Edge Caching Strategies for React Apps

The Cache-Control response header controls how long Cloudflare (and other CDNs) cache your SSR responses. The key directives are: max-age (browser cache), s-maxage (CDN/shared cache duration), and stale-while-revalidate (serve stale content while revalidating in the background).

s-maxage is respected by shared caches (CDNs) while max-age is for browser caches. For SSR pages you typically want s-maxage=60 (CDN caches for 60 seconds) and max-age=0 (browser always revalidates), so all users get reasonably fresh content from the edge cache.

Adding stale-while-revalidate=30 to your Cache-Control header tells Cloudflare to serve the cached page instantly while fetching a fresh version in the background. Users always get a fast response; the maximum staleness is s-maxage + stale-while-revalidate seconds.

Personalized content (based on user session or locale) must not be served from a shared cache to the wrong user. The Vary: Cookie header tells Cloudflare to treat each unique Cookie value as a separate cache entry, preventing the wrong user's data from being served to another user.

A common pattern is to check for a session cookie in the Worker before deciding whether to use the cache. If a session cookie is present, bypass the cache entirely and render a personalized response. If no session cookie, the page is public and can be served from cache.

Cloudflare KV is a globally distributed key-value store that stores data close to users. You can cache rendered HTML in KV — store the rendered page as a value with a TTL, and future requests read from KV at the edge rather than re-rendering with React.

KV reads are fast because data is replicated to the edge PoP serving the request — typical read latency is under 5ms. KV writes, however, use eventual consistency: a write in one region propagates to all global PoPs within 60 seconds, meaning some users may briefly see stale data.

Cloudflare R2 is an S3-compatible object storage service with no egress fees. It is suited for larger assets that don't fit in KV: WASM modules, pre-rendered OG images, large JSON datasets. Workers access R2 via bindings just like KV.

Cloudflare Enterprise supports cache tags: you tag a response with Cache-Tag: product-42, and when product 42 changes, you call Cloudflare's API to purge all responses tagged with product-42. This enables surgical cache invalidation without purging your entire cache.

When you deploy a new version of your Worker, existing cached HTML may reference old JS bundle filenames. A robust strategy is to include the deploy version in your cache keys, or to use versioned bundle filenames (via Vite's content hashing) so old HTML always references valid, cached JS files.

A Worker that caches SSR HTML in KV follows this pattern: compute a cache key from the URL (and optionally locale), check KV for a hit, return cached HTML instantly if found. On a miss, render with React, store the result in KV with a TTL, then return the freshly rendered HTML.

What consistency model does Cloudflare KV use for writes?

Edge caching for React apps layers multiple strategies: Cache-Control s-maxage for CDN caching of public pages, Vary: Cookie to prevent personalized responses from being shared, KV for edge-cached rendered HTML, and cache tags for granular invalidation. KV's eventual consistency model means write propagation takes up to 60 seconds — design your TTLs and invalidation strategy accordingly.