Performance·June 2025·9 min read

What’s New in Core Web Vitals 2.?

First Input Delay is gone. Interaction to Next Paint (INP) has been the third Core Web Vital since March 12, 2024, and it measures every click, tap, and keypress on a page, not just the first one. The other two vitals, Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS), are unchanged in what they measure, but Google keeps refining how they're calculated.

What the three Core Web Vitals actually measure

Core Web Vitals are a fixed set of three field metrics Google uses to judge real-user page experience: loading, responsiveness, and visual stability. Each one is scored at the 75th percentile of page loads, segmented by mobile and desktop, using data from the Chrome UX Report (web.dev — Web Vitals, Chrome for Developers — Overview of CrUX).

75th percentile matters more than it sounds. A site can look fast in a demo and still fail Core Web Vitals, because the metric represents the experience of your slower-than-median real users, on real networks and real devices, not a lab run on a fiber connection.

Largest Contentful Paint (LCP) — loading

LCP tracks how long it takes the largest visible content element, an image, a video poster frame, or a block of text, to render. Good is 2.5 seconds or less; needs improvement is up to 4.0 seconds; anything past 4.0 seconds is poor (web.dev — Largest Contentful Paint).

Interaction to Next Paint (INP) — responsiveness

INP is the metric that changed. It's covered on its own below, because the change is the actual news in this space.

Cumulative Layout Shift (CLS) — visual stability

CLS scores unexpected layout movement across the entire page lifecycle, not just during load. Good is 0.1 or less; needs improvement is up to 0.25; poor is anything above that (web.dev — Cumulative Layout Shift). The score for each shift is impact fraction multiplied by distance fraction, and shifts get grouped into session windows, so a single scroll-triggered ad insert can tank a page's score even if the rest of the layout never moves.

Metric	What it measures	Good	Needs improvement	Poor
LCP	Time to render the largest visible element	≤2.5s	2.5s–4.0s	>4.0s
INP	Latency of every click, tap, and keypress, to next paint	≤200ms	200ms–500ms	>500ms
CLS	Unexpected layout movement across the full session	≤0.1	0.1–0.25	>0.25

All three thresholds are measured at the 75th percentile of page loads, split by mobile and desktop. Passing in a Lighthouse run on your own laptop tells you nothing about whether you pass in the field.

Why FID was retired and INP took over

First Input Delay only measured the delay before the browser started processing a user's very first interaction with a page. It said nothing about every interaction after that, which is most of what a user actually does on a commerce site: filtering a product grid, opening a size selector, typing into a search box.

INP replaces that with full-session coverage. It observes every click, tap, and keyboard press for as long as the page is open, and reports a single representative value, not an average, so a page that's fast once and then locks up under real use can no longer hide behind a good first-interaction score (web.dev — Interaction to Next Paint).

The Chrome team proposed INP as FID's replacement in May 2023, moved it from experimental to pending status the same year, and made it a stable Core Web Vital on March 12, 2024 (web.dev — Advancing Interaction to Next Paint, web.dev — INP becomes a Core Web Vital on March 12, Google Search Central — Introducing INP to Core Web Vitals).

What INP actually observes

Only three interaction types count toward INP: mouse clicks, touchscreen taps, and keyboard presses. Scrolling, hovering, and pinch-zoom are explicitly excluded, because they don't represent a discrete request-response interaction the way a click does (web.dev — Interaction to Next Paint).

Every qualifying interaction gets timed from the moment it starts to the moment the browser paints the next frame in response. For pages with many interactions, one outlier is dropped per 50 interactions observed, which keeps a single freak stall from wrecking an otherwise responsive page's score.

The three phases inside a single interaction. INP reports the worst representative interaction across the whole page session, not just the first one.

How Google actually measures this: field data over lab data

The Chrome UX Report (CrUX) is the dataset behind every Core Web Vitals score that affects search. It aggregates real, anonymized user experience data from Chrome, and it's the same dataset behind PageSpeed Insights and the Search Console Core Web Vitals report (Chrome for Developers — Overview of CrUX).

Field data versus lab data

Lighthouse gives you a lab score: one run, one simulated device and network profile, fully reproducible. CrUX gives you a field score: real users, real devices, real network conditions, aggregated over a rolling 28-day window. A page can score 100 in Lighthouse and still fail its CrUX INP threshold, because Lighthouse can't simulate a mid-range Android phone under real thermal throttling with six tabs open.

Both have a job. Lighthouse is for diagnosing a specific page before you ship. CrUX is for knowing whether your actual users are having a good time, which is the number that matters for ranking and for revenue.

What actually moves each vital on a commerce site

Fixing LCP

