Core Web Vitals and AI crawlers are usually discussed in the same paragraph for a bad reason: both are about pages being "fast" or "well built", so a sentence that connects them sounds plausible. The connection is real but narrower than the paragraph suggests. Core Web Vitals measure a person’s experience in a browser; an AI crawler fetching HTML is not a browser, and no engine has published a Core Web Vitals threshold for citation.
This article separates the two, then says where they genuinely overlap. The overlap is worth knowing because it points at work that helps both; the separation is worth knowing because selling one as the other is the kind of overclaim this site argues against.
What the three metrics measure
| Metric | What it measures | Good threshold (field data) |
|---|---|---|
| LCP | How long until the largest visible element is rendered. | 2.5 seconds or less. |
| INP | How responsive the page is to interaction, across the visit. | 200 milliseconds or less. |
| CLS | How much the layout shifts unexpectedly while loading. | 0.1 or less. |
The thresholds are Google’s, evaluated on field data from real users (the Chrome UX Report) rather than on a single lab run. That matters for this article: the score describes what people experienced, not what a machine can fetch.
What an AI crawler actually does
The agents this scanner tests fetch a URL, receive a response, and work with what came back. Some may render pages; none promises to. What none of them does is load your page in a browser, run Lighthouse, wait for INP, or measure layout shift. A perfect CLS is not an input to their decision, because they do not compute it.
What they can experience is the delivery side: a server that takes ten seconds to answer, a response that times out, or an HTML body so large that fetching it is expensive. Those are real, and they are not the same measurements as LCP or INP.
Where they genuinely connect
- The same cause: client-side rendering. A page that assembles its content in the browser is often slow to paint and empty in the response. Fixing it with server-rendering improves both LCP and the no-JS body — one change, two audiences.
- The same cause: JavaScript weight. A large bundle delays the main thread and also means the HTML response carries more code than content. Less JS helps a person and a parser.
- The same delivery path. TTFB is part of LCP; it is also how long a crawler waits for the first byte. A slow origin is slow for both, and the fixes overlap at the edge even though the metrics do not.
- The same content cost. Serving images at full resolution and loading fonts you do not use hurts CWV; serving an enormous HTML document hurts a parser’s token budget. Different numbers, same principle: send less of what is not needed.
The overlap is a set of shared causes. It is not a single score. A site can have green Core Web Vitals and a JavaScript-only article, or a plain server-rendered page with poor CLS. The easiest way to see that is to measure both separately.
What this site scores, and what it does not
The delivery dimension has two rules, and both are deliberately coarse. viewport (1 point) checks that a meta viewport tag is present; the rule page admits it does not read the value, because judging whether the configuration is usable needs a rendering engine. payload (1 point) checks that the uncompressed HTML is under 500 KB; the rule page admits it counts only the document, so a 400 KB page with three megabytes of images passes.
That is honest and limited. The scanner does not run Lighthouse and does not report LCP, INP or CLS. A site that wants those numbers should use the field data from the Chrome UX Report, or a lab tool for a single page; the two are different questions and neither is a citation metric.
How to measure the two separately
# 1. Browser experience: field data (needs a CrUX/PSI key) or PageSpeed Insights
# https://pagespeed.web.dev/analysis?url=https%3A%2F%2Fyour-domain.com%2F
# 2. What a crawler receives, in bytes and time
curl -sS -o /dev/null -w "%{time_starttransfer} %{size_download}\n" https://your-domain.com/page/
# 3. Does the content need JavaScript? (the first 1000 characters of the body)
curl -sS https://your-domain.com/page/ | sed 's/<[^>]*>/ /g' | tr -s ' ' | head -c 1000
# 4. Are the heavy assets separate requests?
curl -sS https://your-domain.com/page/ | grep -oE '<(img|script|link)[^>]+(src|href)="[^"]+"' | wc -lCommand 2 is the overlap: TTFB and bytes matter to both. Command 3 is the part CWV cannot tell you: whether the content is in the response at all. Command 1 is the part a crawler cannot tell you: how the page felt to a person.
The overclaims to avoid
- "Fast pages get cited more." Plausible as a tendency, not established as a rule; no engine publishes it, and the causal path is unclear.
- "CWV is a GEO ranking factor." No. It is a page-experience signal for search, and an AI crawler does not compute it.
- "INP matters to GPTBot." INP measures interaction; a crawler does not interact with the page.
- "A green Lighthouse score means AI can read the page." Lighthouse runs a browser; the question is what the server returned.
The useful framing
Treat Core Web Vitals as user-experience engineering and treat crawler access as a separate discipline that shares some causes. Where the causes overlap — client rendering, JS weight, TTFB, payload — one fix serves both. Where they do not, do not borrow the authority of one metric for the other.
The rest of this series keeps making the same move: name the mechanism, measure the thing that actually matters, and say what the measurement does not cover. "Fast" is not a mechanism, and "cited" is not a metric.