How fast does my website actually need to be?
The three numbers Google measures, why your PageSpeed score is not one of them, and what 735 real small business homepages say about where the bar honestly sits.
- The measurable bar is Core Web Vitals, assessed at the 75th percentile of real page loads: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint at 200 milliseconds or less, Cumulative Layout Shift at 0.1 or less.
- Your PageSpeed score is lab data from one simulated run. Google's own guidance is to think of performance as "a distribution of scores, rather than a single number".
- Speed is usually not the reason the phone is quiet. In an audit of 3,241 small business homepages the median mobile score was 66, and only 10.5% scored 90 or more, which makes middling the norm rather than the exception.
- Google says Core Web Vitals are used by its ranking systems, and also that it will still show the most relevant content when page experience is sub-par. Speed is a tiebreaker, not a substitute for being the right answer.
Fast enough that the main thing on the page has drawn within two and a half seconds on a phone, that a tap gets a visible response almost immediately, and that nothing shifts about under the reader's thumb while it loads. That is the honest answer, and it is not an opinion: those are Google's published thresholds, and they are the only speed numbers with a defined pass mark attached.
What follows is the detail behind that, including the part most speed advice leaves out, which is how rarely speed is the thing standing between a small business and an enquiry.
The three numbers that are actually measured
| Metric | What it measures | Good |
|---|---|---|
| Largest Contentful Paint | How long until the biggest thing on screen, usually the hero image or the headline, has finished drawing | Within 2.5 seconds |
| Interaction to Next Paint | How long the page takes to visibly respond after someone taps, clicks or types | 200 milliseconds or less |
| Cumulative Layout Shift | How much the page jumps about while it is still loading | 0.1 or less |
Thresholds from Google's Core Web Vitals documentation. Each is assessed at the 75th percentile of page loads, segmented across mobile and desktop, so three quarters of real visits have to clear the bar. An average would let a fast desktop connection hide a slow phone.
Two of those three are not about waiting at all. Interaction to Next Paint is about the page feeling dead for a moment after a tap, which on a phone reads as a broken button and gets tapped again. Cumulative Layout Shift is the one everyone has experienced: you reach for a link, an advert or a late-loading image pushes the page down, and you hit something else. Both are fixable without touching your hosting.
Your PageSpeed score is not one of those numbers
The number out of 100 that everyone quotes is a Lighthouse performance score. It is lab data: one simulated device, one simulated connection, one run, in a controlled environment. It is genuinely useful for finding what to fix, because it tells you which asset is the problem. It is not a measurement of what your visitors experienced.
Google's own documentation lists the reasons two runs of the same page disagree: A/B tests, changes in the adverts being served, internet routing, the device it ran on, browser extensions, even antivirus software. Its advice is to treat "site performance as a distribution of scores, rather than a single number". The colour bands are wider than people assume too: 90 to 100 is good, 50 to 89 is needs improvement, and only below 50 is poor. A score of 72 is not a failure, it is the middle of the road.
The field data is the other half. Where enough real Chrome visitors have loaded your pages, Google reports what they actually experienced, and that is what feeds the page experience signals. If you only ever look at the lab score, you are reading a rehearsal and calling it the performance.
What 735 real homepages actually scored
Rather than guess at a typical score, here is a measured distribution. In an audit of small business websites run between 11 July and 16 August 2026, Google PageSpeed Insights returned a mobile score for 735 of 1,934 live homepages. The median was 66.
Share of the 735 homepages that returned a mobile score. Scores are Google PageSpeed Insights, measured once per site during the audit window.
Two things follow from that shape. One in ten sites is genuinely fast, so a good score is a real competitive difference rather than table stakes. And roughly a third sit under 60, which is the range where a phone on mobile data starts losing people before the page appears. The large middle is neither winning nor losing on speed.
Speed is rarely why the phone is not ringing
This is the uncomfortable part for anyone selling speed optimisation. In the same audit, the local sites were faster than the comparison sample, not slower: 30.1% of borough homepages scored under 60 on mobile against 38.5% across the rest of the sample. Speed was the thing those businesses were being sold, and it was the thing they were already doing best.
What was actually broken was findability. 51.9% of the live homepages carried no structured data identifying them as a local business at all, which is the machine readable version of your name, address and phone number, and the thing search engines and AI assistants read before they decide you are a real business in a real place. A site that loads in one second and cannot be found is not a fast site, it is an invisible one.
So the honest order of work for most small businesses is: be findable, be clear about what you do and where, make it obvious how to get in touch, then make it fast. If enquiries have dried up, the six usual causes are worth working through before you spend anything on performance.
What actually makes a small business site slow
There is a floor, though, and when a site is under it the cause is almost always one of four things. None of them are exotic and none of them need a rebuild.
- Full size photographs. A photo straight off a phone or a camera can be several thousand pixels wide, served at that size to a screen 375 pixels across. It is the single commonest cause of a slow homepage and the easiest to fix: resize, compress, and let the browser choose a size.
- Accumulated plugins and apps. A booking widget, a review carousel, a chat bubble, a cookie banner, a popup, a tracking script and a page builder each load their own code. Any one is fine. Seven is a slow site, and they are also the usual source of layout shift, because they arrive late and push everything down.
- Fonts loaded from somewhere else. Every custom font is another connection to another server before any text can be drawn. Self hosting them and cutting them down to the characters you actually use removes a round trip from every visit.
- Hosting and caching. Cheap shared hosting can spend a long second thinking before it sends the first byte, and nothing you do to the page recovers that. Caching means the server sends a finished page instead of rebuilding it for every visitor.
How to test it so the answer means something
- Run PageSpeed Insights and read the field data at the top first, if your site gets enough traffic to have any. That is real visits. The lab score underneath is the diagnosis, not the verdict.
- Test the pages people actually land on. A service page or a location page is usually heavier than the homepage and is where most search traffic arrives.
- Run it three times and take the middle result. Single runs vary for all the reasons Google lists, and one bad run sends people rebuilding a site that was fine.
- Check the mobile tab, not desktop. The thresholds are assessed separately and mobile is where the traffic and the weak connections are.
- Load it on a real phone, on mobile data, away from your own wifi. Then scroll immediately. If anything jumps under your thumb, that is your layout shift problem, visible without a tool.
What to aim for
For a small business site, clearing the three Core Web Vitals thresholds on mobile is the target that matters, and a mobile Lighthouse score in the nineties is a reasonable proxy for a site built carefully. Every page on this site is built to a budget of 95 or better on mobile, with the stylesheet inlined, the fonts self hosted and cut down, and no third party script in the critical path. That is not a heroic engineering effort, it is what you get when nothing unnecessary is loaded in the first place.
And if the choice is between a fast site nobody can find and a merely adequate one that answers the question people are searching for, Google is explicit about which wins: it "always seeks to show the most relevant content, even if the page experience is sub-par". Speed settles ties. It does not win the argument.
Common questions.
What is a good PageSpeed score?
In Lighthouse's own bands, 90 to 100 is good, 50 to 89 is needs improvement and 0 to 49 is poor. For context, in an audit of 735 small business homepages the median mobile score was 66 and only 10.5% reached 90 or more. Anything in the sixties or seventies is ordinary rather than broken.
Is website speed a Google ranking factor?
Yes, but a modest one. Google states that Core Web Vitals are used by its ranking systems, and in the same documentation that it "always seeks to show the most relevant content, even if the page experience is sub-par". Speed helps decide between pages that are otherwise equally good answers.
How fast should a page load on a phone?
The published target is Largest Contentful Paint within 2.5 seconds, measured at the 75th percentile of real page loads on mobile. In plain terms, the main image or headline should be on screen in under two and a half seconds for at least three quarters of your visitors.
Why does my PageSpeed score change every time I run it?
Because it is a single simulated run. Google lists A/B tests, rotating adverts, internet routing, the device, browser extensions and antivirus software as causes of variation between runs. Run the test three times and use the middle result rather than reacting to one number.
Will making my website faster get me more enquiries?
Only if slowness is what was losing them. If a site is scoring under 40 on mobile, people are leaving before it appears and fixing it will show. If it is in the sixties, the enquiry problem is almost always findability, clarity or trust instead, and speed work will not move it.
Do I need to worry about Core Web Vitals if I use Wix or Squarespace?
The thresholds apply to every site regardless of what built it. What differs is how much control you have: on a hosted builder you can resize images, remove unused apps and cut third party widgets, but you cannot change how the platform loads its own code. That ceiling is worth knowing about before you pay someone to chase a score.