Website Caching Checklist: How to Audit Cache Headers, TTLs, and Purging

Overview

Website caching improves performance by reusing work that would otherwise be repeated at the browser, CDN, web server, application, or database layer. It can reduce origin requests, lower time to first byte (TTFB), and make traffic spikes easier to handle. It can also create difficult bugs when cache boundaries are unclear.

Begin an audit by drawing the request path for a typical page:

1. Browser cache: stores images, stylesheets, scripts, fonts, and sometimes documents on the user’s device.
2. CDN or edge cache: serves eligible responses from a nearby point of presence instead of contacting the origin for every request.
3. Page or full-page cache: stores generated HTML, often through a WordPress cache plugin, hosting platform, Varnish, or Nginx FastCGI Cache.
4. Object cache: stores reusable application data, commonly with Redis object cache or another key-value system. It is not a replacement for page caching.
5. Origin: runs the application, queries the database, and produces responses that are not available in a cache.

For each layer, document the cache key, eligibility rules, TTL, bypass conditions, and purge method. A useful audit is not simply a search for the longest possible TTL. It balances speed with freshness, personalization, and the effort required to invalidate content safely.

Checklist by scenario

1. Browser caching for static assets

• Inspect response headers for images, CSS, JavaScript, and font files.
• Confirm that cacheable, versioned assets include an intentional Cache-Control policy.
• Use a long freshness period only when filenames or query-string versions change whenever the file changes.
• Check that HTML documents do not inherit the same long-lived policy as static assets.
• Verify that compressed responses and content types are correct; a cache policy cannot fix an incorrectly served asset.

A common pattern for fingerprinted assets is Cache-Control: public, max-age=31536000, immutable, but only use a policy like this when the deployment process reliably changes the asset URL after edits. For unversioned files, choose a shorter TTL or provide a dependable purge process. See Browser Caching Best Practices for Images, Fonts, CSS, and JavaScript for a more focused asset review.

2. Public HTML and page caching

• Test an anonymous page in a private browser session and record the response headers.
• Make two or more requests and compare headers such as Age, ETag, Last-Modified, or platform-specific cache status values.
• Confirm whether the first request is a miss and subsequent requests can be hits.
• Check that query strings, cookies, authorization headers, and request methods do not unintentionally fragment the cache.
• Exclude login pages, account pages, checkout, cart, and other personalized responses unless the platform explicitly supports safe variation.
• Test both the homepage and representative templates such as an article, category, product, and search page.

For WordPress, review the cache plugin, managed WordPress hosting settings, and any CDN rules together. Two systems may each attempt to cache the same page with different TTLs or purge behavior. For ecommerce sites, treat cart, checkout, customer accounts, and order-related pages as special cases. The guide to bypassing cache on login, cart, and personalized pages provides a useful rule-by-rule review.

3. CDN caching and edge delivery

• Identify which hostnames and paths are eligible for CDN caching.
• Compare the CDN’s cache-control interpretation with the origin headers.
• Check whether cookies, authorization headers, query strings, or redirect responses prevent cache hits.
• Test from more than one network or region when geography matters to the site.
• Record the exact purge scope: URL, hostname, tag, prefix, or entire cache.
• Verify that a purge reaches every relevant edge location and that the next request repopulates the cache.

Do not assume that a CDN is serving a cached response merely because traffic passes through it. A cache-status header, provider diagnostic, or controlled request comparison can show whether the edge is hitting, missing, bypassing, or revalidating. If assets repeatedly contact the origin, use the CDN cache miss troubleshooting checklist.

4. Server and application caching

• Document whether the server uses Nginx FastCGI Cache, Varnish Cache, a hosting-layer page cache, or another reverse proxy.
• Check the cache key for host, scheme, path, query string, device variation, and language variation.
• Confirm that bypass rules cover sessions, administrative users, previews, and authenticated requests.
• Measure origin response time on a controlled cache miss as well as a cache hit.
• Check Redis object cache health separately from full-page cache health.

Page cache versus object cache is an important distinction: page caching can avoid application execution for an entire public response, while object caching can reduce repeated database or application lookups. Compare the actual architecture before changing settings. For a server-level comparison, see Varnish vs Nginx FastCGI Cache.

What to double-check

Cache-Control directives

Read the complete header rather than looking only for a number. public indicates that shared caches may store a response; private is intended for a user-specific response; no-store asks caches not to retain it; no-cache generally means the stored response must be revalidated before reuse. These directives have different meanings, so choose them based on privacy and freshness requirements rather than using no-cache as a general “do not cache” switch.

Record max-age for browsers and any shared-cache directive your stack uses. Then check Vary. If responses differ by compression, language, device, or another request property, the cache must either vary safely or bypass caching for that response.

TTL strategy

Set TTLs by content type and change frequency. Fingerprinted CSS and JavaScript can usually remain fresh longer than HTML. Frequently updated listings, stock information, or event pages may require shorter TTLs or targeted invalidation. DNS TTL settings are a separate concern from HTTP cache TTLs; changing a DNS record does not purge an HTML or CDN object. Use DNS TTL Best Practices when planning domain or hosting changes.

Purge and deployment verification

Write down the purge command or dashboard action before relying on a cache. After a deployment, update a harmless test page, purge the narrowest relevant scope, request it, and confirm the new content at the browser, CDN, and origin layers. Include rollback instructions. A safe cache-busting workflow should be part of the release process, not an emergency-only procedure; see How to Bust Cache Safely During Deployments.

Common mistakes

• Testing only one request: one request cannot establish whether a second request is a hit.
• Purging everything for every edit: this increases origin load and can create a cold-cache performance drop. Prefer targeted purges when supported.
• Caching personalized HTML: cookies and login state can make a public-looking URL unsafe to share from a cache.
• Using long TTLs without versioned filenames: visitors may continue receiving old assets after a release.
• Adding a cache plugin on top of unknown host caching: overlapping page caches can produce confusing headers and incomplete purges.
• Optimizing only for cache hits: a high hit rate does not prove that the cached response is correct, current, or safe.
• Ignoring cache misses: measure miss TTFB and origin resource use as well as the fast cached path. The TTFB troubleshooting checklist can help separate caching from origin bottlenecks.

When to revisit

Re-run this website caching checklist before seasonal planning cycles, traffic campaigns, major content changes, hosting migrations, CDN rule changes, and platform or cache-plugin updates. Revisit it after changing WordPress themes, adding WooCommerce functionality, introducing personalization, changing domains, or moving between web hosting providers.

Keep a small audit record with the tested URLs, date, headers, TTL decisions, purge method, and known exceptions. During each review:

1. Test an anonymous page, an authenticated page, and a transactional or personalized page.
2. Inspect one static asset and one HTML document.
3. Compare cache hit and miss timing.
4. Perform a controlled content update and verify the purge path.
5. Check logs or monitoring for unexpected origin load and cache errors.
6. Update the record when workflows or tools change.

The goal is not to cache every response for as long as possible. It is to make caching predictable: public content should be reused when appropriate, private content should remain private, changed content should be replaceable, and cache behavior should be visible enough to diagnose. That discipline supports faster pages, more stable origins, and more reliable website speed optimization over time.