The PageSpeed Insights score is a lab number, and 30% of it is Total Blocking Time, a metric no real visitor ever reports (Chrome for Developers, Lighthouse scoring). What Google's Search Console grades, and what its Core Web Vitals guidance for Search refers to, is field data: Core Web Vitals collected from real Chrome users over 28 days. Most arguments about a "slow" site are two people reading two different kinds of tool.
This guide sorts the free and paid website speed tools by the question each one answers, explains how the score is built, and uses 66 Lighthouse runs we recorded on 22 home pages to show how much a single score moves on its own.
Lab data and field data answer different questions
Lab data is one controlled page load: fixed device, fixed network, cold cache. It is repeatable enough to debug with. Field data is what real visitors got, summarised at the 75th percentile. It is the truth about the experience, but it arrives late and says little about the cause.
| Lab data | Field data | |
|---|---|---|
| What it is | One simulated load in a controlled environment | Measurements from real visits |
| Device and network | One emulated phone or desktop, fixed throttling | Every device and connection your visitors use |
| Responsiveness metric | Total Blocking Time, a proxy | Interaction to Next Paint, measured on real taps and clicks |
| Time to reflect a fix | Immediately | Up to 28 days in CrUX-based tools |
| Best used for | Debugging, testing before release | Deciding what to fix, proving it worked |
Sources: Google PageSpeed Insights documentation; web.dev, "Why lab and field data can be different"; Web Almanac 2025
Philip Walton's web.dev article on the difference gives a clean example: a page whose lab test reported a 3.0 second Largest Contentful Paint had a field 75th percentile of 1.8 seconds, with 88% of real visits rated good. Real visitors had warm caches and back/forward cache restores that a cold lab load never sees. The gap can also run the other way, because field data only includes visitors who managed to load the page.
What a PageSpeed Insights score is made of
The 0 to 100 score at the top of a PageSpeed Insights report comes from Lighthouse. Each lab metric is converted to a sub-score on a log-normal curve built from HTTP Archive data on real websites: the 25th percentile of sites maps to 50, the 8th percentile maps to 90. The curve flattens near the top, so moving from 95 to 99 costs far more work than moving from 50 to 70. Below 50 is red, 50 to 89 orange, 90 and above green.
| Metric | Weight | Measured where | Core Web Vital |
|---|---|---|---|
| Total Blocking Time | 30% | Lab only | No, a proxy for INP |
| Largest Contentful Paint | 25% | Lab and field | Yes |
| Cumulative Layout Shift | 25% | Lab and field | Yes |
| First Contentful Paint | 10% | Lab and field | No |
| Speed Index | 10% | Lab only | No |
Source: Chrome for Developers, Lighthouse performance scoring (Lighthouse 10 weights)
The lab load runs with simulated throttling. Lighthouse's throttling documentation gives the mobile preset as a 150 ms round trip, 1.6 Mbps down and 750 Kbps up, with a 4x CPU slowdown, aimed at roughly the 85th percentile mobile connection and a mid-tier phone. The same document admits the simulation has edge cases on both network and CPU. PageSpeed Insights runs that test from a Google data centre in North America, Europe or Asia, so a site hosted in Belgrade and tested from Iowa gets latency its local visitors never see.
Two consequences follow. First, 40% of the score is metrics that do not exist in the field at all. Second, Interaction to Next Paint, the Core Web Vital for responsiveness, is not in the score, because a lab load has nobody tapping the page.
Why the same page scores differently on every run
We ran Lighthouse 12.8.2 in mobile mode three times in a row on each of 24 legal-tech vendor home pages on 21 October 2026, for our post on legal tech website speed statistics. Twenty-two pages completed all three runs. The table shows the eight widest spreads.
| Home page | Platform | Run scores | Spread | Crossed a colour band |
|---|---|---|---|---|
| Lawmatics | Webflow | 41, 75, 78 | 37 | Yes |
| EvenUp | WordPress | 77, 100, 100 | 23 | Yes |
| Litify | Webflow | 47, 66, 67 | 20 | Yes |
| NetDocuments | WordPress | 51, 64, 70 | 19 | No |
| Quorum | WordPress | 32, 49, 50 | 18 | Yes |
| Everlaw | Contentful | 66, 79, 84 | 18 | No |
| Harvey | Next.js | 31, 42, 44 | 13 | No |
| Smokeball | Webflow | 43, 56, 56 | 13 | Yes |
Source: Octo Lighthouse 12.8.2 runs, mobile preset, simulated throttling, one machine, 21 October 2026
Across all 22 pages the median spread was 10 points and the mean 11.4. Twelve pages moved by 10 points or more, three by 20 or more, and five changed colour between runs. Only two scored identically three times, one of them at 100. The runs were minutes apart, so the difference most likely comes from ads, tag managers, A/B tests, server response and the test machine itself rather than from edits to the pages.
Lighthouse's variability guide rates page nondeterminism, local network variability and client hardware as high-impact sources. Its advice is to report the median of several runs and never to run tests in parallel on one machine. A single run 12 points below last week's is often no news at all.
When lab and field disagree
The Web Almanac's 2025 performance chapter, published by HTTP Archive in January 2026, shows the starkest disagreement in the data. Median mobile Total Blocking Time rose to 1,916 ms, up 58% from 1,209 ms in 2024, and the 90th percentile reached 7,555 ms. Over the same year, the share of sites with good mobile INP in the field rose from 74% to 77%, and desktop reached 97%. The authors' explanation is that real phones got faster while the lab still emulates the same mid-tier device.
Three other gaps catch teams out.
Field data may not exist. CrUX only includes pages and origins that are publicly discoverable and popular enough, and Google does not disclose the threshold. New sites and low-traffic landing pages often show no field data at all.
Field data is Chrome only. CrUX comes from desktop Chrome and Chrome on Android. Chrome on iOS, Android WebView and other Chromium browsers such as Edge are excluded, so an audience that is mostly on iPhones is barely represented.
Field data is slow to move. Every CrUX number is a 28-day rolling window. Search Console's validation for a fixed issue runs for 28 days too, and an issue only counts as fixed if it is absent from every URL in the group for the whole period.
The website speed tools, and which question each answers
| Tool | Data | Cost | Best for | Watch out for |
|---|---|---|---|---|
| PageSpeed Insights | Lab and CrUX field, side by side | Free | A first look at one URL | Score is one run from a distant data centre |
| Lighthouse in DevTools or CLI | Lab | Free | Repeatable runs, before and after a change | Local CPU and extensions skew results |
| Chrome DevTools Performance panel | Your own live LCP, CLS and INP, plus CrUX | Free | Finding the cause of a slow interaction | Your device and network, not your visitors' |
| Search Console Core Web Vitals report | CrUX field, grouped URLs | Free | Seeing which page groups fail, as Google sees them | Groups need enough data; 28-day lag |
| CrUX Vis | CrUX field history, weekly | Free | Trend over the last 40 weeks | Popular origins and URLs only |
| CrUX API | CrUX field, daily | Free, 150 queries a minute | Scripted checks across many URLs | Needs a Google Cloud key |
| web-vitals library | Your own field data | Free, about 3 KB | Real-user data for every browser that supports the metric | You need somewhere to send and store it |
| WebPageTest, GTmetrix | Lab, chosen location and device | Varies by plan | Filmstrips, waterfalls, testing near your visitors | Still one load per run |
| Commercial monitors such as DebugBear | Lab schedules, RUM and CrUX in one place | Paid | Alerts and history across a whole site | Cost scales with pages and traffic |
Sources: Chrome for Developers (CrUX Vis, CrUX API, DevTools Performance panel), Google Search Console Help, GoogleChrome/web-vitals, Lighthouse variability guide, DebugBear
The old CrUX Dashboard in Looker Studio is deprecated; Google points to CrUX Vis, which updates weekly instead of monthly. The DevTools Performance panel shows your local Core Web Vitals live and can pull CrUX values for the same URL alongside. The web-vitals library reports LCP and INP in Chromium, Firefox and Safari, with CLS still Chromium only, so a RUM script fills part of the iPhone gap CrUX leaves.
For a Webflow site, our post on Webflow page speed lists which fixes move Core Web Vitals and which only move the lab score; our website speed statistics post covers what speed does to bounce and revenue.
A testing routine that does not chase the score
This is the routine we would run on a marketing site we build or audit. It uses only free tools.
- Start in Search Console. Note which URL groups fail on mobile, and on which metric. A group's status is its worst metric.
- Check the trend in CrUX Vis. A metric sliding for months points to a change; a flat line points to the template.
- Reproduce in the lab, five times. Run Lighthouse in mobile mode five times on a URL from the failing group and keep the median run.
- Find the cause in DevTools. Record the Performance panel and use the page as a visitor would to find the long task or late image.
- Ship, then measure in the field. Recheck the lab median, start Search Console validation, and judge the fix on the 28-day field numbers.
We build marketing sites in Webflow and applications in Next.js, and the routine is the same on both. What changes is where the fix lives: a Webflow setting or an embed on one, the build and the bundle on the other.
What this means for a speed audit or a rebuild brief
Ask for field data first. If a client, a stakeholder or an agency pitch quotes a PageSpeed score, ask what the 75th percentile LCP, INP and CLS are in Search Console or CrUX, on mobile, and over which 28 days. If the site has no field data, say so and use a five-run lab median as the baseline instead of a single score. Treat a score movement of under about 10 points as noise unless the median of several runs agrees. Google's guidance is to aim for good Core Web Vitals: "We highly recommend site owners achieve good Core Web Vitals for success with Search." A 100 in Lighthouse is not in that sentence. Our marketing websites page explains how we scope speed work into a build.
