Core Web Vitals: What Changed with INP, and How to Pass

Core Web Vitals are user-experience metrics documented in Google's page-experience guidance. Their field data describes observed Chrome-user experiences rather than a single lab-machine run. The biggest recent change was the retirement of First Input Delay in favour of Interaction to Next Paint (INP), a stricter measure of responsiveness. Here is what to target and how to investigate each metric.

The three thresholds

• Largest Contentful Paint (LCP): under 2.5s — how fast the main content appears.
• Interaction to Next Paint (INP): under 200ms — how responsive the page feels to input.
• Cumulative Layout Shift (CLS): under 0.1 — how much the layout jumps as it loads.

LCP: investigate the main-content path

The LCP element is often a large image or heading above the fold, but the responsible element and delay vary by page and device. Use page-level browser tooling to identify it before changing the loading path. A large image may need a modern format, correct dimensions, and earlier loading rather than a waterfall of scripts.

• Use next/image with the priority prop on the hero so it is not lazy-loaded.
• Preconnect to any origin the LCP asset loads from.
• Avoid rendering the hero only after client-side hydration — server-render it.

One detail that catches people out: LCP measures when the element renders, not when it finishes loading in some abstract sense — and the element it picks can change between visits. A page whose hero is sometimes a heading and sometimes an image (because the image is slow) will show a bimodal LCP, which looks like noise until you realise the metric is measuring two different things.

INP: investigate interaction and main-thread work

Long JavaScript tasks can delay visual feedback after an interaction. Use interaction traces to identify the work for a representative page, then consider shipping less JavaScript, splitting what remains, and deferring work that is not needed for the first interaction. In React, inspect expensive synchronous work inside event handlers.

INP replaced First Input Delay for a specific reason. FID measured only the delay before an event handler began, so a page could score well while doing something slow enough afterwards to feel broken. INP measures the whole interaction — input, processing, and the paint that follows — across the entire visit, and reports close to the worst one. It is a much harder metric to game, which is precisely the point.

Large hydration work, expensive synchronous event-handler work, and third-party scripts can contribute to slow interactions, but an origin-level field value does not identify which one applies. Use a browser trace before choosing a fix; splitting long tasks and moving verified work off the critical path are common follow-up options.

CLS: reserve the space

• Always set width and height (or an aspect ratio) on images and embeds.
• Use font-display: swap and preload key fonts to avoid text reflow.
• Never insert banners or ads above existing content after load.

Lab results and field data answer different questions

Lighthouse gives you a lab estimate from one simulated device. The Chrome User Experience Report (CrUX) publishes aggregated field data from Chrome users when an origin has enough data, including 75th-percentile values over its trailing window. A green lab score and a poor field value can coexist, which is why chasing the Lighthouse number alone can feel like running in place.

UseShipReady does not run a browser performance test or diagnose why a metric is poor. When CrUX has data for the scanned origin, it queries the LCP, INP, and CLS 75th-percentile values and reports only ShipReady's poor-band results: LCP above 4 seconds, INP above 500 ms, and CLS above 0.25. Those findings describe available origin-level Chrome field data, not an individual scanned page, every visitor, or a live test performed during the scan. New or low-traffic origins may have no CrUX record, which is not a passing metric result.

UseShipReady also reports static deployment signals such as images served without width and height, render-blocking scripts, text served uncompressed, static assets with no cache headers, and redirect chains. These signals can guide investigation, but they do not identify the cause of an origin-level field metric. Use browser profiling and field-data tools to investigate a reported metric before selecting a fix.