Auditing Core Web Vitals

"LCP 2.1 s, CLS 0.08, INP 180 ms" — you should be able to hear those three numbers and know instantly which are fine. Core Web Vitals are three field metrics with hard thresholds:

INP is the newest: it replaced First Input Delay in March 2024. FID measured only the input delay of the first interaction — a load-time impression. INP observes every click, tap, and key press and reports the interaction's full latency to the next painted frame, so it grades the page's entire life. Hover and scroll are not observed, which is why a scroll-only session reports no INP at all.

Where a number comes from decides what you are allowed to optimize against:

• Lab (Lighthouse: one synthetic run, throttled CPU/network) is diagnostic — it hands you render-blocking resources and long-task bars, but it often reports no INP, because nobody clicked anything.
• Field (CrUX's 28-day dataset, or your own RUM) is the verdict: the 75th percentile of page loads, segmented mobile vs desktop. A page is "good" when p75 clears the threshold, not when your laptop feels fast.

The three are independent by design: a page can paint in 1.5 s and still score poor INP because a filter handler blocks the thread; another can be slow to load and still post perfect CLS. A green Lighthouse score is evidence about one synthetic run on one throttled profile — it says nothing about the interactions users actually perform, and nothing about the mid-range device that is a third of your traffic. metric.rating applies the same thresholds as the table to a single sample, which is what lets your pipeline bucket reports without re-deriving the bands.

Sourcing, in priority order: field first — PageSpeed Insights shows CrUX's 28 days of field data above its own lab run, and that ordering is correct. Field answers what to fix; the lab answers where to look. When field data reports no INP for a URL, check two mundane causes before panicking: scroll-and-hover-only sessions are never observed, and low-traffic URLs lack enough interaction samples. In the lab, Total Blocking Time stands in for INP — the same long tasks, minus the user.

Wiring measurement into the app is one client component:

'use client'
import { useReportWebVitals } from 'next/web-vitals'

const send = (metric: { name: string; value: number; id: string }) => {
  navigator.sendBeacon('/analytics/web-vitals', JSON.stringify(metric))
}

export function WebVitals() {
  useReportWebVitals(send)   // callback identity must stay stable
  return null
}

Import it from the root layout and keep the function outside the component: an inline arrow gets a new identity every render, re-registers, and reports duplicates of metrics already observed. The payload gives you metric.name, metric.value, metric.rating (good / needs-improvement / poor), metric.entries for attribution, and navigationType — worth segmenting on, since back-forward-cache and soft-navigation visits behave differently from a fresh load. sendBeacon matters because INP finalizes when the page is hidden or unloaded; a fetch that never lands in time silently loses the worst interactions.

Percentile math deserves one sentence of skepticism: p75 across users hides your worst 25%. Reading a green dashboard while one device class churns is the standard failure — segment by device and page type before declaring victory.

With the numbers fixed, the rest of this topic is diagnosis: which component produces the LCP element, which element moves after paint, and which interaction takes 620 ms to answer.

LCP — dissect the largest element. The browser tracks the largest visible element in the initial viewport — usually a hero <img>, a text block, or an element with a background image — and records when it paints. Observation stops once the user starts interacting, so it is a load metric with four sub-parts, each with a different owner:

The canonical Next.js bug is one line: <Image src="/hero.jpg" /> with default props. Default loading="lazy" defers the fetch until the layout positions the element, so resource load delay alone can cost hundreds of milliseconds on the exact element that defines LCP. The fix from Optimizing Images with next/image transfers directly: preload (or loading="eager" + fetchPriority="high") on the single LCP candidate, accurate sizes, nothing else eager. Note the second-order effect: if the LCP element is a headline rather than an image, font-swap timing lands inside element render delay — which is why metric-tuned fallbacks in Self-Hosted Fonts with next/font move LCP, not just CLS.

CLS — the score has a formula. For each unexpected shift:

shift score = impact fraction × distance fraction
impact   = share of the viewport affected by the moved elements
distance = how far the furthest element traveled, as a viewport fraction

Work an example: elements covering half the viewport (impact = 0.5) sliding down 20% of the viewport height (distance = 0.2) score 0.10 — a single shift sitting exactly on the good/poor boundary. Shifts less than a second apart group into a session window, windows cap at 5 seconds, and the page's CLS is its worst window, not a running sum — one five-second burst of chaos defines the score.

The usual culprits, matched to fixes:

• image or iframe with no reserved box → width/height, or fill inside an aspect-ratio container; the browser reserves space before bytes arrive;
• cookie banner, consent toast, or ad injected above content → render below existing content, or reserve min-height for the slot;
• font swap re-wrapping paragraphs → next/font's adjusted fallback metrics;
• client-only content appearing after hydration → put a skeleton of the final size in the server HTML — a skeleton that grows still shifts.

Two rules keep CLS honest: shifts within 500 ms of a user input are excluded (a dropdown pushing content down on click is not penalized — the user asked), and only unexpected movement counts, so position: fixed overlays that never participate in layout are free. Your enemy is movement the reader didn't request.

What qualifies as an LCP candidate: an <img>, a block-level text element (a headline paragraph counts as one unit), an element whose background image loads through CSS, or a video poster. The largest one in the initial viewport wins, and candidates stop updating at the first click or key press — that boundary is what makes LCP a load metric and leaves everything after it to INP's territory. It also complicates "preload the hero": when desktop shows a text headline and mobile shows an image, the candidate differs by viewport, which is exactly the case the docs warn against preloading — you are then choosing per viewport or arguing that one element is largest everywhere.

LCP is one load event and CLS is a stability score; the third vital is neither — it is latency, repeated across every interaction the user attempts.

The report says a settings-page button has an INP of 620 ms — poor. FID would never have flagged it: the user's first interaction was a nav link, and FID only measured the delay before that first handler ran. INP watches every click, tap, and key press, and for most pages reports the slowest one (one outlier is discarded per 50 interactions, so a single hiccup doesn't define the page; at p75, the threshold back in chapter 1 is good ≤ 200 ms, poor > 500 ms).

