Core Web Vitals for developers: LCP, INP, and CLS guide

Core Web Vitals measure three parts of a page experience: loading, responsiveness, and visual stability. The metrics are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS).

Google's Core Web Vitals documentation lists the current good targets: LCP within 2.5 seconds, INP below 200 milliseconds, and CLS below 0.1. Use those numbers as release targets, then inspect the page when a metric misses its target.

What LCP measures

Largest Contentful Paint measures when the largest visible content element finishes rendering. It is often a hero image, heading, or large text block. A slow server, render-blocking CSS, a large image, or a delayed font can push LCP later.

Start with the element named in the browser performance panel. Then check the work that delays it:

• Reduce time to first byte with a fast origin and cache policy.
• Compress and size the largest image for the viewport.
• Preload only a truly critical image or font.
• Remove JavaScript that blocks the first render.
• Keep the initial HTML useful while the app loads.

Do not optimize an element that is below the fold just because it is large in the source. LCP measures what the browser renders in the viewport.

What INP measures

Interaction to Next Paint measures how quickly the page responds after a user interaction. It covers clicks, taps, and key presses during the page visit. Long event handlers and expensive rendering work make INP worse.

When INP is high, inspect the slow interaction in the Performance panel. Look for:

• A click handler that does too much work before returning.
• Large synchronous JSON parsing or state updates.
• Repeated layout reads and writes in the same event.
• Third-party scripts running during a user action.
• A component tree that rerenders when one small value changes.

Move non-critical work out of the interaction path. Split large components, defer secondary requests, and keep the first response focused on the action the user chose.

What CLS measures

Cumulative Layout Shift measures unexpected movement of visible content. A page can have a fast LCP and still feel broken if a button moves while a font or image loads.

Reserve space before content arrives:

• Set width and height or an aspect ratio on images and video.
• Give banners and embedded content a known slot.
• Use a font loading strategy that does not replace text with a very different size.
• Avoid inserting content above an element after the page has rendered.
• Animate with transform and opacity when possible.

Test the page after a clean load. A warm cache can hide layout shifts that a first-time visitor will see.

Field data and lab data answer different questions

Field data describes real visits over time. Lab data runs a controlled test with a chosen device, network, and browser state. Field data tells you how users experience the page. Lab data helps you reproduce and debug a change.

Record the test conditions with every lab result:

1. Viewport size and device profile.
2. Network and CPU settings.
3. Cache state.
4. URL and build revision.
5. Metric values and the largest contributing element.

Do not call a lab result a field result. A single local run cannot describe every user's connection or device.

Check performance before release

Run a performance check against the production URL. A local development server does not confirm that the response, assets, and client-side requests come from the deployed build. Compare the result with the last release when you have a baseline.

Use mobile website testing to check the same page at a narrow viewport. A page can meet a timing target while its main button is clipped or its content shifts under a fixed header.

Slop Audit can record lab observations such as Largest Contentful Paint and long main-thread tasks when browser evidence is available. It does not replace field data or a full performance investigation. The report shows the viewport and coverage so you can see what the scan measured.

A short Core Web Vitals release check

production URL → clean load → LCP element → slow tasks
→ real interaction → layout shifts → mobile viewport
→ compare with the previous release

Fix the largest measured cause, deploy it, and test the same URL again. Keep the metric result with the build or release note so a later regression has a clear starting point.