Does Page Speed Affect AI Citations?

Yes — page speed affects AI citations: SE Ranking found pages with a First Contentful Paint under 0.4 seconds earned roughly three times more AI citations than slower pages. Crawlers work on budgets and timeouts, so a fast page gets fetched reliably while a slow one risks being throttled or skipped. Speed is part of the access gate, not a nice-to-have.

Does speed really change citation rates?

Yes — speed measurably changes citation rates. SE Ranking's analysis found that pages with a First Contentful Paint under 0.4 seconds earned roughly three times more AI citations than slower pages. That's a large gap for a single technical factor, and it lines up with how crawling works: faster pages are simply fetched more reliably and more completely.

Why does a crawler care about speed?

A crawler cares about speed because it operates on finite time and resource budgets. A fast server lets it fetch more of your pages per crawl window, and it lowers the chance a request times out before your HTML finishes arriving. Slow responses can trigger throttling — the crawler backs off to avoid overloading you — and a request that times out means your content was never read at all. That's the access pillar in its bluntest form: speed is part of whether the crawler can reach your content, not just how pleasant the page feels.

How do you measure it?

Measure server response time with curl — it needs no tools and reflects what a crawler experiences. This prints the timing breakdown, including time to first byte (TTFB) and total time:

# Server timing as a crawler experiences it
curl -s -o /dev/null \
  -w "DNS:    %{time_namelookup}s\nConnect: %{time_connect}s\nTTFB:    %{time_starttransfer}s\nTotal:   %{time_total}s\n" \
  https://yourdomain.com/

DNS:    0.008s
Connect: 0.021s
TTFB:    0.180s
Total:   0.240s

A TTFB well under ~0.2s and a fast total is the goal. For lab metrics including FCP and Largest Contentful Paint, run Lighthouse:

# Lighthouse performance audit (Node required)
npx lighthouse https://yourdomain.com/ --only-categories=performance --view

How do you make pages faster for crawlers?

Make pages faster by cutting server response time and shipping less to render. In rough order of impact for crawlers:

1. 1

   Serve ready HTML

   Use static generation (SSG) or cached server-side rendering so the HTML is complete on first byte — no waiting on client-side assembly.

2. 2

   Put a CDN in front

   Cache and serve pages from edge locations close to the requester to cut network and server time.

3. 3

   Compress responses

   Enable gzip or brotli so HTML, CSS, and JS transfer in fewer bytes.

4. 4

   Cut render-blocking JavaScript

   Ship less JS, defer non-critical scripts, and avoid assembling content client-side.

5. 5

   Optimize images and fonts

   Use modern formats (AVIF/WebP), correct sizing, and preloaded or system fonts.

A minimal cache-and-compress example for nginx — serve static HTML fast and compressed:

# nginx: compress text responses and cache static assets
gzip on;
gzip_types text/html text/css application/javascript application/json;
 
location ~* \.(?:css|js|woff2|avif|webp)$ {
  add_header Cache-Control "public, max-age=31536000, immutable";
}

Where this fits in the Canon

Page speed is the third dimension of the access pillar, alongside permission (robots.txt) and rendering (server-side HTML): a crawler must be allowed in, able to read the content, and able to fetch it before timing out. Fast, ready HTML satisfies all three at once.

Related: why JavaScript breaks AI citation eligibility, server-side vs client-side rendering, and how to check if AI crawlers can read your site.