INP and Core Web Vitals in the AI Search Era: What Is Actually Documented

Interaction to Next Paint (INP) replaced First Input Delay as a Core Web Vital in March 2024, and the honest picture two years later is this: 77% of websites pass the 200ms good threshold on mobile, up from 74% in 2024, but the top 1,000 most popular sites still only pass at 63%, because rich interactivity and heavy third-party scripts make good INP genuinely hard at scale.

This post covers what INP measures, the verified thresholds, the real connections between Core Web Vitals and AI search (which are narrower than most content implies), and practical fixes. We also cover what our cookie banner CLS post found about layout shift suppressing AI citations, since CLS and INP sit in the same performance layer and the mechanism matters.

What INP measures and the exact thresholds

INP observes the latency of every click, tap, and keyboard interaction during a user’s visit. It reports the worst interaction (with an allowance to ignore statistical outliers on pages with many interactions). The metric covers three phases: input delay (time before the event handler runs), processing time (the handler itself), and presentation delay (time until the browser paints the next frame).

The thresholds from the primary web.dev documentation are:

• Good: INP at or below 200 milliseconds.
• Needs improvement: INP above 200 milliseconds and at or below 500 milliseconds.
• Poor: INP above 500 milliseconds.

Google uses the 75th percentile of real-user INP across all interactions on a page. That means 75% of your users’ visits must have an INP at or below your reported score. A single slow interaction on a rarely-used modal does not tank your score, but a slow interaction on a frequently-used filter or form field does.

INP replaced FID (First Input Delay) because FID only measured the first interaction on a page. A page could pass FID while feeling sluggish on every subsequent click. INP captures the full interaction lifecycle, which is more honest about real user experience.

Where the web stands on INP in 2025

The 2025 Web Almanac (HTTP Archive CrUX data, July 2025) reports that 77% of websites achieve good INP scores on mobile, up from 74% in 2024. Desktop performance is 97%, a long-standing gap explained by more powerful hardware and stable network conditions. The 20-percentage-point mobile-desktop gap has narrowed by 3 points since 2024.

The 23% of mobile sites that fail INP are disproportionately complex: e-commerce platforms with heavy checkout flows, media sites with interactive ad units, and SaaS marketing sites with modal-heavy UX. The top 1,000 most visited sites pass at only 63% on mobile, despite having the engineering resources to optimize. Rich interactivity genuinely trades against INP scores.

The secondary-page decline is worth flagging. Secondary pages accumulate third-party scripts, filters, and interactive widgets as users move deeper into a site. Home pages see optimization investment; secondary pages often do not.

INP and AI search: what is actually documented

CWV is a documented Google ranking signal for classic organic search. The relationship between Core Web Vitals and AI search citations is less direct, and the honest position is that no AI engine has published documentation saying CWV scores are a citation factor.

The real connections are three narrower mechanisms:

• Render success: AI crawlers that partially render pages (or that rely on Google’s rendering pipeline) get better content extraction from fast-loading, stable pages. A page that takes 8 seconds to complete its main-thread work is more likely to be captured in an incomplete state.
• Google AI Mode: AI Mode is built on Google’s infrastructure and inherits Google’s quality signals, which include CWV. A page that fails Core Web Vitals for classic search is also a weaker candidate for AI Mode citations, though this is our inference from Google’s published guidance rather than an explicit AI Mode citation rule.
• User trust post-click: AI engines that surface links depend on users clicking through and finding the page functional. A page with a 500ms INP on its primary interactive element creates a poor experience for users who arrive from an AI citation, which affects the indirect signals that feed back into citation quality over time.

Where the evidence ends: we do not have data showing that improving INP from 300ms to 150ms directly increases citation frequency on ChatGPT or Perplexity. We are honest about that gap. The case for INP optimization in an AI search context is real but indirect.

What our cookie-banner research found

Our cookie banner CLS post documented a specific mechanism where CLS failure suppresses AI citations. Across audited sites, 31% had cookie banner implementations actively suppressing AI citations. The mechanism was not INP but CLS: late-loading banner scripts caused layout shift from near-zero to 0.3 or higher, and when AI Mode crawlers encountered these pages, the banner overlay dominated the chunked content that got embedded.

The CLS-to-citation link is better documented than the INP-to-citation link, because CLS directly affects what content gets parsed and chunked. A full-page overlay that the crawler sees before consent is given makes the cookie banner text the primary chunk, not the article content. INP does not affect what content is visible in the initial HTML; CLS and rendering order do.

