Core Web Vitals in 2026: INP is the one that bites

Core Web Vitals still matter in 2026, but as a tiebreaker and a user-experience floor rather than a lever that lifts rankings on its own. Google says the metrics align with "what our core ranking systems seek to reward", and also that good scores do not "guarantee that your pages will rank at the top." The metric most sites now struggle with is Interaction to Next Paint (INP), which replaced First Input Delay on March 12, 2024 and measures how quickly a page responds to every click, tap, and keypress, not just the first. JavaScript-heavy sites that load quickly can still fail it badly.

The three metrics and their thresholds

Two details trip people up. First, the scores that count are field data from real Chrome users, collected in the Chrome User Experience Report (CrUX) and assessed at the 75th percentile. A Lighthouse score from your laptop is a diagnostic, not the measurement. Second, INP reports roughly the worst interaction on a page: web.dev explains that for most pages the slowest interaction is the one reported, with one outlier ignored for every 50 interactions on very busy pages.

What Core Web Vitals do for rankings

Google's position is consistent and modest. "Google Search always seeks to show the most relevant content, even if the page experience is sub-par." There is "no single signal" for page experience; core ranking systems "look at a variety of signals that align with overall page experience." In practice that makes the vitals a tiebreaker between pages of similar relevance and quality, and a guard against the kind of experience that sends visitors straight back to the results.

The stronger case for fixing them is your own visitors. A page that takes four seconds to show its main content, or freezes for half a second after every tap, loses people regardless of how it ranks. Treat the vitals as a quality bar for the experience, and the ranking benefit as a bonus.

How the web scores in 2025

The 2025 Web Almanac from HTTP Archive, which analyzes CrUX field data across millions of sites, gives the clearest picture. On mobile, 48 percent of sites passed all three Core Web Vitals, up from 44 percent a year earlier, and 56 percent passed on desktop. Mobile pass rates for the individual metrics were 62 percent for LCP, 77 percent for INP, and 81 percent for CLS. INP improved from 74 percent, and the top 1,000 sites showed the biggest jump, from 53 to 63 percent with good INP.

Read those numbers carefully. LCP has the lowest pass rate overall, so it remains the most common failure. INP looks healthier on average, but the busiest, most interactive sites score worst on it, which is exactly the category of site, rich applications, ecommerce, and dashboards, where a slow response costs the most.

Why INP is the hard one

LCP and CLS usually have known, contained fixes: a properly sized and prioritized hero image, preloaded fonts, and reserved space for images, embeds, and ads. INP problems come from how the page's JavaScript behaves throughout the visit. web.dev breaks each interaction into three parts: input delay, while the browser is busy with other work; processing time, while your event handlers run; and presentation delay, while the browser renders the result. Any of the three can push an interaction past 200 milliseconds.

The usual culprits are long tasks on the main thread, such as large script bundles evaluating, third-party tags, or a framework re-rendering a big component tree on every keystroke; event handlers that do all their work before letting the browser paint; and very large DOMs that are expensive to update. A page can load in under two seconds and still fail INP when someone opens a menu or adds an item to a cart.

The pattern that fixes most slow handlers

The single most useful technique is to give the browser a chance to paint before doing the expensive part of the work. Update the visible state first, then yield to the main thread, then run the rest. web.dev recommends breaking the work in event callbacks into separate tasks for exactly this reason: it lets the next frame, and other interactions, happen sooner.

button.addEventListener("click", async () => {
  showSpinnerAndSelectedState(); // cheap, visible update
  await new Promise((resolve) => setTimeout(resolve, 0)); // yield so the browser can paint
  recalculateTotalsAndSendAnalytics(); // expensive work runs after the frame
});

In React and Next.js apps the same idea shows up in a few common mistakes: storing fast-changing input in state high up the tree so every keystroke re-renders a large page, running filtering or sorting over big lists inside the render path, and loading analytics and chat widgets eagerly on every route. Moving state down, memoizing expensive lists, marking non-urgent updates as transitions, and loading third-party widgets after the page is interactive each remove a slice of the delay.

A practical order of fixes

1. Find out where you actually stand. Check the Core Web Vitals report in Search Console and the CrUX data in PageSpeed Insights for your key templates, not just the homepage.
2. Fix LCP on your highest-traffic templates: serve the main image in the HTML, sized correctly, with high fetch priority, and avoid hiding the main content behind client-side rendering.
3. Fix CLS by giving every image, video, embed, and ad slot explicit dimensions, and by not injecting banners above existing content.
4. For INP, find the slow interactions first. Chrome DevTools and field tools that report interaction attribution show which element and which script were involved.
5. Shorten the work in those handlers: update the screen first and defer the rest, break long tasks into smaller ones that yield to the main thread, and avoid reading layout immediately after changing styles.
6. Reduce JavaScript overall. Remove unused third-party tags, split bundles by route, and render static content on the server so the browser has less to hydrate.
7. Re-check field data after 28 days, the window CrUX reports over, before deciding a fix did not work.

One fix serves two goals. Rendering primary content on the server improves LCP, reduces the JavaScript that hurts INP, and makes the content readable by AI crawlers that do not execute JavaScript. We cover the AI side in which rendering modes AI crawlers can read.

How SEO for AI Agents measures this

The Core Web Vitals check reports two kinds of data side by side and keeps them clearly separate. Field data comes from CrUX at the 75th percentile, the same data Google uses, and it is the only input to the score. Lab data from a single Lighthouse run is shown alongside for diagnosis, labeled as lab, and never affects the score. When a page has too little traffic for its own CrUX record, we fall back to site-wide field data and mark the result medium confidence; when there is no field data at all, the lab result is shown as informational, marked low confidence, and does not affect the score.

Each finding names the metric, the value, the threshold, and the source of the data, so you can confirm it in PageSpeed Insights yourself. The glossary entries on INP, LCP, and CLS explain each metric in more depth.