Caching Testing Strategy

Why Cache Testing Matters #

Caching dramatically improves web performance by storing copies of resources so they do not need to be fetched from the server every time. However, incorrect caching leads to users seeing outdated content, receiving stale API responses, or experiencing broken pages after deployments.

The famous quote “There are only two hard things in computer science: cache invalidation and naming things” exists because caching bugs are notoriously difficult to reproduce and debug.

Cache Layers #

Each layer can independently cache and serve stale content.

Browser Cache #

Stores resources locally on the user’s device. Controlled by Cache-Control and ETag response headers.

CDN Cache #

Stores copies at edge locations worldwide. Reduces latency by serving content from the nearest server.

Server-Side Cache #

Application-level caching (Redis, Memcached) that stores computed results, database queries, or API responses.

Key Cache Headers #

Cache-Control Directives #

What to Test #

Correct Caching Behavior #

Cache Invalidation After Deployment #

1. Deploy a change to CSS/JS
2. Verify that users get the new version (check file hash in URL changed)
3. Verify old cached version does not break the new HTML
4. Test with the browser cache populated from before the deployment

Stale Content Scenarios #

• Update a product price — does the old price persist in any cache?
• Change a user’s role — do cached permission checks still show old role?
• Delete content — does the cached version still serve the deleted page?
• Update a profile image — does the old image persist?

Cache and Authentication #

• User A’s data must never be served from cache to User B
• Logging out must invalidate cached user-specific content
• Vary: Cookie or private must be used for authenticated responses
• CDN must not cache authenticated API responses

Exercise: Cache Testing Audit #

Perform a caching audit on a web application.

Step 1: Inspect Cache Headers #

Open DevTools > Network tab. Load the page and check headers for different resource types:

Step 2: Test Cache Busting #

1. Note the current JS/CSS file URLs (with hashes)
2. Make a code change and deploy
3. Verify file URLs have changed (new hashes)
4. Hard refresh (Ctrl+Shift+R) should load new files
5. Normal refresh should also load new files (if HTML is not cached)

Step 3: Test Stale Content #

1. Load a page with dynamic content (user profile, product)
2. Update the content via another browser/API
3. Refresh in the original browser
4. Verify updated content is displayed (not stale cache)

Step 4: Cross-User Cache Test #

1. Log in as User A, visit profile page
2. Note the API response in DevTools (User A’s data)
3. Log out and log in as User B
4. Visit the same profile endpoint
5. Verify you see User B’s data (not User A’s cached data)

Debugging Cache Issues #

Chrome DevTools #

1. Disable cache checkbox in Network tab (for testing without cache)
2. Hard refresh (Ctrl+Shift+R) bypasses browser cache
3. Check Size column: “disk cache” or “memory cache” = served from cache
4. Check response headers for Cache-Control, ETag, Age
5. Application > Cache Storage shows Service Worker caches

curl for Header Inspection #

# Check cache headers
curl -I https://example.com/page

# Check if CDN is serving cached content (look for Age header)
curl -I https://example.com/style.css | grep -i "age\|cache-control\|etag"

Key Takeaways #

• Cache testing must cover all layers: browser, CDN, and server-side
• Static assets should use long cache with content hashes for cache busting
• HTML should use no-cache to ensure users always get the latest version
• Authenticated responses must use private or no-store to prevent cross-user data leakage
• Always test cache behavior after deployments to verify users get updated content
• The browser back button can serve stale cached content — test logout flows carefully