The practical lesson: fix CLS (especially from cookie banners, ad slots, and font swaps) before spending time on INP for AI search purposes. Both matter for Google’s classic ranking signal, but CLS has a more direct path to AI citation impact through the content-visibility mechanism.

The three components of INP latency

Diagnosing INP requires understanding which of the three phases is the bottleneck:

• Input delay: The time from user gesture to the first event handler running. Caused by long tasks on the main thread that block event processing. Fix by breaking long tasks (any task over 50ms) into smaller chunks.
• Processing time: Time the event handler itself takes to execute. Caused by expensive DOM queries, complex calculations, or synchronous network calls inside the handler. Fix by deferring non-critical work out of the handler.
• Presentation delay: Time from handler completion to the browser painting the next frame. Often the dominant phase on poor-performing pages. Caused by layout thrash (reading then writing DOM geometry in a loop), large DOM updates, or expensive style recalculations.

Use Chrome DevTools Performance panel to identify which phase dominates. Record the slow interaction, find the frame in the trace, and look at the longest task within it. The task category (script evaluation, layout, style recalculation, paint) tells you which fix to apply first.

Practical INP fixes

The highest-leverage fixes in rough priority order:

1. Break long tasks. Any JavaScript task over 50ms blocks the main thread and delays event handling. Use scheduler.yield() (or setTimeout(fn, 0) as a fallback) to yield to the browser between work chunks. This is the fix that moves the needle most on input delay.
2. Audit and defer third-party scripts. Analytics tags, chat widgets, A/B testing scripts, and ad tags all run on the main thread. Load them after the first user interaction or after a short timeout. Removing one slow third-party script often produces a larger INP improvement than any first-party optimization.
3. Avoid hydration bottlenecks. React, Vue, and Angular hydration runs synchronously on the main thread. Heavy component trees that hydrate on load block interactions during the first few seconds. Use lazy hydration (hydrate on interaction, not on load) for components below the fold.
4. Use CSS containment. contain: layout on interactive components limits layout recalculation to that subtree, reducing presentation delay when the component changes state.
5. Move expensive work to Web Workers. Calculations that do not need DOM access (parsing, sorting, filtering large datasets) can run off the main thread entirely. The main thread handles the result, not the computation.

Measuring INP in production

Two tools give you INP data from real users:

PageSpeed Insights shows CrUX field data for your URL if enough Chrome user data exists for that page. It reports INP at the 75th percentile alongside LCP and CLS. The CrUX dataset covers only pages with sufficient Chrome user traffic, so low-traffic pages may show no field data. PageSpeed Insights also runs a Lighthouse lab audit, which estimates INP based on simulated interactions but is less reliable than field data for INP specifically, because the interactions are synthetic.

Chrome User Experience Report (CrUX) is the underlying dataset. You can access it directly via the CrUX API for URL-level and origin-level INP breakdowns, or via PageSpeed Insights for the simplified view. The 28-day rolling window means recent optimizations take about a month to fully appear in the data.

For sites where CrUX data is thin (low traffic, new pages), Real User Monitoring (RUM) using the web-vitals JavaScript library gives session-level INP breakdowns. The library captures the worst interaction and the interaction type, which lets you identify whether slow INP is concentrated on a specific element or interaction pattern.

How INP connects to AI page speed research

Our AI search page speed correlation research found that page speed affects AI citation rates through crawl efficiency and render completeness, not through a direct ranking signal from AI engines. Fast pages complete their render within the time window that AI crawlers allocate before moving on. Slow pages get partially parsed, partially chunked, and partially embedded.

INP is not a crawl-time metric (it requires user interaction), so it does not directly affect what crawlers see during their visit. But it is correlated with overall page quality: pages with poor INP tend to have heavy main-thread JavaScript, which is also what slows down initial HTML delivery (TTFB and FCP), which does directly affect crawl quality.

For a complete technical picture, INP optimization belongs in the same workstream as semantic HTML structure, structured data, and content chunking, not as its own isolated AI search lever. The case for it is that a well-optimized page that passes all three CWVs is a better candidate across every signal channel than one that fails half of them.

For agentic AI browsers that do execute JavaScript (a growing category as AI agents become more capable), INP becomes directly relevant: an agent browsing your site to extract information will experience the same interaction latency a human user would, and a page that hangs on interaction may result in the agent timing out and abandoning the page before extracting the content you want cited.