What are the three metrics actually measuring?
Loading, responsiveness and visual stability: one number each. Largest Contentful Paint (LCP) is the time until the biggest element above the fold has rendered; Google’s published threshold for “good” is 2.5 seconds. Interaction to Next Paint (INP) is how long the page takes to visibly respond when a user taps, clicks or types: 200 milliseconds. Cumulative Layout Shift (CLS) scores how much the layout jumps around during the visit: 0.1.
Two properties matter more than the definitions. First, the thresholds are judged at the 75th percentile of real visits: your page passes only if three-quarters of actual users get the good experience, so your fast laptop on office wi-fi proves nothing. Second, each metric sits at the end of a short causal chain, which is why fixing them is mostly diagnosis: find which link in the chain is broken and the fix names itself.
What actually improves LCP?
Whatever shortens the chain between the request and the largest element’s pixels: LCP is a supply chain, not a score. The browser must receive the first bytes (server time), discover the hero resource (HTML parsing), download it (size and network), and render it (whatever is blocking). Every failing LCP is a delay in one of those four links. They compound in order: nothing downstream can start until upstream finishes.
The usual culprits, upstream first. Slow server responses (uncached pages generated per request, overloaded hosting, no CDN) spend the whole budget before a single image byte moves. Late discovery: hero images set as CSS backgrounds, injected by JavaScript, or, remarkably often, explicitly lazy-loaded, so the most urgent resource on the page is the last one requested. Weight: a full-resolution image shipped to a phone. And render-blocking CSS or JavaScript that keeps finished pixels off the screen.
Client-side rendering deserves its own mention: if the hero only exists after a JavaScript bundle downloads, parses and executes, your LCP includes your entire framework. That is an architecture cost, not a tuning problem, and occasionally a platform one: when the platform itself is the ceiling is a separate diagnosis. It’s why serious performance work so often starts with how the page is served rather than what’s on it.
What drives INP, and why did it replace FID?
INP is a main-thread problem. The browser runs your JavaScript, layout and paint on one thread; when a user taps while that thread is busy, the tap waits. INP records interaction latency across the whole visit and reports one of the worst cases, so a page that loads beautifully and then freezes when someone opens the menu fails, however good the first impression was.
The culprits are whatever occupies the thread in long, unbroken tasks: oversized bundles hydrating a whole page before anything is interactive; third-party scripts (tag managers, chat widgets, session recorders) each “only” a hundred milliseconds; expensive event handlers doing synchronous work on tap; and enormous DOMs where every update triggers a costly re-layout. Death by a thousand scripts is the normal diagnosis; a single villain is rare.
FID, the metric INP replaced, measured only the delay before the first input’s handler started, not how long the response took, and only once per visit. Pages passed FID while feeling broken; INP closed the loophole by measuring what users actually experience, all visit long. Fixing it is squarely front-end engineering: code-splitting, deferring third parties, breaking long tasks into interruptible pieces.
What causes layout shift?
Anything that renders without its space being reserved. The browser lays out what it has; when something arrives late (an image with no declared dimensions, an ad slot, a cookie banner injected at the top of the page), everything below it moves. CLS sums those movements across the visit, weighted by how far the content jumped.
The fixes are one discipline applied everywhere: give images and embeds explicit dimensions so the browser reserves the box before the pixels arrive; give dynamic content (banners, ads, late-loading widgets) a fixed-size container that exists from the first paint; and load web fonts with metric-compatible fallbacks so text doesn’t reflow when the real font lands. Most of this is settled at build time, which is why a design-to-code handoff that skips the states and breakpoints tends to ship layout shift with them. CLS is rarely one big problem. It’s a housekeeping standard, which is why it quietly regresses the moment nobody owns it.
Why does your lab score disagree with the field data?
Because they measure different things, and only one of them counts. Lab data (Lighthouse, the top panel of PageSpeed Insights) is one synthetic load of one page on one throttled, simulated device, with nobody actually using it. Field data is what Chrome collects from real users (the Chrome UX Report) across every device, network and cache state, reported as a 28-day rolling 75th percentile. Search evaluates the field numbers. The lab number is a diagnostic instrument, not the exam.
So the disagreements are structural, not bugs. Green lab, red field: your test conditions are kinder than your median user’s phone, or the failures happen after load. That’s always true for INP, since a synthetic load never taps anything. Red lab, green field: the throttled simulation is harsher than your actual audience, common for desktop-heavy B2B traffic on good connections. And low-traffic pages may have no field data at all, in which case origin-level numbers stand in.
The practical rule: diagnose in the lab, verify in the field, and let the field verdict decide whether there’s a problem worth money. Chasing 100/100 in a simulator while real users fail is performance theatre. A technical SEO review reads both sources side by side for exactly that reason.
When does performance work actually pay off?
When you’re on the wrong side of a threshold, on pages where speed stands between a user and money. The metrics are bucketed (good, needs improvement, poor), so moving from four seconds to 2.4 crosses a line that matters for the page-experience signal, while shaving 1.8 to 1.2 mostly buys bragging rights. Field-failing commercial pages (product, category, checkout, and paid landing pages where every visitor is bought) are where the same engineering returns conversion as well as compliance.
It pays least when the numbers are already green and the real constraint is elsewhere: content that doesn’t answer the query, authority that doesn’t exist. Performance can’t rescue a page nobody wants to read or link to. A proper SEO audit ranks speed against those other deficits before you spend on the wrong one.
One honest caution: sometimes the culprit is architectural (a theme, a plugin stack, a rendering model), and patching around it costs more over a year than rebuilding the offending layer. A good performance engagement tells you which side of that line you’re on before billing you for either.
