How fast should my website load, and why it matters

Short answer: your main content should appear within 2.5 seconds, the page should respond to taps within 200 milliseconds, and nothing should jump around while it loads. Those are Google's "good" thresholds for its three Core Web Vitals. I aim tighter than that, with main content in under 1.8 seconds on mobile, because many customers are on phones and mobile data. Speed matters because slow pages lose visitors, and Google uses these signals in search.

"Make it fast" is easy to say and hard to measure without knowing what to look for. This guide explains the numbers Google uses, in plain English, how to test your own site for free, and the fixes that make the biggest difference.

The three numbers that matter

Google groups its speed and stability measurements into Core Web Vitals. There are three, and each one answers a simple question a visitor might ask.

Google assesses these at the 75th percentile of real page visits, which means at least three out of four visits should hit the "good" mark, not just the fast ones. Interaction to Next Paint replaced an older metric, First Input Delay, as a Core Web Vital in 2024, so older articles may still mention FID.

LCP: how fast the main content appears

This is the one visitors feel most. It measures when the largest thing in view, usually a hero image or a headline, finishes appearing. A slow LCP is what makes people hit the back button before they've read a word.

INP: how quickly the page responds

You tap the menu button and nothing happens for a moment, so you tap again. That delay is what INP measures. It's usually caused by too much JavaScript running in the background, often from third-party widgets.

CLS: whether the layout stays put

You go to tap a link and an image loads above it, pushing everything down, so you tap the wrong thing. Layout shift is annoying and makes a site feel broken. It's usually caused by images without set dimensions, late-loading ads or banners, or fonts swapping in.

Does speed affect search rankings?

Yes, but it's not a magic switch. Google's own Search documentation says Core Web Vitals are used by its ranking systems, and also that it always tries to show the most relevant content, even when the page experience is weaker. In practice, speed works like this: if two businesses have similarly useful pages, the faster one has an edge. And a fast site keeps more of the visitors it does get, which matters regardless of rankings.

How to measure your own site

You don't need any special tools. These are free:

• PageSpeed Insights. Enter your address and you get two kinds of data. At the top is field data from real Chrome users, when your site has enough traffic. Below it is lab data from a Lighthouse test that simulates a mid-range phone on a throttled mobile connection.
• Google Search Console. If your site is verified, the Core Web Vitals report shows which groups of pages pass or fail, based on real visits.
• My free website check. It runs the same Lighthouse test and explains the results in plain English, with the top things to fix.
• Your own phone. Turn off Wi-Fi and load your site on mobile data. It's not scientific, but it's exactly what your customers experience.

Field data versus lab data

Field data is what real visitors experienced over the past few weeks. Lab data is a single controlled test. Field data is the better measure of how you're doing, but lab data is useful for finding causes and checking fixes immediately. Small sites often don't have enough traffic for field data, so the lab test is the main guide. Lab scores also vary a little from run to run, so test a few times and look at the trend.

The fixes that make the biggest difference

On the small business sites I review, these are the usual causes of a slow site, roughly in order of impact.

Images

Oversized photos are the most common problem by far. A photo straight from a camera can be many times larger than it needs to be. Resize images to the size they're actually displayed, use modern formats like WebP or AVIF, set their width and height so the layout doesn't shift, and lazy-load images further down the page. Don't lazy-load the main hero image, though, since that delays LCP.

Third-party scripts

Chat widgets, social feeds, tracking pixels, and embedded maps each load their own code, often a lot of it. Remove the ones you don't use, and load the rest only when needed. A map can be a static image that opens the full map on tap.

Themes and plugins

Multipurpose themes and long plugin lists add code to every page, even pages that don't use those features. This is the main reason I often recommend a rebuild over patching, as I explain in WordPress vs a custom built website.

Fonts

Each font family and weight is another download. Use one or two families, only the weights you need, and host them with the site so text appears quickly.

Hosting and caching

If the server takes a long time to respond, everything else waits. Good hosting, caching, and serving files from a content delivery network close to your visitors all help. For sites that don't change minute to minute, generating pages ahead of time is the fastest option of all.

Quick wins you can do this week

Not every improvement needs a developer. If you manage your own site, start here:

1. Replace your largest photos with resized versions, no wider than they're shown on screen
2. Remove plugins, widgets, and embeds you no longer use
3. Swap an embedded map for a static image that links to the full map
4. Remove auto-playing videos and sliders from the top of the home page
5. Check with your host that caching and HTTPS are turned on

Test again after each change, so you know which ones helped. If the mobile score barely moves after all of that, the problem is probably the foundation of the site, not the content on it.

My targets

For the sites I build, I aim for a Lighthouse mobile score of 95 or higher, main content in under 1.8 seconds, almost no layout shift, and very little JavaScript on first load. I test before launch and share the numbers with the client, so the result is measurable, not a promise.

Curious where your site stands? Run a free website check. If it's slow, a website rebuild is usually the most reliable fix, and I'm happy to give you an honest opinion on whether you need one.