Website Loading Speed: The Number That Actually Matters

Website speed comes down to one number for most small businesses: how long until the biggest thing on the screen appears, on a phone, for a real visitor. Google's threshold for good is 2.5 seconds, measured at the slowest quarter of visits. The score PageSpeed Insights gives you is a lab estimate of that and two other measures. Aim for the real number first, the score second, and know that for some businesses neither matters much yet.

I test every page I build to a bar higher than Google's before it goes live, and I have watched enough owners panic at a red 47 to want to explain what the number is and is not. Five of the six pages ranking for this search are lists of testing tools, and not one of them links to Google's own definition of good. This one does.

What Is a Good Website Speed?

Google measures three things and calls them the Core Web Vitals. The definitions and thresholds are published on web.dev, last updated 31 October 2024, and the good and poor boundaries are set out in Google's thresholds article, updated 7 May 2025.

Two details in that guidance matter more than the numbers. The threshold is judged at the 75th percentile of page loads, which means the slowest quarter of your real visitors have to get the good experience, not the average one. And it is "segmented across mobile and desktop devices", so a fast desktop site with a slow phone site fails. In Australia Statcounter's October 2026 figures have mobile at 48.56% of web use against 48.49% desktop, and the phone is where the slow experiences are. Test the phone result.

For a sense of how many sites get there, the 2025 Web Almanac, working from July 2025 measurements across the web, found 48% of mobile sites and 56% of desktop sites passed all three, and 62% of pages on mobile had a good LCP against 74% on desktop. Roughly half the web is on the wrong side of the line on a phone. Being on the right side is not exotic. It is a decision made at build time.

Why Your Test and Google Disagree

Run PageSpeed Insights and you get two reports on one page, and they routinely contradict each other. The top one is field data: what Google's documentation, updated 21 October 2024, describes as real users' experiences "over the previous 28-day collection period", from the Chrome User Experience Report. The bottom one is lab data, which "is based on a simulated load of a page on a single device and fixed set of network conditions". The score out of 100 comes from the lab run. Search Console's Core Web Vitals report comes from the field.

So a site can score 92 in the lab and fail in the field, because the lab phone on a fixed connection is not your customer on a regional 4G signal, and the field number is a 28-day history that does not move the day you fix something. The reverse happens too: a site with hardly any visitors shows no field data at all, and the lab score is the only guide there is. When the two disagree, the field wins, because the field is what Google says it uses. The lab is for finding what to fix.

Google's Search Central page on Core Web Vitals, updated on 10 December 2025, is plain about why any of this matters for being found: "We highly recommend site owners achieve good Core Web Vitals for success with Search." It also says page experience "aligns with what our core ranking systems seek to reward". Not a guarantee, and not the whole game. One signal, applied to every page you have.

Why Page Builder Sites Are Slow

The three usual causes, in the order I find them.

• The hero. A full-width photo uploaded straight from a phone at 4 or 5 megabytes, or worse, an autoplay video. The biggest thing on the screen is the LCP element by definition, so this one file decides the number that matters.
• The stack. Page builders load their whole toolkit on every page whether the page uses it or not, and each app, plugin, chat widget, booking embed and font service adds requests. None of them is slow on its own. Together they are.
• The hosting. A site served from one server on the other side of the world, rendered fresh for every visitor, against a site delivered as finished files from a location near them. Same design, different seconds.

A recent redesign client of mine is the cleanest example I have. When I measured her old site in July 2026 it took 11.1 seconds to show its main content on a phone, almost all of it an autoplay video in the hero, and it scored 39 out of 100. That is the first cause and the second cause on one screen. On the rebuild, the About page carries fifty-four photographs of the real community. Loaded naively that page would weigh 4.7 megabytes. It starts at 0.04 megabytes and fetches the rest as you scroll, which is 117 times lighter at the moment the LCP is measured. The photographs are the same. The engineering is different.

What Fixing It Costs

The cheapest fixes are the ones you can do this afternoon on any platform, and they are usually the ones with the biggest effect on the number that matters.

I would rather you did the first three rows before you talked to me. If they take a page from poor to good, you have solved it for the price of an afternoon, and a rebuild is a decision for other reasons. My guide to website redesign covers when those other reasons are worth it, and how long a build takes covers the timeline if you get there.

When Speed Does Not Matter

This is the section the tool lists leave out. If your site gets forty visits a month, nearly all of them people who already know the business and want the phone number, taking LCP from 4 seconds to 2 seconds will change almost nothing about your year. Speed is a multiplier on visitors who are deciding. It is not a source of visitors, and it will not rescue a page that does not say what you do or what it costs.

Where it decides the outcome is the page a stranger lands on from search or an ad, on a phone, in a hurry, comparing you with the next result. That is where a page that has not painted in four seconds is a page that never got read, and where a jumping layout makes them tap the wrong thing and leave. If that describes your service pages, speed is worth an afternoon. If it does not, spend the afternoon on the words. Website traffic but no sales takes the leaks in the order they usually matter, and broken basics, speed included, are the last of the five, not the first.

How to Check Yours in Two Minutes

You can run the test right here. It asks Google to load your site on a phone and hands back the two reports side by side: what real visitors got over the last 28 days, and the lab score. The first is the number that matters. The second is the one everyone quotes.

If you would rather read Google's full report, or the test above cannot reach your site, the same result is five steps away.

• Open PageSpeed Insights and paste the exact address your site uses, with the www if it has one. Testing the version that redirects measures the redirect, and I have watched that cost a site eight points.
• Read the top block first. If it shows real visitor data, those are the numbers Google uses. If it says there is not enough data, your site is too quiet for a field result and the lab score is your only guide.
• Switch to Mobile. Ignore Desktop until Mobile passes.
• Find the LCP element. The report names it. If it is a photo or a video, you already know your first fix.
• Run it twice. Lab results wobble by a few points between runs, so a 91 and an 88 are the same site. A 91 and a 47 are not.

If you would prefer it read for you, The Found Report tests your homepage and the pages you sell from against these thresholds and tells you which of the three numbers is the problem and what is causing it, alongside the rest of what decides whether a stranger trusts the page. $550 flat, two business days, and if the answer is "do the three free fixes", that is what the report will say.

Frequently Asked Questions

Hayley Rasmussen

Founder & digital marketing specialist at Saltline Studio, Port Macquarie. Helping small businesses grow with custom websites and organic search.