← Back to blog

Technical SEO · July 20, 2026 · 8 min read

Caching Layers Explained for SEO: Browser, CDN, and Edge — What Each Does for Speed

A layered breakdown of caching for SEO — how browser, CDN, and edge cache each cut TTFB and improve Core Web Vitals scores.

By FluxWriter Team

Caching for SEO is not a single toggle — it is a stack. Browser cache, CDN cache, and edge cache each sit at a different layer of the delivery chain, each controls different latency windows, and each maps to different Core Web Vitals signals. Treating them as interchangeable is why most "speed optimizations" stall at a plateau. This guide separates the layers, explains what each one actually does to crawl efficiency and CWV scores, and tells you where to spend configuration time first.

Why Cache Layers Matter for SEO Separately

Google's ranking systems use page experience signals — primarily Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP) — alongside TTFB as a diagnostic metric. TTFB itself is not a direct ranking factor, but it eats into LCP budget directly: if the server takes 800 ms to send the first byte, your LCP target of sub-2.5 s is already under pressure before the browser renders a single pixel.

Each cache layer cuts TTFB from a different angle:

These are not redundant. Each layer answers a distinct question.

Browser Cache: The Repeat-Visit Lever

Browser cache stores assets — JS, CSS, fonts, images — on the user's local disk after the first load. On a repeat visit, those assets load from disk in single-digit milliseconds rather than from the network.

What It Controls

• Repeat-visit LCP: If the hero image is cached, it renders from disk. Sub-100 ms retrieval vs. 300-900 ms network round-trip.
• INP: Cached JS means the main thread is not blocked by network fetch on return visits. Interaction responsiveness improves.
• CLS: Fonts and layout-critical CSS served from disk mean no layout recalculation while assets arrive late.

Browser cache does nothing for Googlebot unless it supports conditional requests (ETag / If-None-Match). Googlebot does honor ETags and Last-Modified headers to avoid re-downloading unchanged resources, which reduces crawl bandwidth and can improve crawl frequency on large sites.

Configuration Priorities

Set Cache-Control: max-age aggressively on versioned assets. A build pipeline that fingerprints filenames (e.g., app.3f8a2c.js) lets you set max-age=31536000, immutable safely because the URL changes on each deploy.

For HTML pages, use Cache-Control: no-cache paired with a strong ETag. This forces a revalidation request but serves from cache if the resource has not changed — zero-byte response with a 304 status.

# Static assets with cache-busting filenames
Cache-Control: max-age=31536000, immutable

# HTML documents
Cache-Control: no-cache
ETag: "abc123"

A common mistake: setting max-age=86400 on un-versioned CSS files. A deployment pushes new styles, but users see the old stylesheet for up to 24 hours because the filename did not change.

CDN Cache: The First-Visit LCP Multiplier

A CDN caches full HTTP responses at edge Points of Presence (PoPs) distributed globally. When a user requests a page, the CDN intercepts the request at the nearest PoP and serves the cached response without touching your origin server.

What It Controls

• TTFB on first visit: A CDN HIT means the response comes from a server 10-30 ms away rather than your origin across an ocean. Cloudflare's published data shows median TTFB reductions of 60-80% for cached responses on intercontinental routes.
• LCP: For text-heavy pages where the LCP element is rendered HTML (a heading or paragraph), a fast TTFB directly accelerates LCP.
• Crawl budget indirectly: Googlebot crawls from distributed locations. A CDN serving cached HTML to Googlebot's crawlers reduces origin load and lets you handle higher crawl rates without throttling.

Cache HIT Rate: The Metric That Matters

A CDN cache that is 40% HIT rate is doing less than half the job. Low HIT rates usually trace to:

1. Query string fragmentation: ?utm_source=email and ?utm_source=newsletter are treated as different cache keys by default. Strip or normalize UTM parameters at the CDN layer.
2. Too many Vary header combinations: Vary: Accept-Encoding, Accept-Language, Cookie can fracture the cache into thousands of variants. Strip the Cookie header for pages that do not require authentication.
3. Short TTLs on HTML: Many defaults set HTML TTL to 0 or 60 s. A news site with articles that update rarely is burning CDN capacity by re-fetching every minute. Set HTML TTL to 5-60 minutes with stale-while-revalidate.

Stale-While-Revalidate at the CDN Layer

Cache-Control: s-maxage=300, stale-while-revalidate=60 tells the CDN to serve a stale cached copy for up to 60 seconds while it fetches a fresh copy in the background. This eliminates the cache-miss latency spike that users hit during the revalidation window. For SEO, this means Googlebot almost never sees a slow origin response.

Edge Cache / Application Cache: The Origin Shield

