A recurring conversation: a team has spent months improving their Lighthouse score from 62 to 91, and conversion has not moved. They conclude that site speed does not matter for their business. The more likely explanation is that they optimized a measurement rather than an experience.
Lab scores and field data are different things
Lighthouse runs on a simulated device and network. It is repeatable, which makes it useful for catching regressions in CI. It is not what your customers experience, and Google does not use it for ranking. Google uses the Chrome User Experience Report — aggregated measurements from real Chrome users on real devices and connections.
Those two numbers diverge routinely, and the direction is informative. A site with excellent lab scores and poor field data usually has a problem that only appears under real conditions: a third-party script that is slow from certain regions, a personalization service that delays render for logged-in users, or an origin that is fine at low traffic and struggles at peak.
Optimize the 75th percentile, not the average
Core Web Vitals are assessed at the 75th percentile, which means a quarter of your users must be having a worse experience than the number you are looking at. Averages hide this entirely — a fast experience for most users and a terrible one for a minority produces a comfortable average and a failing assessment.
That minority is not random. It skews toward older Android devices, rural and congested networks, and users on data-saver plans. In most US consumer businesses that is a commercially significant segment, not an edge case worth ignoring.
The three metrics, and what usually causes each
Largest Contentful Paint
Usually the hero image, and usually because it is oversized, in the wrong format, lazy-loaded when it should not be, or waiting behind a render-blocking stylesheet. The fixes are well understood: serve modern formats at appropriate dimensions, preload the LCP element, and eliminate render-blocking resources above the fold.
When LCP is slow and the image is fine, the cause is almost always slow server response. Check Time to First Byte before optimizing images that were never the problem.
Interaction to Next Paint
INP measures whether the page responds when someone taps it. Poor INP is almost always JavaScript occupying the main thread — hydration on framework-heavy pages, analytics and tag manager scripts, chat widgets, and event handlers doing more work than they should.
- Audit third-party scripts and remove any whose business value does not justify their cost.
- Defer everything not needed for the first interaction.
- Break long tasks so the browser can respond between them.
- Consider server-side tag management to move analytics weight off the client entirely.
Cumulative Layout Shift
The most fixable of the three and the most irritating to users. Set explicit width and height on images and video, reserve space for ads and embeds, avoid inserting banners above existing content, and use font-display settings that do not cause a large reflow when the webfont arrives.
Defend the result or lose it
The most common outcome of a successful performance project is gradual reversal. A marketing tag here, an unoptimized image there, a new library for one feature — none individually alarming, collectively returning the site to where it started within about a year.
The fix is a performance budget enforced in continuous integration. Set thresholds for page weight, script size and key timings, and fail the build when a change exceeds them. It converts performance from a project someone championed into a constraint the system enforces.
Performance work without a budget in CI is a temporary condition, not an improvement.
Measure before, measure after, and give field data four weeks to reflect the change. If conversion does not move on a genuinely faster site, the constraint was somewhere else — and now you know where not to look.