Core Web Vitals as Signals, Not Scores
LCP asks "did anything useful appear?", INP asks "did the page answer when I touched it?", CLS asks "did it move while I was reading?". They are proxies for three different user frustrations — and they are web-platform definitions that have already changed once.
Frame the diagnosis
Performance work starts from a symptom and a signal — never from a resource dashboard.
Three metrics, three unrelated complaints
The vitals are not three views of one problem. Each is a proxy for a distinct thing a user complains about, with a distinct cause and a distinct fix. Treating them as a single "performance score" is how teams end up optimising the one that is easiest to move rather than the one their users are suffering from.
Because they are platform definitions rather than physical quantities, they change. INP replaced FID as a Core Web Vital in 2024 precisely because FID measured only the delay before the *first* interaction was processed, which was easy to look good on and poor at describing real responsiveness. Write the metric definitions down with a date, and re-check them: a threshold you memorised two years ago may no longer be current.
The threshold values are also chosen by the platform, not derived from your users. "Good" is a useful shared vocabulary and a poor substitute for knowing what your own funnel does at 2s versus 4s. Use the thresholds to communicate; use your own data to decide.
| Vital | User complaint it proxies | Usually caused by | Fixed by |
|---|---|---|---|
| LCP — Largest Contentful Paint | "I stared at a blank page" | Late-discovered hero resource, render-blocking CSS/JS, slow TTFB | Resource priority and discoverability, less blocking work |
| INP — Interaction to Next Paint | "I tapped and nothing happened" | Long tasks occupying the main thread, heavy event handlers | Breaking up work, yielding, moving computation off the main thread |
| CLS — Cumulative Layout Shift | "It moved and I clicked the wrong thing" | Images without dimensions, late-injected banners, web fonts swapping | Reserving space up front for anything that arrives late |
Why your lab number and your field number disagree
A lab run measures one device, one connection, a cold cache, no extensions, no third-party consent banner, and an interaction pattern chosen by the tool. Field data measures every device your users own, warm and cold caches, real network variance, and interactions people actually perform.
INP is the sharpest example. A lab tool has to *simulate* interaction, so it typically reports responsiveness under conditions no user reproduces; the field value comes from actual taps, including the one a user made while a third-party script was executing. It is completely normal for a lab run to look excellent and field INP to be poor, and that gap is information rather than an error.
The reverse gap also happens: CLS in the lab can look terrible because the tool loads with an empty cache and no consent state, while returning users with a cached font and a dismissed banner see almost no shift. Neither number is wrong; they are answers to different questions, exactly as in The Half of the Budget You Cannot See From the Server.
| Signal | Value | What it tells you | Verdict |
|---|---|---|---|
| LCP — lab, desktop profile | 1.1s | Fast machine, fast link, cold cache. A regression baseline, nothing more | normal |
| LCP — field p75, mobile | 4.2s | The population your users are actually in | smoking gun |
| INP — lab | not reported / simulated | Lab tools cannot observe interactions users did not make | suspect |
| INP — field p75, mobile | 380ms | Real taps landing on a busy main thread | smoking gun |
| CLS — lab | 0.24 | Cold cache, no consent state, font swap on every load | suspect |
| CLS — field p75 | 0.03 | Repeat visitors with cached fonts barely see it | normal |
Moving the metric versus fixing the experience
Every one of these metrics can be gamed, and the gaming is usually easier than the fix. That makes them dangerous as targets: the moment a number becomes a goal, someone will find the shortcut, and the shortcut is almost always invisible to the metric and obvious to the user.
The honest test is whether the change would still be worth shipping if the metric did not exist. Reserving space for an ad slot genuinely stops content jumping under the reader's thumb; hiding the shifting element until it settles makes CLS report a lovely number while the user still waits. One is a fix, the other is a report.
This is why the vitals belong on a dashboard next to a business metric and a qualitative signal, not alone. If completion rate did not move and users still say "it feels laggy", the number improved and the product did not — the same discipline Measure Before You Optimize applies to any optimisation.
1# CLS: hide the late element until it settles2.promo-banner { visibility: hidden }3# ...reveal after layout stabilises4 5# LCP: mark a tiny always-present element as the "largest"6# so LCP fires early while the real hero is still loading7 8# INP: defer the handler past the measurement window9# so the interaction "responds" before doing the work10 11# Result: green dashboard. User still waits, still mis-taps.1# CLS: reserve the space the element will occupy2.promo-slot { min-height: 90px } /* known at render time */3<img src=hero.avif width=1200 height=600> /* aspect ratio reserved */4 5# LCP: make the real hero discoverable and prioritised6<link rel=preload as=image href=hero.avif fetchpriority=high>7 8# INP: break the 300ms handler into yielding chunks9# so the next paint is not blocked by one long task10 11# Result: green dashboard AND the page stops jumping.Both columns produce the same metric movement. Only one changes what the user experiences, which is why a vital is a signal to investigate rather than a target to hit.
Key points
- LCP, INP and CLS proxy three unrelated frustrations — blank screen, unresponsive tap, shifting content — with three different causes and fixes.
- They are platform definitions with a history of changing; INP replaced FID as a Core vital in 2024. Re-check the definitions rather than trusting memory.
- Lab and field values for the same vital routinely disagree, and the disagreement is information about cache state, device and real interaction patterns.
- Every vital can be gamed more cheaply than it can be fixed; the test is whether the change would be worth shipping without the metric.
- Report vitals as p75 per route and device class, next to a business metric — never as a single composite score.
Follow the diagnosis
The causal chain, hop by hop — and the readings that invite the wrong conclusion.
- 1HTML → parser: the hero image is referenced deep in the document or injected by script, so the preload scanner never sees it early.
- 2Parser → network: script and stylesheet fetches occupy connection priority; the hero image queues behind them.
- 3Main thread → paint: a 400ms script task runs before layout can complete, so the largest element cannot paint even once its bytes have arrived.
- 4User → main thread: a tap arrives during that task; input delay is added to processing and presentation, and INP records the total.
- 5Late banner → layout: an element with no reserved space is inserted above the fold, content jumps, and CLS records the shift the user just mis-tapped through.
- • "Our Lighthouse score is 98, vitals are fine." That is one synthetic device with a cold cache; field p75 on mobile is the number your users live in.
- • "CLS is 0, so layout is stable." Check whether shifts are simply happening outside the measurement window or being hidden rather than prevented.
- • "INP is bad, we need a faster server." INP is main-thread responsiveness on the device; server latency is largely irrelevant to it.
- • "LCP improved, so the page is faster." Confirm the LCP element is still the element users care about — LCP can improve because a smaller element became "largest".
- • "The vitals are the goal." They are proxies chosen by a platform. Your funnel is the goal.
Measure, fix, validate
An optimization is not finished until the metric that motivated it has moved.
- • Field p75 of LCP, INP and CLS per route, segmented by device class and connection, from real-user telemetry.
- • The LCP element identity per route — knowing *which* element is the largest paint is usually more actionable than the timing itself.
- • Attribution data for INP: which interaction, which handler, and how much of the delay was input delay versus processing versus presentation.
- • CLS sources: which elements shifted and what arrived late to cause it.
- • Lab values for the same three metrics per commit, on a pinned profile, purely as a regression trend.
- • Fix the vital with the worst field p75 in the worst segment first, and fix its named cause — not the metric.
- • For LCP: make the largest element discoverable in the initial HTML, give it fetch priority, and remove blocking work ahead of it.
- • For INP: break long tasks into yielding chunks and move computation off the main thread (see [[rendering-and-layout]] and [[event-loop-lag]]).
- • For CLS: reserve space for every element whose size is known before it arrives — images with dimensions, slots with min-heights, fonts with matched metrics.
- • Re-read the current metric definitions before acting on a threshold you remember from a previous project.
- • Field p75 for the specific vital, specific route and specific device segment, over a window long enough to be stable — 7 days before and after is a reasonable default.
- • Attribution data confirming the named cause disappeared: the LCP element is now the intended one, the long task no longer appears in INP attribution, the shifting element no longer appears in CLS sources.
- • The other two vitals did not regress — INP getting worse while LCP improves is a common trade when work is deferred rather than removed.
- • A business metric over the same window, so a percentile improvement caused by losing impatient users is distinguishable from a real one.
- • Reserving layout space for late content means visible empty regions during load — a real design cost paid to stop the jump.
- • Preloading and prioritising the hero competes for bandwidth with other resources; over-prioritising simply moves the queue.
- • Yielding long tasks into chunks adds scheduling complexity and can make total work slightly slower while making the page far more responsive.
- • Collecting attribution-level field data increases client telemetry volume and its associated privacy surface.
- • A CI budget on the lab values per route, failing on a meaningful regression rather than on noise.
- • A field alert on p75 per vital per device class, windowed so it does not fire on traffic-mix changes.
- • A review rule: anything inserted above the fold must declare its dimensions; anything added to the first-screen bundle must state its main-thread cost.
- • A dated note recording which metric definitions and thresholds the team is targeting, reviewed periodically because the platform changes them.
Accuracy
Performance numbers are conditional. These are the conditions.
- WEB-SPECIFICCore Web Vitals are web-platform definitions. The metric set, thresholds and measurement methodology are maintained by the platform and have changed — INP replaced FID as a Core vital in 2024. Verify current definitions rather than relying on memory.
- ILLUSTRATIVEAll lab-versus-field numbers here are invented to show the characteristic shape of the disagreement, not measurements from any real site.
- ENVIRONMENT-SPECIFICField values depend on your specific user device and network mix; two sites with identical code can report very different vitals.