Frontend Development 11 min read

Client‑Side and Edge Caching Strategies for Membership Pages

The article outlines client‑cache and client‑snapshot techniques alongside an edge‑node ER‑cache that stores the first HTML chunk, explains a three‑layer routing model, and describes a head‑cache strategy with dynamic resource exclusion, skeleton UI snapshots, configurable switches, and per‑page cache durations to boost performance while preserving content freshness for membership pages.

DaTaobao Tech
DaTaobao Tech
DaTaobao Tech
Client‑Side and Edge Caching Strategies for Membership Pages

The document introduces a set of page‑white‑screen caching solutions based on client containers, called client‑cache, and an edge‑node solution called ER‑cache that caches the first HTML chunk to reduce origin latency.

It explains the concepts of client‑cache, client‑snapshot, and ER‑cache. Client‑cache stores various fragments on the client, while client‑snapshot stores rendered HTML fragments. ER‑cache caches the first chunk at CDN edges using keys such as static resource version, client type, and query parameters.

The membership page routing model consists of three layers: page, module, and render. The gateway determines the target page, then delivers all static resources and module information for that page. Modules are rendered independently and streamed.

Key challenges arise when integrating these caching schemes with membership business logic: the first‑chunk ER‑cache can serve the wrong user’s resources, and client‑snapshot can retain stale content after a user’s status changes (e.g., non‑member to member).

Because full first‑chunk caching proved unreliable, a head‑cache approach was adopted: dynamic user‑specific resources are excluded from cache, while shared static resources are cached. This reduces the response size and allows the client to start executing global scripts and styles earlier.

Snapshot handling includes moving dynamic resources after the first‑contentful‑paint (FCC) marker, dynamically loading styles, and assembling them into the snapshot DOM to ensure correct styling.

To mitigate snapshot‑related risks (e.g., outdated coupon UI), a skeleton UI is rendered in the snapshot layer, and modules can be excluded from the skeleton to protect content integrity.

Stability measures involve a configurable snapshot switch that can quickly disable snapshots and clear client caches if rendering issues occur.

Snapshot cache duration is dynamically configured per page based on revisit metrics (next‑day, 3‑day, 7‑day, 10‑day) to balance performance gains with freshness.

The conclusion emphasizes that while these out‑of‑the‑box solutions improve performance, they must be carefully aligned with business specifics to avoid side effects.

frontendperformanceWebCachingEdgesnapshot
DaTaobao Tech
Written by

DaTaobao Tech

Official account of DaTaobao Technology

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.