Core Web Vitals

How often do AI answers bring up Core Web Vitals?

Almost never. In the 30 days to 4 October 2026, the ChatGPT and Perplexity answers our workspace collected numbered 4,524, read over the Attensira MCP. One of them used the term. It was a Perplexity answer to "AI search optimization for seed-stage startups" on 2 October, and it put Core Web Vitals in a single line: "fix crawl errors, improve Core Web Vitals, ensure mobile-first UX, and implement structured data".

That line gets the weight about right. The engines treat page experience as one item of technical hygiene, next to crawlability and markup, not as a lever on its own. The answer did not name Attensira, and none of the six sources it cited was ours.

The reason is in how AI crawlers read a page. They fetch the HTML and do not render it the way Chrome does for a person, so Largest Contentful Paint and layout shift never happen for them. A page that paints in under a second and one that takes four look much the same to GPTBot, as long as the text is in the HTML. Core Web Vitals matter for the people who arrive, and for Google's ranking among many other signals.

What are Core Web Vitals?

Three metrics Google uses to measure page experience for real users, defined on web.dev:

• Largest Contentful Paint (LCP)

  Measures

  how fast the main content appears

  Good

  within 2.5 s

• Interaction to Next Paint (INP)

  Measures

  how fast the page responds to taps, clicks and keys

  Good

  200 ms or less

• Cumulative Layout Shift (CLS)

  Measures

  how much the layout jumps while loading

  Good

  0.1 or less

Google judges each metric at the 75th percentile of real page loads, separately on mobile and desktop: a page passes when that percentile meets the "good" threshold. INP replaced First Input Delay as the responsiveness metric in 2024.

How are Core Web Vitals measured?

Two ways, and they answer different questions:

• Field data. Collected from real Chrome users and published in the Chrome UX Report. This is what Google uses, and what Search Console's Core Web Vitals report shows, grouped by URL pattern. See Google Search Console.
• Lab data. A controlled load in a tool such as Lighthouse or a scripted browser. Repeatable and good for debugging, but it reflects one device and one network.

When the two disagree, trust the field data for ranking questions and the lab data for finding the cause.

Do Core Web Vitals matter for AI search?

Less than for classic search, and indirectly:

• Google's AI features draw on its index. AI Overviews use pages that are indexed and snippet-eligible. Page experience is one input to Google's ranking among many, so very poor vitals can lower a page's chances of being a candidate. See AI Overview.
• AI crawlers fetch, they do not render. Attensira's own documentation on AI traffic notes that AI crawlers do not execute JavaScript. What matters to them is a fast server response and content present in the HTML. See crawling and indexing.
• People still arrive. When an AI answer does send a click, a fast, stable page keeps the visitor. That is where the vitals pay off.

What are the objections about Core Web Vitals and AI search?

"Perfect scores will lift our rankings." Passing the thresholds removes a handicap. Going from good to perfect rarely moves anything.

"Our lab score is 100, so we pass." Google evaluates field data. A fast lab run on a fast machine can hide a slow experience on real phones.

"Speed is all that matters for AI crawlers." Content in the HTML matters more. A fast page that renders its text only in the browser can be empty to a crawler.

"We need to fix vitals before content." If you already pass, content is the better use of the week.

How does Attensira handle page experience?

Attensira's crew can fix what holds a page back, such as an oversized hero image, a layout that jumps or text that only appears after scripts run, and ship the change to your repository or CMS after your approval. Its focus stays on the outcome: whether AI answers and Google name and cite you, measured per engine with the sample size. A faster page that is still not quoted has not moved that number. Publishing to GitHub shows how a fix arrives as a pull request you review.