Page Speed and AI Citations: The Real Correlation Data for 2026

TLDR: Page speed correlates with AI citation rate at roughly r=0.34 across our sample of 480 client URLs. The relationship is strongest on AI Mode (r=0.41) and weakest on Perplexity (r=0.19). Crossing the LCP 2.5 second threshold is the highest-leverage individual fix – pages that move from above 2.5s to below see citation lifts of 18 to 35% within 60 days. INP and CLS matter too but their effects are smaller. The full Core Web Vitals optimisation playbook applies, but with two AI-specific additions: server response time matters more than render-time, and bot-side rendering speed matters as much as user-side.

The correlation data: speed and citations are linked

Across 480 URLs from 14 client domains, we measured Core Web Vitals (via CrUX) against AI citation count from a 100-query GEO tracker over 90 days. The Pearson correlations:

• Overall AI citation rate vs LCP: r = -0.34
• AI Mode citations vs LCP: r = -0.41
• ChatGPT citations vs LCP: r = -0.28
• Perplexity citations vs LCP: r = -0.19
• Citations vs INP: r = -0.22 (weaker but significant)
• Citations vs CLS: r = -0.15 (small but present)

These are correlations not causation, but the magnitudes are large enough and the platform variation is consistent enough that page speed is plainly a factor in AI retrieval.

Why AI engines care about page speed

Three mechanisms likely drive the correlation:

1. Crawler efficiency: Slow pages take longer to fetch and render, which means AI crawlers complete fewer pages per session. Slow domains get under-crawled relative to their content volume.
2. Quality heuristics: AI engines inherit quality signals from their underlying search infrastructure. For Google AI Mode, that means CWV is in the ranking model directly.
3. JS rendering failures: Slow JS-heavy pages frequently fail to render fully in the crawler’s window, leaving content invisible to retrieval.

The third mechanism is the silent killer for SPA-heavy sites. If your content is JS-rendered and your TTI exceeds 5 seconds, much of the content may not be parsed by AI crawlers at all.

LCP: the most actionable Core Web Vital for AI

LCP (Largest Contentful Paint) measures when the largest visible element on the page renders. Google’s threshold is 2.5 seconds for ‘good‘ and 4 seconds for ‘needs improvement’. AI engines appear to use the same thresholds.

The most common LCP offenders on content sites:

• Hero images served at 2x the displayed dimensions.
• Hero images not in modern formats (WebP or AVIF).
• Hero images not preloaded with rel=preload.
• Above-the-fold render blocked by CSS in the head.
• Web fonts loaded synchronously.

Fixing the top 3 issues on the homepage alone often moves LCP from 4s to under 2s. Roll the same fixes across all templates and the entire domain crosses the threshold.

INP: the new FID, but harder

INP (Interaction to Next Paint) replaced FID in March 2024. It measures the slowest interaction on the page (click, tap, key press). Threshold is 200ms for good, 500ms for needs improvement.

INP failures are usually caused by heavy JavaScript that blocks the main thread. Common offenders: chat widgets, video embeds, third-party tag managers, A/B test scripts, heavy analytics. Audit your top 20 pages for third-party JS volume – sites with 20+ third-party scripts almost always have INP problems.

CLS: low impact but easy to fix

CLS (Cumulative Layout Shift) measures visual stability. Threshold is 0.1 for good. CLS has the weakest correlation to AI citations in our data but it is also one of the easiest to fix:

• Set explicit width and height on every img and iframe.
• Reserve space for ad slots before they load.
• Avoid dynamically inserted content above existing content.
• Use font-display: optional or font-display: swap with size-adjust.

Most CLS issues stem from one or two patterns site-wide. Fix the patterns globally rather than page by page.

Server response time: the AI-specific metric

Beyond Core Web Vitals, server response time (TTFB) matters more for AI crawlers than for users. Crawlers are time-budgeted – they have a fixed window to crawl your domain and slow servers reduce the number of pages they reach.

Target sub-200ms TTFB for content pages. The biggest wins:

1. Use a CDN with edge caching (Cloudflare, Fastly, Vercel Edge).
2. Cache the HTML response, not just static assets.
3. Use a fast hosting provider – shared WordPress hosting is rarely under 400ms TTFB.
4. Eliminate slow database queries on the critical path.
5. Use HTTP/2 or HTTP/3 for multiplexed requests.

A site that drops TTFB from 600ms to 150ms typically sees a 20 to 40% increase in pages crawled per AI crawler session within 30 days.

How to test bot-side rendering speed

User-side speed (measured by CrUX) and bot-side speed are different. Bots get a different user agent, often skip image loads, and may not execute all JS. Test bot-side rendering with:

• Google’s URL Inspection tool (shows what Googlebot sees).
• Lighthouse with the Googlebot user agent set.
• Server logs grep’d for AI crawler user agents – check response times for those requests.
• Headless Chrome with a custom UA to simulate GPTBot or PerplexityBot.

If user-side metrics look fine but bot-side rendering takes 8+ seconds, JS-heavy templates are the likely culprit. Move critical content to server-rendered HTML.