Core Web Vitals: lab runs against CrUX field data
This is the material behind the article Core Web Vitals: Lab Data vs CrUX Field Data. I tested four unchanged cometweb.io pages over and over in September 2026 to see three things: how much Lighthouse moves on its own, how far my laptop and PageSpeed Insights disagree, and what CrUX field data adds.
What I looked at
I ran Lighthouse seven times on each of four production pages: the homepage, /pricing, /tools/auditor and /blog/woff2-vs-ttf. I used the default mobile setup with simulated throttling, logged out and without accepting cookies. Each run got a fresh browser profile, so every run was a cold load, and the pages took turns so none of them got all its runs in one stretch of time.
Page weight per URL stayed within 0.31 KB across all runs, which fits with nothing being deployed in between. I kept all 28 runs and excluded none.
On top of that I called the PageSpeed Insights API three times per page. Each response also carries the CrUX field data Google has for the URL or, as a fallback, for the whole domain. The CrUX API itself was switched off for my key, so I read CrUX from those PSI responses.
To see what the lab says when field data exists, I made one PSI call each to five well-known reference homepages that very likely have CrUX data: web.dev, developer.chrome.com, MDN, w3.org and wikipedia.org. I chose them for that reason, so treat them as an illustration and draw no conclusions about the web as a whole.
Results
Four unchanged pages, 28 local runs. Values are medians with the lowest and highest run in brackets.
| Page | Score | LCP | FCP | TBT |
|---|---|---|---|---|
/ | 67 (63–68) | 6.4 s (6.0–6.8) | 4.2 s (4.1–4.4) | 32 ms (17–43) |
/pricing | 67 (65–75) | 6.3 s (4.9–7.0) | 4.0 s (3.4–4.5) | 3 ms (0–17) |
/tools/auditor | 69 (68–72) | 5.9 s (5.3–6.1) | 3.7 s (3.6–4.1) | 1 ms (0–31) |
/blog/woff2-vs-ttf | 70 (69–77) | 5.7 s (4.8–5.9) | 3.7 s (2.9–3.9) | 0 ms (0–20) |
Across all 28 runs the score went from 63 to 77. No simulated run had an LCP at or under 2.5 seconds. Without throttling, the same loads actually finished LCP in about 1.3 seconds (median), which shows how much of the lab number is the throttling model. All 28 local runs had a CLS of exactly 0.
PageSpeed Insights against my local runs, three PSI calls per page:
| Page | PSI score | Local score | PSI LCP | Local LCP |
|---|---|---|---|---|
/ | 71 (63–76) | 67 | 4.5 s | 6.4 s |
/pricing | 85 (79–85) | 67 | 3.8 s | 6.3 s |
/tools/auditor | 79 (78–82) | 69 | 4.2 s | 5.9 s |
/blog/woff2-vs-ttf | 78 (77–81) | 70 | 4.1 s | 5.7 s |
PSI scored 4 to 18 points higher. Its machines are much slower: the benchmark index Lighthouse records was 4,191 to 4,430 on my laptop and 499 to 1,338 on PSI. One PSI run of the homepage had a TBT of 433 ms, while my highest local value was 43 ms.
CrUX had no field data for cometweb.io, neither for the URLs nor for the domain.
Five public sites, one PSI lab run against the CrUX 75th percentile from the same response:
| Site | Lab LCP | Field LCP (p75) | Field INP (p75) | Core Web Vitals in the field |
|---|---|---|---|---|
| web.dev | 6.8 s | 3.1 s | 220 ms | fail |
| developer.chrome.com | 3.8 s | 3.0 s | 294 ms | fail |
| developer.mozilla.org | 2.7 s | 1.9 s | 160 ms | pass |
| w3.org | 1.7 s | 1.1 s | 89 ms | pass |
| wikipedia.org | 1.4 s | 1.3 s | 98 ms | pass |
The lab LCP was higher on all five sites. A single lab run and a 28-day percentile are different kinds of number, so the gap shows how those two kinds of number differ, with neither tool at fault.
After the 28 runs I ran Lighthouse once more on the homepage and read its diagnostics. Its savings figures are Lighthouse estimates from that one run. The fix that followed is described in the before-and-after measurement.
What this data can't tell you
- How real people experience cometweb.io. CrUX had nothing, so every number here comes from the lab.
- Whether other sites spread as much. These are four pages of one small SvelteKit site, measured on one machine, from one home connection in Poland, on one day. Seven runs per page show the spread, but they can't pin down a stable distribution.
- How much of the PSI gap is the slower CPU and how much is the network. PSI runs in a Google data centre, and this data can't split the two.
- How the pages respond to clicks and typing. The tests had no interaction, so they say nothing about INP, and lab CLS only covers shifts during the load.
- How lab and field relate in general. Five well-known sites with one call each are an illustration.
Files
summary.json: medians, ranges and gaps; every number in the article comes from herelab-runs.json: all 28 local runs, trimmedpsi-runs.json: the PSI responses with their lab metrics and CrUX field blocksdiagnostic-home.json: the extra diagnostic run of the homepagesources.json: the documentation cited in the articlelab-runs.mjs: runs Lighthouse locallypsi-runs.mjs: calls the PSI APIanalyze.mjs: turns the runs into summary.json, offlinecharts.mjs: draws both article charts (--lang enor--lang pl)homepage-fix-2026-09-24/README.en.md: the homepage before and after the fixmetodologia.md: this page in Polish
To run it again, install lighthouse@13.5.0, then run CHROME_PATH=<Chromium> node lab-runs.mjs --runs 7 --out lab-runs.json, node psi-runs.mjs --out psi-runs.json (an optional key goes in PAGESPEED_API_KEY and isn't saved anywhere) and node analyze.mjs.