Performance
Measuring LCP: lab data versus field data
Field LCP says whether a page passes, lab LCP says why. Here field p75 is 1,724 ms, while two Lighthouse runs differ by 42%.
Key points
- The field decides whether the page passes, the lab explains which part slows it down.
- 229 field readings gave a p75 of 1,724 ms, with 33 above 2.5 s.
- Two Lighthouse runs five minutes apart measured 3.5 s and 5.0 s.
Field LCP says whether a page passes for real users; lab LCP says why, yet two runs in a row can differ by 42%. Here the field reports a p75 of 1,724 ms, the lab 3.5 s and 5.0 s on the same URL.
Same metric, two questions
| Dimension | Field | Lab |
|---|---|---|
| Source | RUM beacon, 229 readings | Lighthouse 13.6.0, one run |
| Window | 25 October - 1 November 2026 | 28 October 2026 |
| Answers | does the page pass? | why does it fail? |
| p75 LCP | 1,724 ms | 3.5 s and 5.0 s across two runs |
The two commands
curl -sS "https://ui.eneawork.it/api/rum/summary?days=7" -H "x-admin-token: $ADMIN_TOKEN"
npx lighthouse https://ui.eneawork.it --only-categories=performance --output=json --output-path=./lcp.jsonThe first command returns the p75 per metric and per device over recent visits; the second writes a report with LCP, CLS and TBT from a single run. You need both: one says whether the problem exists, the other where it starts.
Why two runs disagree
Lighthouse simulates a slower CPU and a different network on each run, and the cache starts empty only when you clear it. Third-party scripts, fonts and hero images arrive at different times: that is where the 1,475 ms gap between two runs five minutes apart comes from.
How to read the gap
- Lab: Lighthouse or WebPageTest with simulated network and CPU. Repeatable, used to compare two builds.
- Field: CrUX or RUM on real visitors. It reflects real devices and networks, and arrives about 28 days late.
- When they diverge they do not contradict each other: lab measures the build, field measures the users.
The limitation
229 readings are not a sample: the p75 is not split by connection, and 10 readings on one route move with a single slow visit. The beacon counts only visits that run JavaScript, so anyone blocking scripts never enters the data.
Where to continue
In the EneUI catalogue: 111,985 components, 1,556 blocks and the record image auto slider, a carousel that can become the LCP element. The guides: what makes LCP worse and what Core Web Vitals are; thresholds in Lighthouse CI explains how to fix the budget in a pipeline.
Frequently asked questions
Which number should I read first?
Field data, because that is what Google uses for the threshold. If the field p75 is under 2.5 s the page passes, whatever a single lab run says.
Why does the lab measure a higher LCP than the field?
Because Lighthouse simulates a slow CPU and a mobile network even when real visitors are on fibre. The lab answers a different question: what the page costs under declared conditions.
How many readings make a reliable p75?
There is no fixed number, but below a hundred readings the p75 moves with a few visits. Here 10 readings on one route are enough to produce a value that changes every day.
Does the RUM beacon replace the Chrome UX Report?
No. CrUX aggregates every Chrome user who enabled telemetry; the beacon sees only visitors who run JavaScript on the site. The two numbers can diverge.
How do I set a threshold in CI?
Use Lighthouse CI with a budget on simulated LCP and compare the median of three runs, not a single one. The field stays the final judge.