Core Web Vitals: LCP, INP, and CLS

A team spends two sprints optimising their API response times. Server P99 drops from 400 ms to 90 ms. Google Search Console shows LCP is still “Poor” for 40% of mobile users. The API was not the bottleneck. The 800 KB JS bundle blocking the main thread was.

The three metrics and what they measure

Google’s Core Web Vitals are three field metrics — collected from real Chrome users via the CrUX dataset — that quantify distinct dimensions of user experience.

LCP (Largest Contentful Paint) — the time from navigation start to when the largest visible element above the fold is rendered. This is usually a hero image, an H1, or a background block. Target: under 2.5 s is “Good”; 2.5-4.0 s is “Needs Improvement”; above 4.0 s is “Poor”. Heavy JavaScript that blocks the main thread delays when the browser can paint — LCP suffers directly.

INP (Interaction to Next Paint) — introduced in March 2024, replacing FID. INP measures the worst-case latency from any user input (click, keypress, tap) to the next visual update during the full page lifetime. Target: under 200 ms is “Good”; 200-500 ms is “Needs Improvement”; above 500 ms is “Poor”. Long JS execution tasks on the main thread — including large bundle parse and execution — drive INP up.

CLS (Cumulative Layout Shift) — how much visible content shifts unexpectedly during load. Target: under 0.1 is “Good”; 0.1-0.25 is “Needs Improvement”; above 0.25 is “Poor”. Bundle size does not directly cause CLS; layout shifts come from unsized images, late-loading fonts, and JS that inserts above-fold content after initial paint.

The 100-170 KB rule of thumb

Google’s Web Fundamentals guidance recommends keeping the initial JS under 100-170 KB gzip’d for fast first interactive on mid-range mobile. The math: 170 KB gzip’d decompresses to roughly 500 KB. V8 parses at 200-400 KB/sec on mid-range Android, so parse alone takes 1.5 s. Add compile and execute and the total is 2-2.5 s CPU cost. Add a 4G download at ~500 ms and you arrive at roughly 3 s to interactive — the upper bound that keeps LCP under 2.5 s. Every additional 100 KB beyond that adds roughly 300-500 ms to LCP on the median device.

Different routes can carry different budgets: a marketing homepage should be tight (50-100 KB), a dashboard medium (150-250 KB), admin tools more relaxed (300-500 KB). The homepage carries the tightest cap because it is the conversion entry point.

Three tools: Lighthouse, PageSpeed Insights, RUM

These tools measure the same metrics but from different vantage points.

Lighthouse runs a synthetic test — DevTools or CLI — with CPU throttling on the tester’s machine. Reliable for catching regressions in PRs. Not field data; it represents a single synthetic run.

PageSpeed Insights runs a Google-managed Lighthouse test plus overlays field data from the CrUX dataset — real aggregated metrics from Chrome users on your domain. Useful for public-facing analysis. Updates once per day.

Real User Monitoring (RUM) — your own sampling of real users via the Web Vitals JS library, Sentry, Datadog RUM, or similar. Most accurate, but requires setup and budget. Senior pattern: Lighthouse in CI for catching regressions before merge; RUM in production for regressions that CI misses; PageSpeed Insights quarterly for cross-reference. Each catches a different class of problem; none replaces the others.