Your website is fast on your phone and slow on everyone else's

You open your website on your phone and it appears instantly. Of course it does. You’re standing two metres from your own router, on a recent phone, loading a page your browser has already cached from the last forty times you checked it.

Your customer is on a three-year-old Android, one bar of signal, in a car park, and has never visited your site before. They’re loading the whole thing cold.

Those are two completely different websites, and only one of them counts.

Google doesn’t grade your page — it grades your visitors

This is the part that trips people up. There are two kinds of speed data, and they measure opposite things.

Lab data is a simulation. That’s what PageSpeed Insights produces when it runs a test on a virtual phone in a data centre and hands you a score out of 100. It’s a diagnostic. It’s useful for finding problems. It is not what Google’s ranking systems consume.

Field data is what actually happened to real people who visited your site over the last 28 days — their phones, their networks, their patience. Google collects it from Chrome users, and it’s the version that feeds into Search.

And the threshold isn’t the average. Google measures the 75th percentile of page loads: the slowest quarter of your real visits has to be excluded before you pass. So a site that’s quick for the fast three-quarters and miserable for everyone else fails — correctly, because the slow quarter are real customers who left.

The three numbers to clear: largest content painted within 2.5 seconds, interactions responding within 200 milliseconds, layout shift under 0.1.

The score out of 100 is a vanity metric

Agencies love selling the score, because it’s the only performance number a client can see move. “We took you from 42 to 96.” Great. On what device, on what connection, on which single page?

We’ve seen sites scoring in the nineties in the lab and failing in the field, and we’ve seen the reverse. The score is a to-do list wearing a scoreboard costume. If someone quotes you a fee to “fix your Core Web Vitals” and their deliverable is a screenshot of a green circle, you’re buying a screenshot.

Look at the field data instead. It’s free, it’s in Search Console under Core Web Vitals, and it tells you what your customers experienced rather than what a robot in Iowa experienced.

The four things actually slowing you down

After a few dozen audits, the culprits repeat with boring consistency.

• The hero image. Someone exported a 4,000-pixel photo straight from a phone or a stock site and dropped it at the top of the homepage. It’s often 3–4 MB on its own, and it’s the single largest thing standing between your visitor and a rendered page. Resize it, compress it, serve it in WebP. This one fix is frequently the whole job.
• Third-party scripts. Chat widget, cookie banner, analytics, pixel, review carousel, booking embed, heatmap tool someone installed in 2023 and forgot. The HTTP Archive’s Web Almanac found that 92% of pages load at least one third-party resource. Each one is a request to a server you don’t control, and every one of them is a chance for your site to sit there waiting. Audit them once a year and delete what nobody reads.
• Fonts. Four weights of a custom typeface, loaded from an external host, blocking your text from appearing until they arrive. Two weights, self-hosted, with a sensible fallback, and nobody will ever notice the difference except your visitors, who’ll see words sooner.
• The builder tax. Drag-and-drop platforms ship a large JavaScript bundle to render a page that is, structurally, some text and three images. It’s the trade you accept for the convenience — worth knowing about before you pick a platform, which is part of what you’re really paying for when you commission a site and one of the honest limits of building it yourself with an AI tool.

The honest bit: speed probably isn’t why you’re not ranking

Here’s where we talk ourselves out of a project.

Page speed is a real ranking signal, but it’s a tiebreaker, not a lever. Google’s own documentation is unusually blunt about it: “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” A fast page about nothing does not outrank a slow page that answers the question.

So if you’re on page three, speed is not your problem. Your problem is that the page doesn’t answer what was searched, or nobody links to you, or the page doesn’t exist yet — which is an SEO conversation, not a performance one.

Fix speed for the other reason: the customer who bounced. A slow load costs you the visit you already paid to acquire, whether that visit came from an ad, a map listing, or a van decal. That’s not a ranking issue. That’s a leak.

What we’d actually do, in order

1. Open Search Console, look at the field data, and find out whether you have a problem at all. Half the sites we check don’t.
2. If you do — compress the hero image and the three biggest images behind it. Measure again. Frequently that’s the end of the story.
3. Delete the third-party scripts nobody uses. Every removed widget is a permanent win, not a maintenance task.
4. Only then consider a rebuild, and only if the platform itself is the ceiling.

Notice how far down “rebuild the site” sits. Most speed problems are a bad afternoon of image exports, not a project. We’d rather tell you that than sell you a new build you don’t need.

Send us your URL and we’ll tell you what your real visitors are experiencing — including, quite often, that your site is fine and the money belongs somewhere else.