Server caching headers and a CDN checklist for faster product pages

Cache static assets long and keep product HTML short‑lived or safely purged. Use the checks below (DevTools, edit→purge, Lighthouse) to confirm headers and CDN behaviour without needing vendor‑private access.

Editorial illustration: a product browser card beside a stylised teal CDN/server stack, on a pale mint background with soft shadows and a lavender corner curve.

Short answer: give your static assets (images, CSS, JS, fonts) long, fingerprinted cache lifetimes and let a CDN serve them; treat product HTML as short‑TTL or cacheable only when you can purge it reliably or isolate dynamic parts. That reduces round trips while avoiding stale prices, stock or logged‑in indicators.

Contents

Decide what to cache (static assets vs product HTML)

Split your site by resource type before changing headers or enabling full-page CDN caching. The practical categories and safe defaults are:

Fingerprintable static assets (images, CSS, JS, fonts)

Recommendation: serve from a CDN with long TTLs (weeks → up to 1 year) and mark them immutable when the filenames include a version or hash. Why: these files only change on deploy, and fingerprinting avoids serving stale copies.

Product HTML pages

Recommendation: keep short TTLs, enable revalidation (ETag/Last‑Modified) or only cache when you can purge reliably. Why: product pages contain prices, stock and availability that change; long caches risk showing incorrect information.

Checkout, cart and account pages

Recommendation: do not cache publicly (or cache only per user/session with strict variations). Why: these pages contain user‑specific and secure data that must not be shared between visitors.

These guidelines align with performance guidance that favours long lifetimes for fingerprinted static resources and cautious caching for HTML. See Google’s recommendations for browser caching and content‑driven hosting for more context: Google: leverage browser caching, Google: content‑driven hosting optimizations.

Headers & validators to set on origin

Set clear origin headers so browsers and CDNs can act predictably. The important signals are:

  • Cache‑Control — the primary signal for caches. Use public for CDN‑shareable assets and private for user‑specific responses; set max-age for the desired lifetime and s-maxage for shared caches when relevant.
  • ETag or Last‑Modified — validators that let caches revalidate efficiently instead of refetching full bodies.
  • URL fingerprinting — prefer renaming/versioning files on deploy so you can safely give long max‑age and immutable hints.

If you use a CMS or framework, check how it handles cache headers when users are logged in or when pages are dynamic. For WordPress, for example, review how it sends headers and the helpers it exposes: WordPress: wp_send_headers(). Also consult the HTTP caching spec for validator semantics: W3C: HTTP caching (RFC 2616).

CDN basics and HTTPS

When you add a CDN, there are two secure hops to configure: client → CDN and CDN → origin. Ensure both use HTTPS. Important configuration points:

  1. Find whether your CDN respects origin Cache‑Control or whether it applies an overriding edge TTL (vendors use terms like edge TTL, s‑maxage or origin shield).
  2. Minimise forwarded cookies and headers to avoid cache fragmentation — forward only the ones required for correct page generation.
  3. Read your CDN docs for how cache keys are constructed (which headers, cookies or query strings are included) and how to change that behaviour.

Google’s guidance on hosting and CDNs discusses these tradeoffs for content‑driven sites: Hosting and CDN optimizations.

Handle personalisation and cache key variation safely

Decide how user‑specific parts are produced and cached. Common safe approaches:

  1. Render dynamic fragments client‑side (AJAX/fetch) so the surrounding HTML can be cached publicly. Keep only non‑sensitive fragments in client requests.
  2. Configure your CDN to vary the cache key precisely by the minimal header/cookie/query parameter necessary. Avoid forwarding every cookie or header — that defeats caching.
  3. Exclude pages completely from shared caches when personalization or session data is core (cart, checkout, account pages).

WooCommerce recommends excluding cart/checkout and other session pages from caches — follow platform guidance for pages that rely on dynamic session data: WooCommerce: configuring caching plugins.

Invalidation and purge workflows

When product data (price, stock, availability) must change quickly, you need a reliable invalidation strategy. Practical patterns:

  1. Programmatic purge: have your CMS or a plugin call the CDN’s purge/invalidation API when a product is updated. Verify the purge API and the vendor’s recommended pattern.
  2. Short edge TTLs or explicit s-maxage: when programmatic purge is unavailable, set short edge lifetimes for HTML so changes propagate quickly.
  3. Manual emergency purge: keep a documented manual process for urgent price or stock corrections.

Programmatic invalidation is common; consult your CDN/host docs for exact endpoints and authentication. An example reference for programmatic invalidation patterns is available in vendor support pages: Example: programmatic invalidation.

Practical checks you can run (no vendor access needed)

Run these reader‑performed checks to confirm caching behaviour end‑to‑end.

  1. Open DevTools → Network. Load a product page and inspect response headers for the page and for an image/JS asset. Confirm Cache‑Control and ETag/Last‑Modified are present where expected.
  2. Note CDN/edge headers (common keys include Via, X‑Cache, CF‑Cache‑Status). They are helpful signals but vendor names vary; read your CDN docs for exact header names.
  3. Make a harmless edit to a product (change a short sentence or add a tag) and save/publish. Trigger your CMS’s purge webhook or the CDN purge if you have one; otherwise wait past the HTML TTL and reload the product URL. The updated content should appear; if not, revise the purge approach.
  4. Run Lighthouse or PageSpeed before and after enabling CDN/caching to observe LCP and asset load improvements. Interpret changes cautiously: network conditions and test location affect results, so run several repeats for a representative picture.

Fictional example (illustrative)

Illustrative scenario: a small shop set Cache‑Control: public, max‑age=2592000, immutable on fingerprinted image URLs (30 days + immutable), kept product HTML at Cache‑Control: public, max‑age=60 with s‑maxage=300, and used a webhook to call their CDN’s purge API when a product update was saved. After publishing a product description change, the purge cleared the edge cache and reloading the product showed the new copy. This is illustrative, not a recorded test — check your CDN and CMS docs for exact purge APIs and behaviour.

Quick checklist and sample headers

  • Classify resources: fingerprinted static assets vs dynamic HTML vs session pages.
  • Set Cache‑Control for static assets (long TTL) and for HTML use short TTL or revalidation.
  • Enable ETag or Last‑Modified validators on origin.
  • Configure the CDN to respect or intentionally override headers; limit forwarded cookies/headers.
  • Implement a programmatic purge webhook or use short edge TTLs for HTML.
  • Verify with DevTools, make a content edit and confirm purge, then run Lighthouse for before/after checks.

Example headers you can adapt (vendor syntax may vary):

/* fingerprinted static asset (immutable) */
Cache-Control: public, max-age=2592000, immutable
ETag: "abc123"

/* product HTML (short lived, revalidation allowed) */
Cache-Control: public, max-age=60, s-maxage=300
ETag: "digest-value"

Choose exact values based on how often your content changes and what your CDN supports. For ranges and rationale see Google’s guidance on browser caching and the HTTP spec: Google: browser caching, W3C: HTTP caching.

One practical next step: pick a product page you can edit safely, inspect its current headers in DevTools, change a small non‑critical field, publish and trigger your CDN purge (or wait past the TTL) to confirm the change appears. Record which header changed and which CDN/edge response headers you saw — that single iteration proves the end‑to‑end path.

Related guides: Improve product‑page LCP and image performance without re‑shooting photos — for fast images and LCP; Use WooCommerce webhooks to keep inventory synchronized with marketplaces — for webhook patterns you can adapt to CDN purge calls.