Does page speed affect whether AI engines cite you?
Page speed affects AI citations, but it behaves like a gate rather than a dial. Discovered Labs' 2026 analysis of page speed and AI crawlability found pages with a First Contentful Paint under 0.4 seconds averaged 6.7 citations while pages above 1.13 seconds averaged 2.1, roughly a threefold difference. The mechanism is that most AI crawlers fetch raw HTML under tight time and compute budgets and never execute JavaScript: Vercel and MERJ's analysis of AI crawler traffic, covering more than 500 million GPTBot fetches, recorded zero JavaScript execution. A slow server response therefore costs the fetch rather than a few ranking points. What speed cannot do is make a page worth quoting, so the correct order is to clear the gate, then fix the vocabulary and the structure that decide whether the page is chosen.
Does page speed affect whether AI engines cite you?
Page speed affects whether AI engines cite you, and the measured difference is large, but the relationship is a threshold rather than a continuous curve. Discovered Labs' 2026 analysis of page speed and AI crawlability found that pages with a First Contentful Paint under 0.4 seconds averaged 6.7 citations, while pages taking longer than 1.13 seconds averaged 2.1, a difference of roughly three times. The same firm's regression on two million citations across 10,000 pages found no significant independent effect from real-user LCP, INP and CLS or from synthetic Lighthouse scores once domain was controlled for, which is the result you would expect if speed works as a gate rather than a ranking factor.
Read that as a gate. The pages at the slow end are not being marginally down-weighted; many of them are not being read in full, or at all, because the fetch did not complete inside the budget the crawler allowed it. Once a page is comfortably inside the threshold, making it faster still does not appear to buy additional citations.
The distinction matters because it changes what the fix is worth. Taking a page from 3 seconds to 0.8 seconds can move it from invisible to eligible, which is a large change. Taking a page from 0.6 seconds to 0.3 seconds is engineering work with no citation case behind it.
It also changes who the work belongs to. Clearing the gate is usually a server and delivery problem: time to first byte, caching, how much HTML the page ships. Being chosen once through the gate is a content problem, and no amount of speed substitutes for it.
Worth separating from all of this is the human performance argument. Fast pages are better for buyers and better for classic search rankings, and those reasons stand on their own. This article is only about the citation question.
Why does load time matter to a crawler that never renders the page?
Load time matters to a non-rendering crawler because the crawler still has to receive the HTML, and it gives up if that takes too long. The crawlers behind the major engines fetch the document and extract text from the markup they are served, which means the relevant measurement is how fast your server produces HTML rather than how fast a browser finishes painting it.
The non-rendering part is well documented. Vercel and MERJ's analysis of AI crawler traffic, covering more than 500 million GPTBot fetches, found zero JavaScript execution: GPTBot downloaded JavaScript files on 11.5% of fetches and ClaudeBot on 23.84%, and neither ran them. Our guide on whether AI crawlers read JavaScript goes through what that means for a single-page application.
Put those two facts together and the speed metric that matters shifts. First Contentful Paint is a browser measurement, and the reason it correlates with citations is that it is downstream of the thing a crawler does care about: how long the server took to return the document, and how large that document was. A page with a fast server and heavy client-side rendering will look slow in a browser test and fetch quickly for a crawler, and a page with a slow database query behind it will fail for both.
The budget side is harder to observe from outside and easy to reason about. A crawler fetching at the scale of the web cannot wait on any individual page, so a request that stalls is abandoned rather than queued indefinitely. A page that times out does not register as a slow page in anybody's report. It simply is not in the corpus.
The practical read is that time to first byte and HTML payload size are the two numbers to watch, and they are the two that standard performance reports tend to bury under rendering metrics.
How fast does a page have to be to get cited?
A page has to return its HTML fast enough to clear the crawler's budget, and the published thresholds cluster tightly enough to be actionable. The table below collects the figures worth measuring against. Each row names where the number came from, because the only thing worse than a slow page is a performance budget nobody can source.
| Measurement | The figure | Where it comes from |
|---|---|---|
| First Contentful Paint under 0.4 seconds | Averaged 6.7 citations | Discovered Labs, 2026 |
| First Contentful Paint over 1.13 seconds | Averaged 2.1 citations | Discovered Labs, 2026 |
| Core Web Vitals and Lighthouse scores | No significant independent effect once domain is controlled for | Discovered Labs, 2026 |
| JavaScript execution by GPTBot | Zero, across 500 million fetches | Vercel and MERJ, 2024 |
Translating those into a working budget gives three targets. Get the server returning HTML in well under a second, keep the HTML document small enough to parse without pagination, and make sure the content a buyer would quote is present in that first document rather than fetched afterwards. The third one is the most commonly violated on B2B sites and the least visible in a performance score.
The thresholds are not magic numbers and should not be treated as a specification. Discovered Labs' 2026 analysis of page speed and AI crawlability is observational: fast pages are cited more, and fast pages also tend to belong to teams who do other things well. What makes the finding worth acting on anyway is that the mechanism is independently documented, so the correlation has a plausible cause rather than only a p-value.
One pattern worth checking specifically is a site that is fast on its marketing pages and slow on the pages that answer questions. Documentation portals, search-driven resource libraries and anything behind an application framework are the usual offenders, and they are frequently the pages with the most citable material on them.
Is page speed more important than what is on the page?
Page speed is less important than what is on the page, and treating it as the main lever is the common mistake once a team has a performance report in hand. Speed decides whether the page is read. The words decide whether it is used.
The evidence on relative weight is unambiguous. Discovered Labs' 2026 citation analysis, built on more than two million citations using domain fixed effects and double machine learning, found content alignment was the only page-level signal with a causal effect that survived controlling for domain authority, at an effect size of β=+0.37. Most other signals disappeared once the domain was controlled for.
Selection is where fast pages still lose. AirOps' 2026 retrieval study examined 548,534 pages retrieved across 15,000 ChatGPT prompts and found only 15% of retrieved pages were cited, so the large majority of pages that were fetched successfully, quickly and in full were then discarded. Speed got them into the room and something else decided the outcome.
Structure sits between the two and is cheap. The ConvertMate GEO Benchmark 2026, an observational study of 12,500 queries across 8,000 domains, found 68.7% of cited pages used a strict H1 to H2 to H3 hierarchy, and the same study found 83% of AI citations came from pages outside Google's organic top 10, which is the clearest evidence that this is not the same game as classic ranking.
A defensible order of work therefore puts speed third. Make the page reachable and readable without JavaScript, make sure the vocabulary matches how buyers ask, then clear the performance gate, then improve the structure and sourcing. Our methodology page sets out the weights behind that ordering.
How do you check what an AI crawler actually gets from your page?
Checking what an AI crawler gets takes two measurements and neither of them is a Lighthouse score. The first is a plain fetch of the page with JavaScript disabled, looking at the HTML that comes back: if the content a buyer would quote is missing from that document, the page is failing before speed is relevant.
The second is the time to first byte on that same fetch, measured from outside your own network. Running it from a developer machine on the office connection flatters a slow origin, and running it through a browser-based performance tool mixes in rendering work no crawler performs. Repeat it on your slowest important page rather than your homepage, which is usually the best-optimised page on any site.
Server logs are the third source and the only one that shows what actually happened. Filtering for the AI crawler user agents shows which of your pages they request, how often, and what status codes they got, which turns a theory about timeouts into a count. Our guide to checking whether AI can read your website sets out the full procedure.
Two findings in those logs are worth acting on immediately. A high rate of non-200 responses to AI crawlers usually means a rate limiter or a bot-protection rule is involved rather than a performance problem, and the fix is a configuration change. Pages that are never requested at all are usually unreachable by link structure rather than slow.
What none of these checks will tell you is whether the page is being cited, because a page can be fetched perfectly and never used. That is a different measurement, taken from the answers rather than from the site, and our guide to tracking AI visibility covers how to run it.
What should you fix first if your pages are slow?
Fix the server response first, before anything that happens in the browser, because that is the part a crawler experiences. Caching the HTML, moving to a static or server-rendered output for content pages, and removing the synchronous database or API calls that sit in front of a page render are the changes that move time to first byte, and they are usually the cheapest.
Shrink the document next. Pages that ship tens of thousands of lines of markup, inline data payloads or embedded JSON for a client-side framework take longer to transfer and parse, and the content a crawler needs may sit a long way down. Keeping the main answer high in the document is worth doing for a second reason: it is the part most likely to be read whatever the budget.
Deal with bot protection explicitly rather than by accident. Rate limiters, challenge pages and firewall rules frequently block or throttle AI crawlers without anyone deciding to, and the symptom looks like a performance problem in a report while being a configuration problem in reality. Our guide on whether to block AI crawlers covers the decision properly.
Leave image optimisation, font loading and layout shift for the human-performance backlog. All three are worth doing, none of them changes what a non-rendering crawler receives, and treating them as AEO work is how a quarter gets spent on something a buyer will never notice in an answer.
Once the gate is clear, the remaining question is whether your pages are chosen rather than whether they are reachable, and that is answered from the answers. A free visibility assessment runs your buyer questions across ChatGPT, Claude, Perplexity and Google AI Overviews and reports which of your pages the engines actually cited, which tells you whether speed was ever the binding constraint.
What else do people ask about page speed and AI citations?
Do Core Web Vitals affect AI citations directly?
Core Web Vitals are browser measurements and AI crawlers do not run a browser, so they matter indirectly: the parts of them driven by server response and document size affect whether a fetch completes, and the parts driven by layout shift and interaction delay do not. Discovered Labs' 2026 analysis found pages under 0.4 seconds First Contentful Paint averaged 6.7 citations against 2.1 above 1.13 seconds, which is the observable version of that effect. Optimise for time to first byte and HTML size rather than for the composite score.
Will a CDN improve our AI visibility?
A CDN helps if your origin is slow or geographically distant from where the crawlers fetch, and it does nothing for the reasons most pages are not cited. It is a reasonable change to make for human visitors and classic search regardless. Where a CDN actively hurts is when its bot-protection layer challenges or rate-limits AI crawlers, which is a configuration decision worth checking explicitly rather than assuming.
Our pages score 95 on Lighthouse and we still are not cited. Why?
A high Lighthouse score means the page performs well in a browser, which is not the test a crawler applies. The two common explanations are that the content only exists after JavaScript runs, so the fetched HTML is nearly empty, and that the page is fetched fine but never chosen. AirOps' 2026 retrieval study found that only 15% of the 548,534 pages ChatGPT retrieved across 15,000 prompts were cited, so being read and being used are different outcomes.
Does page speed matter equally for every engine?
No, and the difference follows whether the engine renders. Google's crawling infrastructure renders JavaScript, so a slow client-side page can still be indexed there, while GPTBot, ClaudeBot and PerplexityBot read raw HTML, which Vercel and MERJ confirmed across more than 500 million GPTBot fetches with zero JavaScript execution. A site that is visible in Google AI Overviews and absent from ChatGPT frequently has a rendering problem rather than a speed problem.
Should we rebuild our site for speed before doing anything else?
Almost never. A rebuild is the most expensive available fix and it addresses the gate rather than the selection problem that keeps most pages out of answers. Measure first: fetch your important pages without JavaScript, check time to first byte from outside your network, and look at what the engines currently cite. If the content is reaching the crawler and the pages are still not used, a rebuild would have changed nothing.