Why your website speed score is not your speed problem

You run PageSpeed Insights, get a 63 on mobile, and spend the next three weeks trying to turn it green. You compress images, defer scripts, swap the font loading strategy, and eventually you hit 91. Then you check your analytics and nothing moved. Same bounce rate, same conversion rate, same revenue.

This happens constantly, and it happens because the score you were chasing was never measuring the thing you actually care about.

What the score actually measures

Lighthouse (the engine behind PageSpeed Insights) runs your page in a simulated environment: a throttled mid-tier phone on a modeled slow 4G connection. It loads the page once, measures a set of metrics, and rolls them into a weighted number from 0 to 100.

That number is a lab score. It is repeatable and useful for catching regressions, but it is a synthetic estimate of one page load under one fixed set of conditions. Your actual visitors are not one device on one connection. They are a distribution: new iPhones on wifi, three-year-old Androids on a train, tablets, desktops with ad blockers, people who tap a link and leave before anything renders.

The metrics inside the score matter more than the score itself. As of the current Lighthouse weighting, the mobile performance number is driven mostly by:

• Largest Contentful Paint (LCP): when the biggest visible element finishes rendering
• Total Blocking Time (TBT): how long the main thread is locked up and unresponsive to taps
• Cumulative Layout Shift (CLS): how much the page jumps around while loading
• First Contentful Paint (FCP) and Speed Index: how quickly anything and then most things appear

TBT is a lab proxy for Interaction to Next Paint (INP), which is what Google actually uses in its ranking signals. That gap is the first clue that your 63 is not the number that changes outcomes.

Lab versus field is the whole game

Google runs two systems side by side. One is Lighthouse, the lab test. The other is the Chrome User Experience Report (CrUX), which collects real measurements from real Chrome users over a rolling 28-day window. The Core Web Vitals that influence rankings come from field data, not from your lab score.

You can have a lab score of 90 and fail Core Web Vitals in the field, or a lab score of 55 and pass. This is not a bug. The lab test is one load under fixed conditions. The field data is thousands of loads under every condition your visitors actually experience, weighted by how often each one happens.

The lab score tells you what your page can do on a good day. The field data tells you what it did to real people all month. Only one of those shows up in your revenue.

If your traffic is mostly returning visitors on cached pages, your field numbers can be far better than your lab score suggests. If your traffic is mostly cold first-time loads from paid ads, they can be far worse. The score does not know which one you are. You do, or you should.

Speed is a threshold, not a slider

Here is the part that changes how you should spend your time. The relationship between speed and behavior is not linear. Shaving 200 milliseconds off a page that already loads in 1.5 seconds does almost nothing to conversions. Getting a 9 second page down to 3 seconds changes everything.

Speed matters at the thresholds where it crosses a human patience boundary:

• Under roughly 2.5 seconds for LCP, most people wait without thinking about it
• Between 2.5 and 4 seconds, you start losing the impatient and the distracted
• Past 4 seconds, abandonment climbs fast, especially on paid traffic that had no reason to be loyal

So a page at a 63 that loads its main content in 2.4 seconds is fine. A page at a 63 that loads a blank white screen for 6 seconds because a third-party chat widget blocks rendering is bleeding money. Same score, completely different problems. The number flattened them into one.

The distinction that matters more than any of this

Performance and speed are not the same word. A page can load in 1.8 seconds and still fail its job because the button is below three paragraphs nobody reads, the form asks for a phone number before people trust you, or the headline does not match the ad they clicked. That is a conversion problem wearing a speed costume.

We see this pattern in audits regularly: a team spends a month optimizing a page from 70 to 95, ships it, and the conversion rate does not budge, because the page was never slow enough to lose anyone. The friction was in the offer and the layout, not the load time.

What to fix, and in what order

If you want speed work to actually move a number you care about, work in this sequence:

1. Pull your field data first. Check Core Web Vitals in Google Search Console, which reports CrUX data grouped by page type. This tells you whether real users are actually failing, and on which templates.
2. If the field data passes, stop. Do not optimize a lab score that has no field problem. Spend that time on the offer, the headline, and the form.
3. If the field data fails, find the specific metric. LCP problems are usually a slow server response, an oversized hero image, or a font blocking render. CLS problems are images and ads without reserved space. INP problems are heavy JavaScript, usually from tag managers and third-party scripts.
4. Fix the mechanism, not the number. Set explicit width and height on images. Preload the LCP image. Defer non-critical scripts. Audit what your tag manager is actually loading, because that is where most blocking time hides.
5. Then measure conversion, not the score. The score should improve as a side effect. The metric that proves it worked is revenue per session or lead rate, not a green circle.

Notice that the score never appears as a goal in that list. It is a diagnostic input, not a target. The moment you turn a diagnostic into a target, you start optimizing the measurement instead of the outcome, and Lighthouse gives you plenty of cheap ways to inflate the number without helping anyone.

The honest version

A good speed score is a hygiene signal, like a clean garage. It tells you nobody has left obvious problems lying around. It does not tell you the business runs well. Plenty of slow-scoring sites convert fine because they load their content fast where it counts and their offer is strong. Plenty of fast-scoring sites convert poorly because speed was never the constraint.

Chase the field data when it fails. Chase the conversion when the field data passes. Treat the score as a smoke detector, not a scoreboard.

If you want a plain-language read on where your site actually stands, run our free grader: it reports the metrics behind the score, not just the number. And if you would rather have a partner who gets paid when those metrics turn into revenue instead of billing you for green circles, apply for partnership.