CDN and Edge Caching Setup Guide: Cache Rules, TTLs, Purging, and Bypass Patterns

Overview

CDN caching stores eligible responses at edge locations so later requests can be served closer to visitors instead of traveling to the origin server. The performance benefit depends less on turning caching on than on deciding what may be cached, for how long, and under which conditions it must bypass the cache.

A reliable configuration begins with a content inventory. Separate public, mostly static resources from HTML that changes frequently or contains user-specific data. Images, fonts, stylesheets, JavaScript bundles, and versioned downloads are usually easier to cache than account pages, checkout flows, dashboards, and API responses. A public article page may be cacheable, while the same site’s cart and order-confirmation pages should normally reach the application.

CDN rules should complement origin headers rather than obscure them. Review cache headers, TTLs, and purge behavior at both layers. If a CDN rule says one thing and the origin sends a conflicting directive, the resulting behavior may be difficult to predict or maintain.

Keep a written cache policy for each URL class. Record the path pattern, allowed methods, cookies or authorization conditions, query-string treatment, TTL, purge method, and expected cache status. This turns an otherwise fragile collection of dashboard settings into an operational checklist.

Checklist by scenario

1. Static assets

• Cache CSS, JavaScript, images, fonts, and other public assets at the edge when they do not contain private data.
• Use content-hashed or versioned filenames, such as app.8f31c.js, so a new deployment can use a new URL instead of relying on an uncertain purge.
• Set a longer browser and CDN TTL for assets that are safely versioned. Use a shorter TTL when filenames remain unchanged across deployments.
• Confirm that compression, range requests, CORS headers, and content types remain correct after CDN delivery.
• Check that the CDN does not cache failed responses for longer than intended.

Browser caching and CDN caching solve related but different problems: the CDN serves a response from an edge location, while browser caching can prevent a request from being sent at all. Review browser caching practices for images, fonts, CSS, and JavaScript when tuning both layers.

2. Public HTML pages

• Identify pages that are identical for most visitors, such as public documentation, landing pages, or published posts.
• Cache only safe HTTP methods, usually GET and HEAD; do not treat requests that change application state as cacheable page requests.
• Define how cookies affect eligibility. A session cookie, preview cookie, or administrator cookie should generally trigger a bypass or a separate policy.
• Decide whether query strings represent meaningful content. Tracking parameters may be normalized or ignored, while filters, searches, and pagination may require distinct cache keys.
• Choose a TTL that reflects the publishing workflow. A site updated several times daily needs a different revalidation plan from an infrequently changed reference site.

Test an anonymous request and an authenticated request separately. A page that looks public in a browser may still contain a user name, basket count, experiment assignment, or other personalized fragment.

3. WordPress and WooCommerce

• Cache public WordPress pages only when the page cache, CDN, and cache plugin agree about exclusions.
• Bypass or carefully vary requests for logged-in users, previews, administrator paths, comment submissions, and account pages.
• Exclude WooCommerce cart, checkout, account, and order-related pages from ordinary full-page edge caching unless the application and platform explicitly support a safe alternative.
• Check whether cookies such as cart or session identifiers prevent cache hits on pages that should otherwise be public.
• After product, price, inventory, or navigation changes, verify that the relevant page and API responses are refreshed.

For a detailed exclusion pattern, see the guide to bypassing cache on login, cart, and personalized pages. A cache hit is not a success if it delivers another customer’s state or stale commercial information.

4. APIs and dynamic responses

• Start with a bypass policy for authenticated, authorization-bearing, and user-specific responses.
• Cache a public API response only when its data, headers, and permitted audience are understood.
• Include the relevant query parameters in the cache key, or explicitly normalize them when they do not change the response.
• Use short TTLs or revalidation for data that changes frequently.
• Confirm that private or sensitive responses carry appropriate non-cacheable directives at the origin.

5. Deployments and content changes

• Prefer versioned asset URLs for deployment output.
• Define a purge scope: one URL, a path prefix, a host, or the entire cache.
• Use targeted purges for routine edits and reserve broad purges for incidents or structural changes.
• Deploy origin changes before exposing references to new assets, then verify the new response at the CDN.
• Document who can purge production cache and how the action is audited.

The practical sequence matters. See how to bust cache safely during deployments before connecting purge actions to a release pipeline.

What to double-check

Use response headers and CDN logs rather than assuming that a rule is active. Depending on the provider, headers may expose a cache status such as hit, miss, bypass, or expired. The exact names vary, but the useful test is consistent: request the same URL more than once, from an anonymous context, and compare the result.

• Cache key: Check the scheme, host, path, query strings, cookies, and headers that distinguish one cached response from another.
• TTL: Compare the configured edge TTL with the origin’s Cache-Control, Expires, or related directives. Confirm what happens when no explicit TTL exists.
• Bypass conditions: Test cookies, authorization headers, request methods, preview modes, and administrative paths.
• Purging: Confirm that a purge removes the intended object and that a new request retrieves the expected version.
• Redirects and errors: Decide whether redirects, 404 responses, and 5xx responses may be cached, and for how long.
• Origin changes: Verify that the CDN reaches the intended origin, uses the correct host header, and validates TLS as expected.
• Performance: Measure time to first byte, total transfer time, and cache-hit behavior from more than one network location. A CDN cannot fix slow origin generation on requests that always bypass it.

If assets repeatedly hit the origin, use the CDN cache-miss troubleshooting checklist. Also distinguish edge caching from server caching: Nginx FastCGI cache, Varnish, and Redis object cache can reduce origin work, but they do not replace a clear edge policy.

Common mistakes

1. Caching everything by URL alone. Two requests with the same path may differ because of cookies, authorization, language, currency, or query parameters.
2. Using a long TTL without a content versioning plan. Long-lived objects are useful only when updates can be released under new URLs or purged reliably.
3. Purging the entire site for every edit. Broad purges can create an avoidable wave of origin requests. Target the changed URL or content group where practical.
4. Ignoring the origin. A CDN rule cannot safely compensate for missing privacy directives, inconsistent redirects, incorrect content types, or application responses that vary unexpectedly.
5. Testing while logged in. A logged-in browser often exercises a bypass path and does not represent an anonymous visitor’s cache behavior.
6. Duplicating controls across plugins and platforms. A WordPress cache plugin, web server, hosting layer, and CDN may each apply different TTLs or exclusions. Assign ownership for every policy.
7. Assuming a hit is always desirable. Freshness, correctness, and privacy come before the cache-hit ratio.

When to revisit

Review CDN and edge caching before seasonal traffic periods, major campaigns, catalog changes, or planned migrations. Recheck the policy whenever the application introduces new cookies, authentication flows, personalization, payment steps, APIs, locales, or query-driven filters. A redesign can change URL patterns and asset naming even when the visible site appears similar.

Set a recurring operational review after infrastructure or workflow changes. Compare cache-hit behavior, origin traffic, response headers, purge records, and error rates with the previous baseline. If Core Web Vitals or real-user performance worsens, inspect cache status alongside DNS, origin TTFB, and frontend changes rather than changing TTLs blindly. The TTFB troubleshooting checklist can help separate an edge-delivery issue from an application bottleneck.

For a practical final pass, export or record the current rules and walk through these tests: anonymous public page, logged-in page, cart or account flow, query-string variation, changed asset, purge of one URL, origin error, and a request from a second location. Keep the expected result beside the observed headers. When the results match, the CDN is not merely fast; it is behaving predictably, which is the foundation of dependable website speed optimization and ecommerce reliability.