Most speed conversations still start with a score out of 100. That number is a lab result: one machine, one connection, one moment. The business result is whether the person who landed on your site stayed long enough to call, book, or buy.
Two things have made this more urgent than it was a couple of years ago. Google finished its move to mobile-first indexing, so the phone experience is now the one it evaluates — not the desktop version you checked on a big screen. And in March 2024 it replaced First Input Delay with Interaction to Next Paint (INP), which measures how quickly the page responds when someone taps a menu or a form field on a mid-range Android. Both changes mean an old site that "felt fine on my laptop" can be quietly failing.
Where the cost actually shows up
- Paid traffic that bounces. Every second before the page paints is charged twice: once for the click, again when the visitor leaves.
- Search visibility. Page experience is a ranking input. A fast, stable page won't beat a better answer, but a slow one loses ties it should win.
- Enquiries that never happen. A contact form that appears after four seconds of white screen is a form most people never see.
- Your own time. "Can you check why the site is slow?" becomes a recurring support thread every few months.
The numbers that actually matter
Google's Core Web Vitals are the closest thing to a shared benchmark, because they come from real Chrome users (the CrUX dataset) rather than a lab.
| Metric | What it measures | Good | Needs work |
|---|---|---|---|
| LCP | When the main content appears | ≤ 2.5 s | > 4 s |
| INP | How quickly the page responds to a tap | ≤ 200 ms | > 500 ms |
| CLS | How much the layout jumps while loading | ≤ 0.1 | > 0.25 |
One caveat worth knowing: the score you see in a lab tool and the field data Google uses are different numbers. A page can score 95 in the lab and still be slow for a customer on congested 4G in a shop doorway. Field data wins.
What usually causes it in 2026
On the small business sites I audit, the same handful of problems show up again and again — and they're rarely exotic:
- Hero images exported straight from a design file, still 2–4 MB, instead of a compressed AVIF or WebP.
- Four or five third-party scripts competing to load first: chat widget, consent banner, two tracking pixels, a review widget.
- A page builder plugin stack that renders three copies of the same layout before the browser can show one.
- Fonts loaded from a third-party CDN, so text waits on someone else's server.
- An origin that answers in 600–900 ms before it sends anything at all.
- New in the last year: an AI chat widget bolted onto the page that loads a second framework on top of your site's own.
What I'd fix first
- Images. Resize and re-encode hero art. It's usually the biggest win for the least risk, and it doesn't change the design.
- Scripts. Every third-party script should have an owner and a purpose. Most sites carry at least one nobody can justify.
- Serve HTML before JavaScript. If the page can't paint until a large bundle downloads and runs, everything downstream waits — LCP included.
- Move to fast hosting. Static files behind a CDN, or an origin that responds in under 200 ms, removes a cost you cannot optimise away in code.
- Only then chase the long tail: preload hints, font subsets, re-rendering fixes.
A useful rule: if a change doesn't make the page visibly faster on a mid-range phone over a normal mobile connection, it isn't the first thing to fix.
About that score
Don't pay anyone to chase three green circles. Pay them to find the one metric that's costing you enquiries and fix it properly. Some sites get from "clearly slow" to "feels instant" without a redesign; some need a rebuild, because the weight is structural rather than one oversized image.
If you want a straight answer on which of these is actually costing you, send me the URL and I'll tell you what I'd fix first — no charge for the first look.