Preload the actual LCP image or font, don't just optimize everything equally.
Serve responsive images with correct srcset/sizes so mobile doesn't download a desktop-resolution hero.
Move render-blocking CSS and JS out of the critical path for the above-the-fold view.
Use a CDN with edge caching close to your actual customer base, not just close to your dev team.

Fixing INP

INP problems are almost always long tasks: JavaScript that monopolizes the main thread and delays every pending interaction behind it. The fix is breaking long tasks into smaller chunks and yielding control back to the browser between them (web.dev — Optimize Interaction to Next Paint).

// Yield to the main thread between chunks of work
async function processLargeList(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);
    if (i % 50 === 0) {
      await new Promise((resolve) => setTimeout(resolve, 0));
    }
  }
}

On a product listing page, the usual culprits are: a filter re-render that rebuilds the entire grid instead of patching the DOM, a synchronous analytics call fired inside a click handler, and third-party scripts that block the main thread on every route change.

Fixing CLS

Reserve space for images and embeds with explicit width and height, or an aspect-ratio.
Reserve space for ad slots and banners before they load, instead of pushing content down when they arrive.
Avoid inserting content above existing content unless it's in direct response to a user's own interaction.
Preload web fonts with font-display: optional or matched fallback metrics, so text doesn't reflow when the real font arrives.

Lighthouse tells you what's slow in a lab. CrUX tells you what's slow for the customer on a three-year-old Android phone standing in a store with two bars of signal. Ship for the second one.

Building this into a real workflow

Treating Core Web Vitals as a quarterly audit instead of a standing gate is how regressions ship. A product page that passed in January can fail by June because someone added a chat widget, a size-guide modal, and a personalization script, each shipped by a different team, each individually harmless.

Field monitoring in production

CrUX updates on a rolling 28-day window, which is too slow to catch a regression before it costs a release cycle of traffic. Closing that gap means capturing real user metrics (RUM) directly, with the same open-source web-vitals library Chrome's own team maintains, and shipping the values to your analytics pipeline as they happen (GitHub — GoogleChrome/web-vitals).

That gives you INP and CLS broken down by page template, by device class, and by release, instead of one blended number a month after the damage is done.

Gating merges in CI

Lighthouse can run headlessly in a CI pipeline against a budget, failing the build if LCP or CLS regresses past a set threshold on key templates like product detail and checkout (Chrome for Developers — Lighthouse overview). This catches the regression at the pull request, before it reaches the CrUX dataset, not after.

Neither tool replaces the other. CI budgets stop obvious regressions from merging. Field RUM tells you whether the aggregate experience across real devices actually held, which is the number Search Console and your customers both see.

How much this actually affects search rankings

Google's own documentation is direct about this: page experience is not a single dominant signal. "Our core ranking systems look at a variety of signals that align with overall page experience," and Google will still surface the most relevant result "even if the page experience is sub-par" (Google Search Central — Understanding Google Page Experience).

Where it matters most is the tie-break: when two pages are similarly relevant to a query, the one with the better page experience has an edge. Chasing a perfect Core Web Vitals score purely for SEO, past the point where it improves the actual user experience, is a documented case of Google telling you not to bother.

FAQ

Did FID get removed from PageSpeed Insights and Search Console?

Yes. FID stopped being a Core Web Vital on March 12, 2024, and INP took its place in both PageSpeed Insights and the Search Console Core Web Vitals report (web.dev — INP becomes a Core Web Vital on March 12).

What's a good INP score today?

200 milliseconds or less at the 75th percentile of page loads, measured across mobile and desktop (web.dev — Interaction to Next Paint).

Does scrolling count toward INP?

No. Only clicks, taps, and keyboard presses are measured. Scrolling, hovering, and pinch-zoom gestures are explicitly excluded (web.dev — Interaction to Next Paint).

Can a page pass Lighthouse and still fail Core Web Vitals in Search Console?

Yes, routinely. Lighthouse is a single lab run on a simulated device. Search Console's Core Web Vitals report is built from CrUX field data, real users on real devices and networks, aggregated over 28 days (Chrome for Developers — Overview of CrUX).

Do Core Web Vitals guarantee a ranking boost if I pass all three?

No. Google states explicitly that passing Core Web Vitals doesn't guarantee top rankings, and that relevant content wins even when page experience is weaker (Google Search Central — Understanding Google Page Experience).

What's the single most common cause of a poor INP score on a commerce site?

A long JavaScript task on the main thread, most often a full re-render triggered by a filter, a synchronous third-party script, or an unbatched analytics call fired inside a click handler (web.dev — Optimize Interaction to Next Paint).

References

From the Destm engineering archive. For current work on this topic, start at Solutions or the blog.