An interaction's latency splits into three phases, each with its own fixes:

The measurement window runs from input to the next painted frame, so everything between the tap and visible feedback counts — including work other people's scripts did while your handler waited.

One number frames why this vital exists at all: Chrome usage data shows roughly 90% of a user's time on a page is spent after it loads — so a metric suite that grades only the opening seconds grades the least representative part of the visit. INP is how the suite accounts for the other 90%, which is also why a perfect LCP says nothing about whether your filters feel usable.

Where 620 ms usually comes from in a Next.js app:

DevTools → Performance: record, click the button
long-task bars > 50 ms overlapping the click?
├── in the post-hydration burst → third-party scripts (revisit next/script strategies)
├── inside your handler          → parsing/formatting in the click path; move it out
└── style & layout recalculation → huge lists, deep nested grids, forced synchronous reflows

Concrete moves, each connected to something you already set up: a vendor shipping afterInteractive competes with your first interactions — move non-essentials to lazyOnload (Loading Scripts with next/script); a filter keystroke that re-sorts 10,000 rows belongs in a transition or behind useDeferredValue, so urgent input paints first and the heavy list commits after:

const [query, setQuery] = useState('')
const deferredQuery = useDeferredValue(query)

<SearchInput value={query} onChange={setQuery} />
<ExpensiveResults query={deferredQuery} />  // low-priority render, skipped in the input's frame

Pure computation — CSV parsing, date crunching, diffing — belongs off the main thread in a Web Worker, because no amount of scheduling makes a 300 ms synchronous parse fit inside a frame budget. Streaming slow data behind Suspense also protects INP indirectly: an unbroken server wait delays hydration for everything, while a streamed shell hands interactivity over early.

Diagnosis closes the loop: field data at p75 tells you the score is bad; metric.entries gives the Event Timing entry and its duration split (input delay, processing, presentation); the Performance panel attributes it to a script URL or a component. Because INP finalizes when the page is hidden or unloaded, long-lived tabs report late — segment your pipeline by navigationType and navigationId instead of assuming one value per page view.

Then re-measure against the number, not the feeling: p75 ≤ 200 ms.

This is the last link in the chain you have been building: Router Prefetching Behavior hid navigation latency, script strategies stopped stealing the thread, fonts stopped moving text, images reserved their space and painted early. The same request-level discipline now applies before rendering, in Writing Middleware.