Edge cache (sometimes called origin shield or application cache) sits one layer closer to your server, often as a second CDN tier or a reverse proxy like Varnish. It absorbs cache misses that make it past the CDN before they hit your application server.

What It Controls

• Origin server stability under crawl load: Googlebot can spike request rates during a crawl wave. An origin shield absorbs repeated requests for the same resource within its TTL window, collapsing many simultaneous requests into one origin fetch.
• TTFB for cache misses: When a CDN PoP misses, it queries the origin shield before the actual server. A cache hit at the shield returns a response from infrastructure that is already low-latency.
• Dynamic page acceleration: Some edge platforms (Cloudflare Workers, Fastly Compute) can cache fragments — a cached navigation bar, a dynamic but slowly-changing sidebar — and stitch them together at the edge. This keeps TTFBs low even for pages that cannot be fully cached.

When to Use It

Origin shielding makes the most sense when:

• You have a high-traffic site with global CDN PoPs generating many cache misses.
• Your origin server is geographically centralized.
• You run a CMS (WordPress, Drupal) where full-page cache at the CDN is not always feasible due to cookie-driven personalization.

A mid-size e-commerce site serving 500k pages per day might see 40% of CDN misses absorbed by origin shield rather than hitting the PHP application server. That translates to lower CPU load, fewer timeouts, and more stable TTFB for both users and crawlers.

Mapping Cache Layers to Core Web Vitals

The following priorities reflect where configuration effort yields the most measurable CWV improvement:

LCP (target < 2.5 s) CDN cache HIT rate is the primary lever for first-visit LCP. Browser cache handles repeat visits. Prioritize CDN TTL and cache HIT optimization over image compression if your HIT rate is below 70%.

INP (target < 200 ms) Browser cache of JavaScript bundles is the main lever. Cached scripts execute immediately without network delay. CDN has less direct impact here since INP occurs post-load.

CLS (target < 0.1) Browser-cached fonts and CSS eliminate late-arriving layout shifts. Set font-display: swap with preload for first visits and rely on browser cache for returns.

TTFB (diagnostic, target < 800 ms) All three layers contribute. A CDN cache HIT typically achieves sub-50 ms TTFB. A CDN miss with origin shield hit typically achieves 100-300 ms. A full origin round-trip is where TTFB climbs past 500 ms.

Configuration Sequence: Where to Start

Rather than optimizing all three layers simultaneously, work down the stack:

1. Fix browser cache headers first — requires only HTTP header changes, zero infrastructure cost, immediate repeat-visit gains.
2. Audit CDN HIT rate — pull CDN analytics for your top 50 URLs by traffic. If HIT rate is below 80% on static pages, diagnose cache fragmentation.
3. Add stale-while-revalidate — implement on HTML at the CDN layer with a 5-30 minute TTL.
4. Enable origin shield — only necessary if CDN miss volume creates origin load spikes. Most sites under 1M daily pageviews do not need it.
5. Add edge workers for fragment caching — advanced, appropriate for dynamic sites with cacheable sections.

FAQ

Does caching affect how often Google crawls my site?

Yes, indirectly. Faster response times (lower TTFB) allow Googlebot to crawl more pages per unit of time within the same crawl budget. Sites with consistently sub-200 ms TTFB often see crawl frequency increase as Googlebot can process more URLs without hitting server resource limits. Origin shields and high CDN HIT rates contribute to this by preventing origin overload during crawl bursts.

Should I cache HTML pages at the CDN if they contain personalized content?

No — but you can often cache more than you think. Most personalization is confined to small page fragments (login state, cart count, recommendations). Serve the page skeleton from CDN cache and load personalized elements via JavaScript after initial render. This keeps CDN HIT rates high while delivering personalized content. Alternatively, Cloudflare Workers and similar edge runtimes can vary cache by cookie segment without fracturing the main cache key.

What is the right TTL for HTML pages on a blog?

For blog posts that rarely change after publication, a CDN TTL of 1-24 hours with stale-while-revalidate=300 is reasonable. For news articles, 1-5 minutes is more appropriate to reflect updates promptly. Index pages (homepage, category pages) should be shorter — 1-5 minutes — since they aggregate fresh content. Always pair longer TTLs with a cache purge mechanism triggered by CMS publish events.

Practical Takeaway

Start with browser cache headers — specifically immutable on versioned assets and no-cache + ETag on HTML. Then pull your CDN analytics and address HIT rate before touching origin infrastructure. Most TTFB and LCP problems trace to low CDN HIT rates or missing browser cache directives, not server hardware.

If you are producing content at scale and want to ensure the pages you are optimizing are worth caching in the first place, tools like FluxWriter can help prioritize which content drives crawl activity and engagement, so infrastructure investment goes toward the URLs that matter most.

← All posts