The Core Web Vitals Field Guide: Measure, Diagnose, Improve
A practical guide to LCP, INP, and CLS: what each metric tells you, how to find the real bottleneck, and which fixes are worth shipping first.
On this page
A fast page is not just a high score in a lab. It is a page that shows its main content promptly, responds when someone interacts, and stays where they expect it to be. Core Web Vitals turn those three parts of the experience into field metrics: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS).
The thresholds are useful guardrails, not a complete definition of quality. Google evaluates the 75th percentile of visits, segmented by mobile and desktop. A good result is LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1. Start by understanding which real users miss those targets; optimize the experience, not the report.
Start with field data, then reproduce the problem
Field data answers whether visitors are experiencing a problem; lab data helps you reproduce and diagnose it. PageSpeed Insights combines CrUX field data, when enough data is available, with Lighthouse diagnostics. Search Console groups URLs with similar performance. In your own analytics, segment by device, template, and traffic source so a healthy desktop landing page does not hide a slow mobile article.
Record a baseline before changing code. Note the failing metric, the affected templates, and the browser conditions. Re-test after each meaningful change. Otherwise, a score moving up or down tells you little about what actually improved.
Find the cause behind each metric
LCP: get the main content on screen sooner
The LCP element is often a hero image, a heading, or a large content block. Its time includes server response, resource discovery, download, and rendering. Improve the slowest part: reduce server wait with caching and efficient data access; make the hero image discoverable in the initial HTML; serve an appropriately sized modern image; and avoid loading critical fonts or styles through a long chain of third-party requests.
INP: make interactions feel immediate
INP reflects the latency of interactions across a visit, including the next paint after an input. Long JavaScript tasks, expensive event handlers, and large hydration workloads are common causes. Use browser performance traces to locate the blocking task, split work into smaller pieces, and defer non-essential code. A page that needs little JavaScript has fewer opportunities to block input.
CLS: reserve space before content arrives
Unexpected movement usually comes from media without dimensions, late-inserted embeds, or content injected above what someone is reading. Provide image width and height, set aspect ratios for responsive media, and allocate space for advertisements or embeds before they load. Do not animate layout properties when a transform will do.
Prioritize work by impact and evidence
- Fix issues affecting the largest number of real visitors before polishing a single low-traffic URL.
- Choose changes tied to a measured bottleneck, such as a late-discovered hero image or a long main-thread task.
- Protect accessibility and content quality; removing useful interface features for a score is rarely a durable win.
- Watch field trends after deployment because lab scores cannot represent every network, device, or interaction.
A useful starting point is the web.dev guide to Core Web Vitals. Pair it with a repeatable test plan and real-user monitoring. The goal is not to chase a perfect lighthouse screenshot; it is to make the important path through your site reliably quick.