Core Web Vitals in AI Search: What Still Matters

Q: What are the current Core Web Vitals thresholds?

Google's documented good thresholds, measured at the 75th percentile of real users: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint 200 milliseconds or less, and Cumulative Layout Shift 0.1 or less. INP replaced First Input Delay as the responsiveness vital in March 2024.

Published June 18, 2026 · ClickRadius Institute

Core Web Vitals were designed to measure human experience: how fast a page paints, how quickly it responds to a tap, how much it jumps around while loading. AI engines are not humans — they do not tap, scroll or get annoyed. So does performance still matter when a growing share of your "visitors" are retrieval systems composing answers? Yes — but through a different causal chain than the one the SEO industry usually recites, and understanding the real chain changes what you optimize first.

The vitals, current as of 2026

Google's Core Web Vitals documentation defines three field metrics, each with a "good" threshold that must be met at the 75th percentile of real-user experiences:

Largest Contentful Paint (LCP) — main content painted within 2.5 seconds.
Interaction to Next Paint (INP) — visual response to user interaction within 200 milliseconds. INP replaced First Input Delay in March 2024; sites still quoting FID targets are auditing against a retired metric.
Cumulative Layout Shift (CLS) — layout shift score of 0.1 or less.

Field data comes from the Chrome User Experience Report (CrUX), which is also what Search Console's Core Web Vitals report surfaces. Lab tools (Lighthouse, PageSpeed Insights' lab section) diagnose; CrUX decides. The distinction matters because a fast dev machine on fiber tells you nothing about your 75th-percentile mobile user.

On the classic-search side, the stakes are documented but modest: Google has confirmed page experience is used in ranking, while repeatedly cautioning that great content with poor vitals can still rank — its page experience documentation frames vitals as one consideration among many, a tiebreaker rather than a title fight. The interesting question is what happens to that calculus when the consumer of your page is a machine.

How performance actually reaches AI visibility: four links

Link 1: You inherit the index's standards

Most AI answers are not composed from a fresh crawl of the open web; they are composed from existing search indexes. Google's generative surfaces — AI Overviews, now on roughly 48% of queries per third-party trackers, and AI Mode, made the default experience at I/O in May 2026 — draw on the Googlebot index. Copilot draws on Bing's. Whatever influence page experience has on your standing in those indexes flows through, unchanged, to the answers built on top of them. There is no separate "AI index" where performance is forgiven.

Link 2: Crawl economics

Google's crawl-budget documentation is explicit that server responsiveness affects crawl capacity: fast, healthy sites get crawled more; slow responses and server errors throttle crawling. For AI visibility this compounds, because — as covered in Content Freshness and Decay for AI — the index's copy of your page is what answers quote. A site crawled reluctantly is a site whose AI-visible version is chronically out of date.

Link 3: Fetcher timeouts and error rates

AI crawlers and user-triggered fetchers (ChatGPT-User, Perplexity-User and peers) operate with finite patience — requests time out, slow origins get sampled less, and a fetch that fails at answer-composition time is a citation that goes to someone else right now. Unlike Googlebot, these fetchers publish no patience specifications, which is an argument for margin: an origin that responds in 300ms has slack everywhere; one that takes 8 seconds is gambling on every consumer's timeout policy.

Link 4: The rendering gap — the largest AI-specific factor

Googlebot renders JavaScript in a headless Chromium. The documented AI crawlers largely do not: GPTBot, ClaudeBot and PerplexityBot fetch raw HTML, and content that exists only after client-side hydration is effectively invisible to them. This is where "performance" for AI diverges from Core Web Vitals entirely — a client-rendered React site can post excellent LCP for humans while serving AI fetchers an empty <div id="root">.

For human visitors, the question is "how fast does the content appear?" For AI fetchers, it is "does the content appear in the HTTP response at all?" A site can score green on the first question and zero on the second.— ClickRadius Institute analysis

The test costs one minute: curl your five most important URLs and search the response body for your prices, service descriptions and FAQ answers. If they are absent, no vitals optimization matters until rendering strategy — server-side rendering, static generation, or prerendering for bots — puts substance on the wire.

Why the human side still carries the load

It would be convenient for a GEO article to conclude that machines have made human performance obsolete. The opposite is true, for a reason specific to AI search: the clicks that survive are worth more. With zero-click searches at an estimated 60% overall — and roughly 93% within AI Mode by third-party measurement — the visitors who do click through an AI citation are unusually qualified: they read a synthesized answer, saw your brand attributed, and chose to go deeper. Greeting that visitor with a 6-second load and a lurching layout wastes the scarcest asset in the funnel. Google's own published case-study collection on web.dev has documented for years that cutting load time measurably lifts conversion — Vodafone, for instance, reported an 8% sales lift from a 31% LCP improvement. Performance stopped being a traffic-acquisition tactic and became a traffic-conversion necessity.

AI search shrinks your click volume and raises your click value. Page speed used to influence how many visitors you got; now it decides what you harvest from the few who still arrive.— ClickRadius Institute analysis

