Caching HTML at the edge without serving stale carts

Most teams cache static assets at the CDN and stop there. Images, scripts and stylesheets are served from the edge, while every HTML request still travels to the origin server, runs through the application and hits the database. For content sites and stores, that HTML request is often the slowest part of the page load, and it directly delays Largest Contentful Paint. Caching HTML at the edge can take Time to First Byte from several hundred milliseconds to a few dozen. It can also, if done carelessly, show one customer another customer's cart. This is how we get the speed without the incident.

Decide what is cacheable

We start by classifying every route on the site into three groups.

• Public and identical for everyone: home, category, product, article and landing pages for anonymous visitors. These are the prime candidates.
• Public with small personal fragments: the same pages with a cart count, a greeting or a recently viewed list. Cacheable, if the personal parts are separated out.
• Private: cart, checkout, account pages, search results with personal filters and anything behind a login. Never cached at the shared edge.

On a typical e-commerce site, the first two groups account for 85 to 95 percent of HTML requests. That is the traffic edge caching can serve without touching the origin.

Get the cache key right

The cache key decides which requests share a cached response. Too broad, and users see content meant for someone else. Too narrow, and the cache hit rate collapses. Our defaults:

1. Include host, path and the query parameters that change content, such as pagination and filters.
2. Exclude tracking parameters like campaign tags and click identifiers, which otherwise create a separate cache entry for every ad click.
3. Include a small number of meaningful variants where they change the page, such as country or currency, preferably from a dedicated header or cookie rather than the entire cookie string.
4. Bypass the cache entirely when a session or login cookie is present, unless the page has been specifically designed for authenticated caching.

The tracking parameter rule alone often doubles the hit rate. We have seen sites where more than half of all HTML requests carried unique campaign parameters, each one a guaranteed cache miss.

The most dangerous line in a CDN configuration is the one that caches a page while ignoring the cookie that made it personal.

Separate personal content from the page

The cleanest approach is to make cached HTML genuinely anonymous and load personal fragments separately. The cart count, account link state and personalized recommendations are fetched from a small uncached endpoint after the page renders, or rendered at the edge with a worker that fills in a placeholder. The main HTML stays identical for everyone and stays cached.

This requires discipline in the application. Every template needs to be checked for anything that reads the session. On a recent WordPress and WooCommerce build, we found three places where a greeting or cart total was rendered server-side into otherwise public pages. Each was moved to a client-side fragment before caching was switched on.

We also set Cache-Control: private, no-store explicitly on every response that must not be cached, and have the CDN honor it. Defaults are where leaks happen, so we never rely on them.

Freshness: purging and revalidation

Cached HTML is only useful if it is fresh enough. We combine two strategies.

• Event-driven purging. When a product, price or article changes, the application purges the affected URLs or cache tags. Tag-based purging, where each response carries tags like product-4821 and collection-shoes, lets one update invalidate every page that shows that product.
• Short time-to-live with stale-while-revalidate. Pages are cached for a short period, often one to five minutes, and the CDN serves the stale copy while fetching a fresh one in the background. Users almost never wait for the origin, and content is never more than a few minutes out of date.

Cache-Control: public, max-age=0, s-maxage=300, stale-while-revalidate=600
Surrogate-Key: product-4821 collection-shoes home

Inventory and prices deserve special attention. For fast-moving stock, we avoid caching exact stock counts in HTML and fetch availability separately, so a cached page never promises something that has sold out.

Measuring the result

We track cache hit ratio for HTML, origin requests per second and Time to First Byte from real user monitoring, segmented by template and country. On a recent content-heavy retail site, moving from asset-only caching to edge HTML caching raised the HTML hit ratio from near zero to about 88 percent. Median TTFB for visitors outside the origin's region dropped from roughly 700 milliseconds to under 100, and 75th percentile LCP improved by around 600 milliseconds. Origin load fell enough that the client moved to smaller servers, which covered the cost of the work within a few months.

We also test the unhappy paths before launch: logging in and out, adding to cart from a cached page, switching currency, and purging during high traffic. Each of these is a place where caching bugs hide.

Edge caching is a core part of our CDN configuration service. Because it changes how the application renders, it often goes hand in hand with site speed optimization, and for sites that need the origin itself to be faster we pair it with managed cloud hosting.

Make your origin the exception

If most of your HTML still comes from the origin on every request, there is probably a large speed gain waiting at the edge. Tell us about your stack and we will send a fixed-price quote within 24 hours.