The cometweb.io homepage before and after the fix
This is the measurement behind the article Core Web Vitals: Lab Data vs CrUX Field Data. After the diagnostic run I fixed the homepage in two steps and measured it on production after each one, the same way as before.
What I looked at
Each variant is seven Lighthouse runs in the default mobile preset with simulated throttling, with a fresh browser for every run. I report the median. First I deferred the demo CSS that was blocking rendering. Then I cut the full glossary and the meta table of every page from the JavaScript bundle the layout loads on every page. That took the JavaScript loaded before the homepage's first render from 329 to 208 KB gzipped.
Results
| Variant | LCP | FCP | Score |
|---|---|---|---|
| Before the fix | 6.39 s | 4.14 s | 65 |
| After deferring the CSS | 6.34 s | 4.02 s | 65 |
| After deferring the CSS and trimming the JS | 5.46 s | 3.64 s | 69 |
Deferring the CSS alone cut FCP by 0.12 s and barely moved LCP. The gain came from the lighter JavaScript.
What this data can't tell you
- How the change works for real visitors. These are lab numbers from one machine, and CrUX has no data for cometweb.io.
- How other pages behave. I measured the homepage only.
Files
prod-before.json: runs before the fixprod-after-css-only.json: runs after deferring the CSS onlyprod-after.json: runs after both changeslcp-home.mjs: the measuring script
To run it again with Lighthouse 13.5, use CHROME_PATH=<Chromium> node lcp-home.mjs https://cometweb.io/ 7 result.json.