E-commerce Page Caching and Origin Resilience

Storefront speed is a revenue concern. Faster pages help shoppers move from discovery to purchase, while slow or unavailable pages can lose the sale. In a large catalog, popular pages may already be cached, but less-visited products and newly updated promotions can still make shoppers wait for the origin to build them. Preparing more of the catalog ahead of demand and keeping eligible pages available during outages helps protect those opportunities to buy.

How Harper keeps storefront pages fast and available

Harper sits behind the existing CDN and combines page-serving logic, stored content, and refresh rules. Teams can cache complete pages, reuse page shells, and optionally prepare updated pages before anyone requests them. Application rules control each page type’s cache lifetime, or TTL, and when it should refresh. Teams can size the page store to cover more of the catalog’s long tail, extending fast delivery beyond the most popular products while keeping the existing commerce platform in place.

An eligible request can return a prepared page from the user's region or reuse a stored shell and fill in changing details on the fly. The shell preserves the reusable structure, reducing the work needed to assemble each response. Locale, currency, and other page-changing attributes distinguish stored versions. If no usable copy exists, Harper fetches the origin. Private content stays out of shared copies, and cart and checkout continue to their backing services.

When content changes, a publishing integration can retire the affected copies for refill on demand or trigger an optional refresh and prebuild process. That process fetches or rebuilds the updated pages, stores approved versions, and coordinates the corresponding CDN purge. If preparation finishes before the next visit, even the first shopper after publishing can receive a ready page. Teams choose the pages and variants to prepare, rather than rebuilding the whole catalog after every change.

Retention and freshness serve different purposes. Teams can keep more pages stored while deciding separately how long each version is fresh enough to serve. During an origin outage, a configured policy can serve approved last-known-good pages within an allowed age. That keeps products discoverable and helps prevent an infrastructure failure from becoming lost revenue. When transaction services remain available, shoppers can continue toward a purchase. Live availability and checkout still depend on their own services.

Fabric manages regional replication, routing, and failover, adding a serving layer independent of the storefront origin. To bring page delivery closer to a new market, select a region and confirm deployment. Teams can expand in a few clicks, and sessions are automatically routed around unavailable regions. The same cluster can also run search, redirects, and personalization alongside page caching.

Alternatively, relying on the CDN and storefront origin

Many teams start with their CDN’s caching, TTL, and purge rules. Cached requests return quickly, while misses and excluded requests reach the origin. Some CDN platforms also support retained-content fallback, warming, and programmable page composition. The choice depends on how well the selected setup supports the catalog’s page coverage, storage needs, and application-specific refresh rules.

A high cache hit rate can hide slow visits across the long tail. Popular products may account for most cached requests even when much of the catalog is not cached. Shoppers exploring those other pages still wait for origin work, creating more chances to abandon the journey. Teams can add prebuilding, page composition, or regional cache services to the basic path shown above, with coordination across publishing, storage, routing, and the application.

Where catalog size and updates add work

A large catalog multiplies the pages and variants to retain and refresh. Short lifetimes or broad purges can send shoppers back to a slow origin, while overly long lifetimes can leave old offers visible. During an outage, pages without a usable fallback can become unavailable altogether. Harper brings storage and page policy together so teams can prepare more of the catalog, keep offers current, and reduce the visits exposed to those delays and failures.

Why Harper matters

• More opportunities to convert. Faster pages help shoppers keep moving toward a purchase. Reuse complete pages or shells close to shoppers, and optionally prepare updates before the first visit.
• Speed across more of the catalog. Retain and refresh more long-tail pages so less-visited products can offer the same fast start as bestsellers.
• Protect revenue during disruption. Approved fallback pages keep browsing available when the origin fails. Fabric routes around unavailable regions, helping preserve shopping journeys and sales when checkout remains available.
• Less repeated origin work. Reuse page structure and fetch only changing details, reducing the load of serving each visit.
• Simpler global expansion. Add serving regions in a few clicks to bring fast page delivery closer to more shoppers.

Speed can make a commercial difference. The Milliseconds Make Millions study observed an 8.4% increase in retail conversion alongside a 0.1-second improvement across four mobile speed metrics throughout the journey.

Related solutions

Harper Site Cache (GitHub) provides configurable origins, page rules, cache lifetimes, and targeted invalidation. It is a starting point for the caching layer. Add and test the retained-page outage policy required by the storefront.

Full-page caching starter (GitHub) offers a smaller reference for reusing page content on Harper.

Plan for freshness and useful fallback

Define separate rules for freshness, storage retention, and outage fallback. Include each page-changing attribute in the stored version, and keep private data out of shared pages and shells. Identify which shell details need live checks. Publishing integration must coordinate Harper copies, retained fallback versions, and CDN entries.

For proactive preparation, connect publishing events to a bounded refresh job. Prioritize page variants, control build concurrency, and confirm the new version is ready before marking it available. Budget storage and replication for retained content. Cache expiration alone does not rebuild pages, and a shell that needs a live source still waits for that source.

Define fallback coverage, maximum age, and the errors or timeouts that trigger it. If no suitable copy exists, return the chosen degraded experience. Keep transaction-critical price and availability checks with the commerce system, and retain existing CDN and security controls.

Start with one set of storefront pages

Pilot popular and less-visited product, category, and campaign pages. Compare complete-page caching, shell reuse, and optional prebuilding. Track catalog coverage and cache hit rate separately, then compare page speed, abandonment, conversion, and revenue per visit across cached pages, misses, and first visits after updates. Measure origin work, storage, and delivery cost alongside those results. Test publishing changes, private content, build failures, regional failover, and outage recovery before expanding.

Bring your catalog, page-speed and conversion data, and incident history to a Harper storefront resilience workshop. Identify where faster pages and stronger outage coverage can protect more revenue.

‍