Blog
A score, not a speed measurement.
Why your PageSpeed number says little about what your visitors actually experience, and what to watch instead.
Your PageSpeed score isn't a speed measurement.
It's a composite figure from a simulated test, on one page, at one moment, on a simulated device.
What your visitors actually experience sits in a different block of the same report, one that gets far less attention than the coloured number.
Lab data and field data are two different measurements
Lab data comes from a test, field data comes from your visitors.
Lighthouse runs a single page load in a controlled environment, on a simulated mid range device with a throttled connection, and converts that into a score from 0 to 100.
The Chrome User Experience Report, CrUX for short, collects measurements from real Chrome users and reports the 75th percentile over a rolling 28-day window, updated daily.
PageSpeed Insights shows both side by side, but most reports only quote the score.
The Lighthouse score itself is not a ranking factor.
The Core Web Vitals are, and those are measured from real visitors, in other words the field data.
You can improve your score considerably without anything changing for Google or for your visitor.
Why a score of 100 guarantees nothing
A 100 means a single page load of a single URL went well.
Three things fall outside that: the test starts with an empty cache while a share of your visitors are returning, it usually measures your homepage while your traffic lands on listing and detail pages, and it never clicks anything, so everything that only happens after interaction stays unmeasured.
That last point is the biggest blind spot.
Interaction to Next Paint isn't part of the Lighthouse score, because a standard run never clicks anything: without interaction, there's no INP to calculate.
Reliable INP figures therefore come from your field data.
In the lab, Total Blocking Time stands in for it, and that measures something different: how long the main thread is busy during load, not how slowly your facet filter responds on the third click.
A Drupal site with heavy Views facets, an autocomplete search field and a map widget can hit 100 and still come in above 200 milliseconds INP for real visitors.
Your cookie banner skews the picture the same way, because scripts that only load after consent never show up in a lab test.
Why 70 can be perfectly fine
A 70 falls in the orange band and says nothing about your visitors by itself.
The score is a weighted average of five lab metrics, and those weights are fixed:
| Lab metric | Weight in the score |
|---|---|
| Total Blocking Time | 30 percent |
| Largest Contentful Paint | 25 percent |
| Cumulative Layout Shift | 25 percent |
| First Contentful Paint | 10 percent |
| Speed Index | 10 percent |
The bands are 0 to 49 red, 50 to 89 orange and 90 to 100 green.
Because Total Blocking Time weighs thirty percent, one heavy but necessary script pulls your score down hard while the page is visually ready fast.
If your field data shows you stay under 2.5 seconds LCP, under 200 milliseconds INP and under 0.1 CLS at the 75th percentile, your visitors are having a good experience.
Then 70 is just 70, and you don't need an optimisation project from me.
What to track instead
By the three field data metrics, per page type, at the 75th percentile.
- Measure per template: homepage, listing, detail and search results behave differently, so a site average hides where things go wrong.
- Keep mobile and desktop separate: the thresholds are assessed per segment, and that difference is usually bigger than between two templates.
- Add your own measurement: CrUX only includes publicly findable pages with enough visitors, so smaller sites need to measure their own visitors directly.
- Build in patience: because of the 28-day window, a fix only shows its full effect after a few weeks, so don't judge a fix after two days.
When a low score is a real signal after all
Without field data, the lab score is all you have.
That applies to new sites and to pages with little traffic.
Don't use the number as a goal, read the diagnostics underneath it instead: render blocking resources, images without fixed dimensions, unused JavaScript.
If lab and field point the same way, for example red field data next to a score of 35, then something is genuinely broken and the score is a confirmation rather than a myth.
Which fixes on a Drupal site pay off the most, I cover in my article on Core Web Vitals for Drupal and where the real gains are.
My approach: measure with visitors, fix in the code, document it
I start with your field data, not with the tool.
I map out which templates fall below the thresholds at the 75th percentile, trace the cause in the frontend and in the Drupal configuration, and document what changes so you can check it again after every release.
Drupal 11 gives you a solid base with Dynamic Page Cache and BigPipe, but it isn't automatic: badly configured cache contexts undo that gain again.
Tools for the basics, handwork for the rest.
Want to know where your site stands with real visitors, take a look at my technical SEO and frontend performance service.
If the bottleneck sits deeper in the architecture, that falls under Drupal architecture and development.
Send me your URL via the contact form and I'll give you an honest picture within 24 hours of what there is to gain.
Frequently asked questions
How can I test my website's speed?
With PageSpeed Insights, since it shows both the field data from CrUX and the lab score from Lighthouse in one report.
Look first at the field block with LCP, INP and CLS at the 75th percentile over 28 days, and use the lab score below it only to hunt for causes.
There's no single best tool, there's a right combination: Lighthouse in Chrome DevTools lets you choose device and throttling yourself, and your own measurement on your visitors fills in what CrUX doesn't cover.
For sites with little traffic, that own measurement isn't a luxury, since CrUX requires a minimum number of visitors before a page enters the dataset.
In any case, test more than just your homepage, since an overview page behaves differently from your landing page.
Why is my website slow?
Usually because of too much JavaScript, heavy images, and caching that's not set up on the right layer.
Which of the three weighs heaviest for you differs per site, so start by measuring instead of optimising.
In Drupal I often see it with views missing the right cache contexts, too many separate blocks on a page, and third-party scripts that still get loaded after the cookie banner.
Slowness is rarely a single cause, so an audit that only looks at the score usually misses half the picture.
How can I measure my website's performance?
On two levels: with real visitors and in a test.
Field data from CrUX or from your own measurement script gives you LCP, INP and CLS the way visitors actually experience them, segmented by mobile and desktop.
A lab test in Lighthouse then provides the diagnostics that show you where that time is going.
The field data tells you whether you have a problem, the lab test helps you find it.
Do you need a PageSpeed score of 100 for good SEO?
No.
The Lighthouse score isn't a ranking factor, the Core Web Vitals are, and those are measured on real visitors.
If you stay at the 75th percentile under 2.5 seconds LCP, under 200 milliseconds INP and under 0.1 CLS, you're fine, whether the number in the tool says 72 or 98.
Chasing the last few points usually costs more than it delivers, so stop once the field data is green.
What is the difference between lab data and field data?
Lab data comes from a test, field data comes from your visitors.
Lighthouse does a single page load in a controlled environment, with a simulated mid-range device and a throttled connection, and converts that into a score from 0 to 100.
CrUX collects measurements from real Chrome users and reports the 75th percentile over a rolling 28-day window.
So the field data tells you whether your visitors have a good experience, the lab data mainly helps you find the cause.
Is Interaction to Next Paint included in my PageSpeed score?
No.
A standard Lighthouse run doesn't click anything, and without interaction there's no INP to calculate.
In the lab, Total Blocking Time stands in for it, and that measures how long the main thread is busy during load, not how slow your filter responds on the third click.
Reliable INP figures therefore come from your field data, where you want to stay under 200 milliseconds at the 75th percentile.
A question about this topic?
Briefly describe your situation, and I'll let you know what's going on and what it would cost. No sales pitch.
