Why a slow website costs you enquiries, and what to fix first

Someone searches "emergency plumber near me" from a lay-by, taps your listing, gets a white screen, and is back on the results page before your hero photo has downloaded. They ring the next name down. You never see that in a report. It never became an enquiry.

Here's what's actually true about site speed, and which bits of it are worth paying for.

What Google actually measures

Three things, called Core Web Vitals. The pass marks are published, so you can check yourself rather than take anyone's word for it.

LCP (Largest Contentful Paint). Good is 2.5 seconds or less, poor is above 4. How long until the main thing the visitor came for appears. Not when the page finishes loading, when the big bit, usually your hero photo, is actually there.

INP (Interaction to Next Paint). Good is 200 milliseconds or less, poor is above 500. The gap between someone tapping "Book now" and anything visibly happening, across every interaction in the visit, not just the first tap.

CLS (Cumulative Layout Shift). Good is 0.1 or less, poor is above 0.25. A unitless ratio, not seconds, for how much the page jumps about while someone's reading. You go to tap the phone number, an image loads in above it, and you've tapped the cookie settings instead.

Two mechanics most articles get wrong. It isn't your average load time, it's the 75th percentile, so the worst quarter of visits sets your score. And it's real Chrome visits over a rolling 28 days, mobile and desktop scored separately, not a test run on your office broadband. You need good on all three to pass.

Your site probably isn't being measured at all

That field data comes from the Chrome User Experience Report. CrUX only covers pages and origins that are publicly discoverable and "sufficiently popular", and Google won't say what popular means beyond "an exact number is not disclosed".

For a single-location business, that usually means you're not in it. Open the Core Web Vitals report in Search Console and you'll most likely get a message about not having enough data. That's normal, not a fault.

Which has a consequence nobody mentions. No field data means there's nothing for the Core Web Vitals signal to act on. Your visitors still sit through the slow page though. The ranking argument evaporates. The money argument doesn't.

Speed is a smaller ranking factor than you've been told

Google's page experience documentation says "Core Web Vitals are used by our ranking systems", then in the same document, "Google Search always seeks to show the most relevant content, even if the page experience is sub-par". Good scores guarantee nothing.

John Mueller was blunter on LinkedIn in October 2024: "We've been pretty clear that Core Web Vitals are not giant factors in ranking, and I doubt you'd see a big drop just because of that."

Google's own list of ranking updates backs him up: nothing about speed or Core Web Vitals in 2025 or 2026. If someone's selling you work off the back of a "2026 speed update", they've invented it. It's a weak positive signal, not a stick.

What the conversion evidence actually says

The strongest dataset is Deloitte's "Milliseconds Make Millions", run with Google across 37 European and American brand sites and over 30 million sessions at the end of 2019. A 0.1 second improvement in mobile speed pushed 21.6% more visitors through to the form submission page on lead generation sites. Retail conversion rose 8.4%.

Caveats, because you deserve them. That's 2019 data on big brands, not a two-van heating firm, so take the direction as solid and the percentages as not yours. And the "53% of mobile visits are abandoned after three seconds" line everyone quotes at you is real, from Google, but it dates to September 2016.

The realistic culprits on a small business site

Images, nearly always. The LCP element is an image on 76% of mobile pages, and on the median mobile home page images account for 911 KB on their own.

In practice that's a full resolution photo straight off a phone, dropped into a page builder hero block and scaled down with CSS. The visitor still downloads every last megabyte. Biggest fixable lever on most trades sites, and it's an afternoon's work.

Platform matters more than people admit. Mobile pass rates by CMS in the 2025 Web Almanac: Duda 85%, Wix 74%, WordPress 45%, and WordPress runs roughly 64% of CMS-driven sites.

Before anyone talks you into a rebuild though, note that a median WordPress page ships less JavaScript than a Wix one (638 KB against 1,634 KB) and still has the worst pass rate. That points at hosting and images, not the platform.

So, the £3 a month hosting conversation. TTFB (Time to First Byte) is how long your server takes to say hello, and Google's guidance is 0.8 seconds or less for good, above 1.8 seconds for poor. Google is careful to say TTFB isn't a Core Web Vital itself.

But if your server takes 1.5 seconds to answer, you've a second left of your 2.5 second LCP budget to fetch and paint the whole hero image. No caching plugin buys that back.

Then everything bolted on top. Over 90% of pages load third party resources, a median of 79 third party requests on mobile, and the most common are Google's own fonts, tag manager and analytics. I'd add consent banners from experience rather than data, because I've lost count of the sites where the banner is the thing shoving the layout down.

Right, so what do I actually do on Monday

Measure the right thing first. Put your page into PageSpeed Insights: the top section is field data from real visits, the part Google actually uses.

The bottom is a lab score from a simulated phone, diagnostic only. Chasing 100 out of 100 there is the most common waste of money in this corner of the industry.

Then, roughly in this order:

• Resize every image to the size it's displayed at, then save it as WebP. A 4,000 pixel wide hero on a 400 pixel wide phone is pure waste.
• Check your server response time. If it's over a second, better hosting beats any plugin you can install.
• Set width and height on images, and reserve space for anything that loads late, the cookie banner and review widgets especially. That's your CLS sorted.
• Delete plugins you don't use and tracking scripts nobody reads the reports from.
• Test on a real phone, on mobile data, standing outside. Not on the office wifi.

That last one isn't a gimmick. Ofcom's spring 2026 update puts good 4G from all mobile operators across 84% of the UK landmass, and full fibre at 82% of homes. The person searching from a lay-by isn't on gigabit fibre, and because scoring sits at the 75th percentile, that's exactly the visit setting your number.

Search Console's Core Web Vitals report uses the same 28 day field data, free. Google retired the Looker Studio CrUX dashboard at the end of November 2025, so use CrUX Vis if you want a chart.

Speed is one of the few SEO jobs where you can feel the difference yourself, on your own phone, in your own van. Do the images first and see how far that gets you before you pay anyone, us included.

Will a faster site push me up the Google rankings?

Not on its own. Google says Core Web Vitals are used by its ranking systems but are "not giant factors in ranking", and relevance wins over page experience. If your site has no CrUX field data, common for single-location businesses, the signal has nothing to act on.

My Search Console report says there isn't enough data. Is something broken?

No. CrUX only includes sites that pass an undisclosed popularity threshold, and most local business sites don't reach it. Google isn't measuring you, that's all. Test individual pages in PageSpeed Insights instead.

Which Core Web Vital should I worry about most?

LCP on mobile. In Google's June 2026 CrUX data only 67.7% of origins scored good on LCP, against 85.9% on INP, so it's the one sites fail. It's usually an oversized image rather than anything clever, and images are the cheapest thing on this list to fix.