Why a good PageSpeed score doesn't prove your site is fast

“The first principle is that you must not fool yourself—and you are the easiest person to fool.”
— Richard Feynman, 1974

The screenshot usually arrives at the end of a project: a big green circle, 98 out of 100, sent as proof that the site is fast. Everyone is happy, the agency first of all, and performance gets filed under solved problems. I'll admit it: I've taken that green-circle screenshot myself.

Meanwhile, a potential client opens your page on their phone, on a train between Sion and Brig. They see a blank screen, then a banner that shifts at the exact moment they were about to tap a button. If they came through a Google ad, you paid for that click, whether they stay or not.

The lab score isn't a lie, but it doesn't measure what Google uses to assess your site. Google looks at the speed your real visitors experience, and that is what needs care, even when the circle is already green.

Why a lab score tells you nothing about your real visitors

PageSpeed Insights shows two different things, and people often look at only one. At the top, when they exist, the field data: what real Chrome users experienced on your page over the last 28 days. Below it, the Lighthouse score: a simulation on a fictional device and connection.

The lab simulates a single visitor

The lab test loads your page once, under fixed conditions, with no cookie banner accepted, no extensions and no history. That makes it very useful for debugging, because the result can be reproduced from one run to the next. But it knows nothing about your real visitors, their phones or their network.

Core Web Vitals are measured in the field

Core Web Vitals are three measures of the real experience, and each answers a simple question: does it show, does it respond, does it stay put? To be rated good, a page has to meet all three thresholds on at least 75% of real visits:

• LCP: the time to display the largest visible element, 2.5 seconds at most;
• INP: responsiveness to interactions, 200 milliseconds at most;
• CLS: layout stability while the page loads, 0.1 at most.

A lab score of 98 with field data in the red is still a slow site for the people who matter.

1. Read your field data before you touch the code

Start with the Core Web Vitals report in Search Console. It groups your pages by issue, separates mobile from desktop and tells you which of the three measures is the problem. It is the only serious basis for deciding where to invest, because it reflects what Google actually sees.

When your site doesn't get enough visits

One honest limit applies here: a low-traffic site often doesn't have enough Chrome visits for Google to publish field data. The report stays empty, and that is normal. In that case, the lab becomes your best indicator again, as long as you read it as an estimate and test on a real phone.

That is also why performance belongs in an SEO strategy rather than on a checklist at the end of a project: it is tracked over time, page by page, like your rankings, and it quietly degrades with every addition if nobody keeps an eye on it.

2. Lighten the main image, the one that shows first

On most brochure sites, the element that sets LCP is an image: the header photo, the homepage visual, sometimes a background video. That is what to tackle first, because it often carries most of the weight the visitor is waiting to see.

Lighten, size and prioritize the image

Three moves fix most cases:

• serve the image in a modern format such as AVIF or WebP, at the size it is actually displayed;
• load it with priority instead of letting it wait its turn behind everything else;
• declare its width and height in the code, so the browser reserves its space before it even arrives.

That last point also fixes CLS, the shifts that make people tap the wrong button. On my own site, all 739 images declare their dimensions, and none of them causes a layout shift. It's no feat; it's a rule applied during the build rather than corrected afterwards.

Be wary, too, of carousels at the top of the page and autoplaying background videos. They often become the LCP element without anyone deciding so, and they force the phone to download several visuals before showing the first one. A single strong image, served well, almost always does better, for impact as much as for speed.

3. Remove the scripts nobody really chose

A site's second source of weight is invisible: scripts. A chat widget, three tracking tools, a cookie banner, a carousel, a plugin installed for a one-off need and never removed. Each seemed light, and together they keep your visitor's phone busy at the very moment they try to interact.

Take inventory before you optimize

List every script your site loads and ask who added it, why and whether it still serves a purpose. Many arrive with a theme bought to save time , and that inventory alone often gains more than any fine-tuning: the fastest code is still the code you don't load.

For the scripts that stay, the question becomes one of timing. A chat widget or an interactive map has no reason to load before your headline: defer them until after the main content renders, or until the visitor's first interaction. Content comes first, tools second, and the phone responds when it is touched.

And no site is perfect. The latest audit of mine still flagged structured data weighing about 16% of the HTML, and a missing preconnect to the analytics tool. That's extra weight, modest but real, and I treat it like any other piece of work.

Speed is decided in the architecture, not after launch

Optimizing speed after the fact means hunting for grams on a structure built without a scale. You compress an image, delay a script, gain a few points, and the next addition wipes out the gain. Sites that stay fast are fast because every choice was weighed while they were being built.

Set a performance budget from the mockup

I work with that constraint from the start: which images, in which format, which scripts and for what use, which font and how many weights. Those decisions belong to web development , not to an optimization phase you hope to have time for at the end.

One truth is worth keeping in mind: speed breaks ties, it doesn't replace anything. A fast page that doesn't answer the visitor's question won't climb, and a slow but indispensable page will hold its place for a while. Performance is a condition of entry, not a strategy on its own.

Ready to measure the speed your visitors really experience?

A green circle is nice, but your visitors are the ones who decide whether your site is fast. Look at what they experience, deal with the main image, sort through the scripts, and the score will follow on its own. The reverse has never made a site faster for anyone.

👉 Want to know what your visitors really experience when they open your site? Get in touch