Cloudflare Cache: Why Your Server Is the Bottleneck

Cloudflare cache is supposed to sit between your visitors and your origin server: a copy of your page held on servers around the world, so a request gets answered from the node nearest the visitor instead of traveling back to you every time. That’s CDN caching, or edge caching if you want the vendor-neutral name for it, and it works the same way whether you’re on Cloudflare or another CDN. With no cache in place, every request, from every human and every bot, hits your origin and waits for it to build the page from scratch. That’s slower, and it’s slower in the exact way that costs you AI traffic.

The telltale sign is a cf-cache-status: DYNAMIC header, or its equivalent on other CDNs: your HTML is being served dynamically, with no CDN cache in front of it. Here’s what that means and how to decide whether to fix it.

Why no edge caching kills AI traffic

Getting cited by ChatGPT, Perplexity, or Google’s AI Mode is a retrieval game, and retrieval starts with a crawler actually fetching your page. AI crawlers are far less patient than humans. They make one request, read whatever comes back, and move on. Reporting from technical SEO practitioners puts AI crawler timeouts under 10 seconds, sometimes less, well below what a browser would tolerate. If your origin is slow to respond, the crawler bails and your page never enters the pool of things an AI engine can cite.

The metric that matters is TTFB, Time to First Byte: how long the visitor waits before your server starts sending the page. Google says most sites should aim for 0.8 seconds or less. TTFB isn’t a Core Web Vitals metric itself, but it’s the floor under Largest Contentful Paint: LCP can never be faster than the first byte. A slow server eats the budget for everything after it, so a bad TTFB drags LCP down with it.

It costs you crawl coverage too. Google says outright that if it can load your pages faster, it might read more content from your site, and crawl health works both ways: respond quickly and Google raises the number of connections it uses; slow down and it backs off. No edge cache means every crawl hit pays full origin render cost, so you get fewer pages crawled per visit. Fewer crawled pages means fewer pages in the index, human or AI.

The upside of closing this gap is mechanical. A cached page skips the origin round trip and the render entirely. TTFB drops from “however long your server takes” to “however long the nearest edge node takes,” usually tens of milliseconds. Every visitor and every crawler gets the fast path.

Which pages should you actually cache?

Cache when:

Your pages are mostly the same for everyone. Marketing pages, blog posts, docs, product pages: content that doesn’t change per visitor is the ideal cache candidate, and it’s exactly the content you want AI to cite.
You’re seeing a slow TTFB or cf-cache-status: DYNAMIC on pages that should be public and static. This is the common case, and it’s usually a config change, not a rewrite.

Think twice when:

The page is genuinely per-user. A logged-in dashboard, a cart, a personalized feed: caching the wrong version and serving it to someone else is a real bug. These pages should stay dynamic, or use a strategy that keys on the user.
You have content that changes by the second and must be exact, like live pricing or inventory. You can still cache these with short TTLs or cache invalidation, but that’s a more careful setup than a blanket rule.
You don’t control the CDN or the headers. If your hosting doesn’t expose cache configuration, this becomes a hosting decision, not a header tweak.

The effort is usually low. The risk is all about scoping: cache the public pages, leave the personalized ones alone. That’s the line to check before you turn it on.

Once you’ve drawn that line, switching caching on is a config change, not a rewrite. Get AI Traffic applies it with enable_edge_caching, which adds a Cloudflare rule marking your HTML cache-eligible without overriding the Cache-Control your origin already sends, so the routes you serve as private stay uncached. Give it 30 to 60 seconds to propagate across the edge before you retest.

Frequently asked questions

How do I check whether Cloudflare cache is actually working? Look at the cf-cache-status response header on any page. HIT means Cloudflare served that request from the edge without touching your origin, which is Cloudflare cache doing its job. DYNAMIC means Cloudflare decided the response wasn’t cacheable and passed it straight through, so your origin paid full cost. If your public, non-personalized pages are consistently DYNAMIC, that’s the gap this fix closes.

What does cf-cache-status: DYNAMIC mean? It means Cloudflare did not cache that response and served it straight from your origin. On Cloudflare, DYNAMIC means the asset wasn’t considered cacheable by default and no rule told it otherwise, so every request pays full origin cost. HIT is what you want: served from the edge.

Is TTFB a Google ranking factor? Not directly. TTFB is not one of the Core Web Vitals. But it sets the floor for Largest Contentful Paint, which is a ranking signal: LCP can never be faster than the first byte. Google also ties crawl rate to how fast your server responds. A slow TTFB hurts you through both, even though Google doesn’t score it on its own.

Why do AI crawlers care more about speed than Google does? Because they’re built to skip slow pages. AI crawlers run tight timeouts and generally don’t execute JavaScript, so they take one quick request and bail if your origin is slow. Googlebot is more patient and renders more. An origin that’s “fine for Google” can still be too slow for ChatGPT or Perplexity to bother with.

Will edge caching break personalized pages? Only if you cache them. The fix scopes caching to pages that are the same for everyone and leaves per-user routes dynamic. Caching is a per-route decision, not an all-or-nothing switch.

Your Cloudflare Cache Is Empty, and Your Server Is the Bottleneck

Why no edge caching kills AI traffic

Which pages should you actually cache?

Frequently asked questions

Sources