The priority list, reordered for the AI era

Where a performance budget should go, in order of AI-visibility impact per hour of work:

Raw-HTML completeness. Citation-critical content present in the initial response (SSR/SSG/prerender). Nothing else on this list matters to an AI fetcher if this fails.
Origin response time (TTFB). Sub-second time-to-first-byte through caching, a CDN, and honest server capacity. This is the shared root of crawl budget, fetcher success and human LCP alike.
Error-rate hygiene. 5xx spikes and timeout storms throttle crawlers for weeks. Monitor status codes per user agent so you notice when it is Googlebot or an AI fetcher receiving errors, not just users.
LCP for humans — compress and right-size the hero image, preload it, eliminate render-blocking CSS/JS in the critical path.
CLS and INP — dimension attributes on media, reserved slots for ads/embeds, breaking up long main-thread tasks. Real money for conversion, minor for machines.
Page weight discipline. HTTP Archive's Web Almanac has tracked median page weight past two megabytes — most of it script and imagery that neither humans on mid-range phones nor token-limited machine readers benefit from. Lighter pages make every other item on this list easier.

Note what is not high on the list: chasing a perfect 100 Lighthouse score. Lab scores are diagnostic instruments, not outcomes. A site at CrUX "good" across all three vitals with complete raw HTML has captured essentially all of the visibility value; the remaining polish is for your conversion rate, not your citations.

The rendering decision, by site type

Since raw-HTML completeness tops the priority list, it deserves a concrete decision guide. The question for each site is not "SSR or not" in the abstract but "what is the cheapest path to complete HTML given what we run today?"

WordPress, and classic server-rendered CMSs (most small-business sites). You already pass. PHP templates emit complete HTML by default; your risks are narrower — page builders or plugins that inject key content (pricing tables, FAQ accordions) via JavaScript after load. Curl-test the specific pages built with those tools rather than assuming.
Next.js / Nuxt / SvelteKit and similar meta-frameworks. The capability is built in; the failure mode is per-page choices. A team that fetches product data client-side in a useEffect has opted that content out of machine visibility regardless of framework. Audit per template: server-render anything citable, hydrate interactivity on top.
Single-page applications (bare React/Vue/Angular). The hard case. Options in ascending effort: prerender critical marketing/content routes to static HTML at build time; add a prerendering service that serves bot traffic a rendered snapshot; or migrate the content-bearing routes to a meta-framework. Dynamic rendering (different content path for bots) works but adds an infrastructure component you must monitor forever — a snapshot service that silently breaks fails exactly like a CDN bot-block: invisibly.
Headless commerce and JAMstack. Usually fine for templated pages generated at build, with the same client-side-data trap: live inventory and pricing fetched in the browser are invisible to non-rendering fetchers. Where the numbers matter for citations, bake the latest build-time values into the HTML and let the client update them after load.

In every case the acceptance test is identical and non-negotiable: curl the URL, grep for the facts. Frameworks, plugins and vendors all claim SSR support; the response body is the only witness that cannot be mistaken.

Diagnostics: the honest toolkit

CrUX / Search Console — the field truth on all three vitals, per URL group.
PageSpeed Insights — field data when available plus lab diagnosis in one view.
curl or "view source" — the raw-HTML completeness test AI fetchers effectively administer on every visit.
Server logs filtered by verified bot user agents — response times and status codes served specifically to Googlebot, Bingbot, GPTBot, ClaudeBot, PerplexityBot (verification methods in AI Crawlers Explained). Sites are routinely fast for users and slow for bots — bot traffic often bypasses the CDN cache paths users hit.
A recurring scan — vitals and rendering regress with every redesign, plugin and tag-manager addition; quarterly checks catch drift while it is one commit old. ClickRadius runs technical checks like these continuously as part of its six-category readiness score.

Frequently asked questions

Do AI engines like ChatGPT or Perplexity measure Core Web Vitals?

There is no evidence that AI engines run Core Web Vitals assessments. But most AI answers are composed from search indexes — Google's and Bing's — where page experience and crawl efficiency do operate, and AI fetchers impose their own hard constraints: timeouts, limited rendering, raw-HTML parsing. Performance reaches AI visibility indirectly but genuinely.

What are the current Core Web Vitals thresholds?

Google's documented "good" thresholds, measured at the 75th percentile of real users: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint 200 milliseconds or less, and Cumulative Layout Shift 0.1 or less. INP replaced First Input Delay as the responsiveness vital in March 2024.

If AI crawlers don't render JavaScript, should I abandon my JS framework?

No — change how it delivers, not what you build with. Server-side rendering, static generation or prerendering puts complete HTML on the wire while keeping the framework developer experience. The test is simple: fetch your key pages with curl and check whether the content you want cited is present in the response body.

Curious whether AI fetchers see a complete site or an empty shell? A free AI Readiness Score checks rendering, response health and technical trust alongside your content and entity signals — plans on the pricing page.