# Stale-while-revalidate at the edge: deploys without the loading spinner | Edge Commerce Journal

Source: https://edgecommercejournal.com/blog/2026-10-11-edge-stale-while-revalidate-deploys.html

Oct 11, 2026 - Edge Commerce Journal


Every storefront deploy creates a gap: the old origin is gone, the new one is cold, and shoppers arrive in the middle. Stale-while-revalidate at the edge closes that gap by serving the previous cached page instantly while the fresh version builds quietly in the background.

## The deploy window nobody measures

Most teams watch deploy duration on the CI dashboard and call it done when the build passes. Shoppers experience something different. The first requests to a fresh deploy hit cold caches, unwarmed application servers, and empty template caches. Time to first byte spikes for a few minutes, sometimes much longer on large catalogs. If the deploy includes a migration, the origin may be genuinely slower while background jobs catch up. Nobody pages the on-call for this because the site is technically up. But conversion data tells the story: a two-second TTFB regression during a ten-minute deploy window costs real orders on a busy store.

Traditional answers to this problem are heavy. Blue-green deploys keep the old stack warm, but they double infrastructure cost and still need a cache strategy at the cutover. Deploy freezes during peak hours work until the business needs a fix shipped at noon on a Friday. Both approaches treat the origin as the thing shoppers talk to. Stale-while-revalidate flips the assumption: shoppers talk to the edge cache, and the edge decides what freshness means.

## How stale-while-revalidate changes the contract

The HTTP directive is old, but enforcing it at the edge is what makes it practical for commerce. A page is cached with two timers: a freshness lifetime, and a stale window after expiry during which the cached copy can still be served. When a request arrives after the freshness timer but inside the stale window, the edge serves the cached page immediately and fires the origin revalidation asynchronously. The shopper never waits for the origin. The next visitor gets the fresh page.

During a deploy, this means the edge keeps serving the pre-deploy page at full cache speed while the new origin warms up, templates compile, and caches fill. There is no cutover moment from the shopper's perspective. The stale window becomes a shock absorber for exactly the minutes when the origin is at its worst. Once the origin responds quickly again, revalidations complete fast and the cache converges on the new version with no one the wiser.

## Where it fits and where it does not

Stale-while-revalidate is ideal for content that changes on deploy cadence rather than on shopper action: category pages, product listing templates, editorial content, navigation fragments. It is a poor fit for anything transactional. Cart state, pricing with active promotions, and inventory counts should never be served stale to the wrong shopper, and edge logic must exclude them from this treatment explicitly. The most common implementation mistake is applying a generous stale window site-wide instead of scoping it per content type.

Pricing deserves special care. A stale price shown for thirty seconds during a deploy is a customer service incident if the promotion just ended. The fix is to keep price and inventory fragments on short or zero stale windows while letting the page shell ride the longer one. Edge-side includes or fragmented caching make this practical: the cacheable shell revalidates lazily while the dynamic fragments always go to the origin.

## Tuning the timers

Three numbers matter. The freshness lifetime should reflect how often the content genuinely changes between deploys; for most storefront templates, minutes to an hour is right. The stale window should cover the worst-case deploy warmup, which teams consistently underestimate. Measure actual origin p99 during your last three deploys and set the window to twice that, with a sane ceiling. The third number is the origin timeout for the background revalidation: if the new origin is struggling, the edge should not queue unlimited revalidations. A short timeout with the stale copy retained beats a pileup of slow background fetches.

Also plan for the failure mode where the new origin is not just slow but broken. A stale window that outlasts your rollback decision gives you options: the edge keeps serving the old page while you roll back, and shoppers never see the broken version. This only works if your monitoring distinguishes "serving stale during deploy" from "origin is down," so instrument the revalidation path, not just the shopper-facing response.

## The takeaway

Deploys are the one time you know the origin will be at its worst, and they are the one time shoppers keep arriving at full speed. Stale-while-revalidate at the edge decouples those two facts. The page the shopper sees is always fast; the origin gets the time it needs to become correct. Set the timers from measured deploy behavior, keep transactional fragments out of the stale path, and the next Friday deploy stops being a conversion event.