Lighthouse scores are a starting point, not a finish line. Here are the metrics real users experience — and how to measure, interpret, and improve each one.
Field data from the Chrome User Experience Report (CrUX) shows the real performance distribution your users experience — often dramatically worse than lab test results.
The Lab vs Field Gap
Every engineering team knows the scenario: Lighthouse returns a score of 95, the team celebrates, and then a user on a mid-range Android phone in Mumbai reports that the page "takes forever" to load. The gap between lab metrics and field experience is the most underappreciated problem in frontend performance.
Lab tools like Lighthouse run on a controlled machine with throttled CPU and network. Field data — captured from real user sessions — reflects actual hardware, network conditions, browser extensions, and cache states. The two tell fundamentally different stories.
Core Web Vitals: The Three That Count
Google's Core Web Vitals are the subset of performance signals that correlate most directly with user experience. As of 2024, the three that matter for search ranking and user satisfaction are:
- Largest Contentful Paint (LCP) — how long until the largest meaningful element is visible. Good: under
2.5s. Needs improvement: 2.5s–4s. Poor: over4s. - Interaction to Next Paint (INP) — the 98th percentile of all interaction latencies on a page. Good: under
200ms. This replaced FID in March 2024. - Cumulative Layout Shift (CLS) — the total unexpected layout movement users experience. Good: under
0.1. Every image without explicit dimensions contributes to this score.
Diagnosing LCP Problems
LCP is almost always caused by one of four things: a slow server response, a render-blocking resource, a slow resource load, or client-side rendering delay. Start your diagnosis by looking at the LCP element in the Chrome DevTools Performance panel — it is highlighted automatically.
- Check Time to First Byte (TTFB) — if it is over 800ms, fix your server or CDN before touching the frontend
- Check whether the LCP resource (usually a hero image) is discoverable in the initial HTML — or hidden behind JavaScript
- Ensure the LCP image has a
fetchpriority="high"attribute and is not lazily loaded - Verify the image is served in a modern format (
WebPorAVIF) and sized correctly for the viewport
Performance is not a feature you add at the end — it is a constraint you design within from the start.
— Alex Russell, Chrome team, Google
Taming CLS: The Silent Conversion Killer
Cumulative Layout Shift is the metric users feel most viscerally but describe least precisely. They say the page "jumps around" or that they "accidentally clicked the wrong thing." Buttons that shift as ads load, text that moves as fonts swap in, images that reflow as they arrive — these are all CLS contributors.
INP: The New Interaction Standard
Interaction to Next Paint replaced First Input Delay because FID only measured the delay before the browser starts processing an input — not how long it actually took for the next frame to paint after that. INP captures the full interaction cost, which is far more representative of perceived sluggishness.
To diagnose INP, use the Long Animation Frames API (LoAF) in Chrome 123+, or the web-vitals JavaScript library with onINP(). The attribution data tells you which specific interactions are slow and what work is blocking the next paint. Blind optimisation without this data wastes engineering time.
Turning Metrics Into a Feedback Loop
The most valuable thing you can do with performance metrics is integrate them into your development workflow before code reaches production. A CI check that fails if a Lighthouse LCP score regresses by more than 10% from the baseline prevents performance debt from accumulating silently. Pair this with real-user monitoring via the PerformanceObserver API or a tool like Vercel Speed Insights, and you have a closed loop between shipping and measuring that compounds improvement over time.
