How fast should a business website be? Targets, not feelings
Fast enough is a number, not a feeling. The targets we hold every site to, why mobile is the one that counts, and how to measure yours in five minutes.
The short answer
“Fast enough” has a definition. Google publishes thresholds for three measurements of real user experience, and treats a page as good when it meets all three for three out of four visits, on mobile. Those are the targets we hold every site to, not because Google says so but because they match the point where visitors stop noticing the wait.
| Metric | Target | What the visitor experiences below it |
|---|---|---|
| Largest Contentful Paint | 2.5 seconds or less | The main content is on screen before they wonder whether the page is broken |
| Interaction to Next Paint | 200 milliseconds or less | Taps and clicks respond immediately |
| Cumulative Layout Shift | 0.1 or less | Nothing jumps while they are reading or about to tap |
Why mobile is the number that counts
Most first visits to a business website happen on a phone, often on mobile data, often on a device that is two or three years old. That device has less processing power and a worse connection than any laptop in your office. JavaScript that runs instantly on a desktop takes several times longer there. Images that feel fine on Wi-Fi are heavy on a metered connection.
Google measures and reports mobile and desktop separately, and mobile is the one that reflects your visitors. Judge your site there.
Measure yours in five minutes
- Open Google Search Console and find the Core Web Vitals report. Switch to mobile.
- Look at the page groups marked poor or needs improvement. Those are pages losing visitors right now, regardless of what anyone’s laptop shows.
- Open PageSpeed Insights for your homepage, your main service page and the page where people convert. Read the field data section first; it comes from real visitors.
- Only then look at the lab diagnostics to understand the causes: images, scripts, fonts, server response, layout.
- Check on a real phone over mobile data. Not to measure, but to feel what your visitors feel.
Speed is a property of decisions
A slow site is not slow because nobody tried. They are slow because of accumulated decisions: a heavy theme, a slider on the homepage, fifteen tracking tags, images uploaded at camera resolution, three font families, a server that assembles every page on request.
Fast sites are fast because of different decisions: pages delivered as finished HTML from a network close to the visitor, script only where a component needs it, images sized and formatted for the screen, one or two fonts, self-hosted. A site built that way meets the targets without a tuning project and, more importantly, keeps meeting them.
What this means for you
Open Search Console this week and look at mobile Core Web Vitals. If your important pages are green, keep them that way by watching what gets added. If they are not, the causes are almost always images, scripts and layout, in that order. Fix them in place if the platform allows it; if you are fixing the same things for the third time, the platform is the problem.
Frequently asked questions
Is there a single number I should aim for?
Not one, three: the Core Web Vitals thresholds, at the 75th percentile of real mobile visits. If you want one habit instead of one number, open the Core Web Vitals report in Search Console once a month and make sure no page group is marked poor.
Our Lighthouse score is 90. Is that good?
It is a lab result from one simulated visit, useful for finding causes and useless as a report card. A page can score 90 in Lighthouse on a laptop and fail Core Web Vitals for real visitors on phones. Look at field data first, then use Lighthouse to find out why.
How much does speed actually matter for a small business?
Two ways. Google uses Core Web Vitals in ranking, mostly as a signal among many. More directly, visitors on slow pages leave before they act, and they do it silently. You do not get a complaint; you get a lower conversion rate and no explanation.
Can an existing slow site be fixed without a rebuild?
Often to an acceptable level: images, scripts and fonts are usually the culprits and can be fixed in place. Sites built on heavy platforms tend to drift back, because every new plugin and tag adds weight. A rebuild becomes the cheaper option when you fix the same problems for the third time.
Sources
- Google web.dev: Web Vitals (accessed 2026-09-11)
- Google Search Central: Understanding page experience in Google Search results (accessed 2026-09-11)