Does Page Speed Matter for AI Search?
By the alphaa team — we run AI-visibility scans across thousands of businesses and fetch their pages the way AI crawlers do. Last updated 25 August 2026.
Short answer: Yes, but it is a different kind of speed than the one your SEO report measures. AI engines do not appear to score you on Core Web Vitals — nobody has shown that a Largest Contentful Paint of 3.1s versus 1.8s changes whether ChatGPT names your business. What does matter is whether a crawler receives your complete content in the initial HTML response, fast enough that it does not time out or give up. Speed is a gating factor for retrieval, not a ranking factor for quality. A slow page that still returns full HTML is usually fine. A fast-feeling page that returns an empty shell and fills it in with JavaScript half a second later is invisible.
Two different meanings of "speed"
Separating these is most of the answer:
- Perceived speed (Core Web Vitals). LCP, INP, CLS — metrics about how a page feels to a human in a browser. They involve layout, images, fonts, and interactivity. Google uses them as a minor ranking input. They are largely irrelevant to a crawler, which never paints anything.
- Fetch speed (TTFB and total response time). How long your server takes to return the bytes, and whether those bytes contain the content. This is the one that decides whether an AI engine reads you at all.
A page can score 98 on a Lighthouse audit and be useless to an assistant, and score 40 and be read perfectly. The two measurements are not testing the same thing.
What actually happens when an AI engine fetches your page
There are two distinct moments where speed can cost you, and they behave differently.
The indexing crawl. Bots such as GPTBot, ClaudeBot, PerplexityBot and Google-Extended fetch pages on their own schedule to build a corpus. These are patient — a slow response mostly costs you crawl budget rather than inclusion. But persistent slowness has a compounding effect: crawlers back off from origins that respond slowly or return errors under load, so your pages get fetched less often, and your newer content takes longer to be seen. If freshness matters to your category, that lag is the real cost. We cover which bots exist and how to admit them in the AI crawlers and robots.txt guide.
The live retrieval fetch. This is the moment that hurts. When someone asks an assistant a question and it browses the web to answer, it fetches a handful of candidate pages while a user waits. That request operates under a tight practical budget — a few seconds at most — and a page that has not responded gets dropped in favour of one that has. There is no queue and no retry. Your competitor's page, which answered in 400ms, gets summarised instead. Engines do not publish their timeout values, so treat any specific number you see quoted as a guess; the safe posture is to be comfortably fast rather than to aim at an assumed threshold.
The failure that looks like slowness but is not
By far the most common problem we see is not a slow server. It is a fast server returning an empty page. A client-rendered site sends a minimal HTML shell, then JavaScript fetches the content and injects it. A human perceives this as quick. A crawler that does not execute JavaScript sees a document with no words in it — and several AI crawlers do not execute JavaScript, or do so inconsistently. This is a rendering problem wearing a performance costume, and it is covered in detail in how JavaScript rendering affects AI crawlers.
The reason it belongs in a speed article is that teams reach for the wrong fix. They compress images and buy a bigger server, the Lighthouse score improves, and nothing changes in AI answers — because the content was never in the response to begin with.
How to test what a crawler actually gets
Skip the performance dashboards for this. Use curl, which behaves like a simple crawler: it makes one request, runs no JavaScript, and shows you exactly what came back.
- Measure time to first byte and total time.
curl -o /dev/null -s -w "ttfb:%{time_starttransfer}s total:%{time_total}s\n" https://yoursite.com/your-page
Under ~0.8s total is comfortable. Over ~2.5s, fix it. Over 5s, you are being dropped from live retrieval. - Check the content is actually there.
curl -s https://yoursite.com/your-page | grep -c "a distinctive sentence from the page"
A zero means the sentence is not in the HTML, and no amount of speed tuning will help. - Test as a bot, not as a browser.
curl -s -A "GPTBot/1.0" -o /dev/null -w "%{http_code} %{time_total}s\n" https://yoursite.com/your-page
If this returns 403, 429, or a challenge page while a normal browser fetch returns 200, your CDN or bot protection is blocking AI crawlers. That is the most severe finding on this list and it has nothing to do with speed. - Test cold, not warm. Request a page nobody has visited recently. Cached pages lie; the crawler frequently hits an uncached URL.
- Test from far away. If your server is in Virginia and your CDN is not caching HTML, a crawler egressing from elsewhere pays the full round trip every time.
What to fix, in order
- Bot blocking. Verify GPTBot, ClaudeBot, PerplexityBot and friends get a 200. Aggressive WAF rules and "protect against AI scrapers" toggles are switched on by default at some hosts.
- Content in the initial HTML. Server-side render or statically generate the pages you want cited. This is the highest-value change on the list for most sites.
- Time to first byte. Cache HTML at the edge, fix the slow database query on your template, and stop rendering pages on demand that could be built at deploy time.
- Redirect chains. Each hop is another round trip inside the same budget. Point links at final URLs; collapse http → www → https chains into one redirect.
- Reliability under load. Intermittent 5xx responses are worse than consistent slowness, because a crawler treats them as a reason to come back less often.
- Image and font optimisation. Worth doing for your human visitors and for Google. Close to irrelevant for an AI crawler reading text.
Questions we get asked
Do Core Web Vitals affect AI Overviews?
Indirectly at most. AI Overviews draw heavily on pages that already rank in Google's index, and Core Web Vitals are a small ranking input there — so there is a chain of influence, but it runs through conventional ranking rather than through any AI-specific evaluation. Do not expect a Vitals improvement to move your citation rate on its own.
Is a slow site penalised by AI engines?
There is no evidence of a penalty in the SEO sense. The mechanism is exclusion by timeout during live retrieval and reduced crawl frequency over time — both practical consequences, not a quality score.
Does a CDN help?
Yes, if it caches HTML rather than only static assets, and if its bot rules allow AI crawlers through. A CDN configured to block unknown user agents makes your AI visibility worse while making your speed report look better.
What about very large pages?
Page weight matters less than you would think for text extraction, but a 2MB HTML document full of inline scripts and tracking payloads takes longer to transfer and buries your actual content. Keeping the readable substance high in the document is a reasonable habit; it is not a magic threshold.
How much of AI visibility is technical at all?
Honestly, a minority of it. Being fetchable is a prerequisite, not an advantage — once your pages are readable, what decides whether you get named is what your content says and what other sources say about you. See what sources AI engines actually cite.
The bottom line
Treat speed as a gate, not a lever. Your job is to make sure a crawler can get your complete content, in one request, without JavaScript, without being blocked, in well under a second — and then stop optimising, because past that point the returns collapse and the real work is elsewhere. Test with curl, not with a performance score, because the performance score is measuring an experience no AI engine ever has.