Getting HTTP caching right is mostly a matter of setting the correct headers. But knowing whether you set them correctly requires being able to inspect actual response headers, simulate cache behavior, and verify that resources are being cached and invalidated the way you intend.
These seven tools let you do that without paying for anything. They cover browser-level inspection, command-line header analysis, performance auditing, and CDN-layer caching behavior.
1. Chrome DevTools Network Panel
Chrome DevTools is the fastest way to inspect cache headers for any resource a page loads. Open the Network panel, load a page with cache disabled, and click any request to see its response headers.
The panel shows Cache-Control, ETag, Last-Modified, Expires, and Vary headers directly. On subsequent loads, the Size column displays "disk cache" or "memory cache" for resources served from cache. The status column shows 304 for revalidated resources.
The Lighthouse tab in DevTools includes a "Serve static assets with an efficient cache policy" audit that lists every resource with a TTL under one week and estimates the bandwidth savings from extending it.
This should be the first tool in any caching audit workflow.
2. curl
curl is the most reliable way to inspect HTTP headers from the command line. It makes actual HTTP requests to your server or CDN and displays the raw response headers.
To see just the response headers without downloading the body:
curl -I https://example.com
To follow redirects and see all response headers along the way:
curl -IL https://example.com/
The -I flag sends a HEAD request. For resources where HEAD behaves differently from GET, use -X GET --head instead.
curl is particularly useful for checking how your CDN modifies cache headers relative to what your origin server sends. Run the same command against the CDN URL and the origin URL directly and compare the output. Differences between the two often explain why a resource appears to cache correctly at the origin but fails to cache at the edge.
3. WebPageTest
WebPageTest is a free, open-source performance testing tool that runs synthetic tests from multiple geographic locations. It measures real page load times including the effect of caching on repeat visits.
The "Repeat View" feature runs the same test twice: once for a first-time visitor and once for a returning visitor who has cached resources. The difference between the two load times tells you how much your current cache configuration is helping for repeat visitors.
WebPageTest also produces a waterfall chart that shows when each resource was requested, whether it was cached, and what the response headers contained. This is useful for identifying resources that should be cached but are not.
4. PageSpeed Insights
PageSpeed Insights is Google's free performance analysis tool that runs Lighthouse audits against any public URL. Its "Serve static assets with an efficient cache policy" audit surfaces resources with short or missing cache TTLs and estimates the bandwidth savings from extending them.
Because PageSpeed Insights runs Lighthouse server-side, results are consistent and reproducible regardless of which device or browser you are testing from. This makes it useful for confirming that a cache configuration change had the intended effect after deployment without relying on local browser state.
The tool separates lab data from field data. Lab data shows what Lighthouse measured in a controlled test run. Field data draws from the Chrome User Experience Report, giving you a sense of real-world caching performance across actual user visits. For cache header auditing, the lab data section is most directly relevant because it shows exactly which headers each resource returned during the test. For teams that ship frequently, running PageSpeed Insights against a production URL after each deployment is a low-cost check that cache header regressions have not crept in through new asset types or updated server configurations. The audit output names each offending resource alongside its current TTL and a recommended minimum, which maps directly to the Cache-Control directives you need to adjust.
5. Redbot
Redbot is a purpose-built HTTP header analysis tool maintained by the HTTP working group community. You enter a URL and it fetches the resource and analyzes the response headers in detail, explaining what each directive means and flagging problems.
Redbot explains why a header is or is not correct, not just whether it is present. For developers learning caching behavior, this explanatory output is more useful than a binary pass/fail.
It checks Cache-Control, ETag, Last-Modified, Vary, Content-Encoding, and several other headers, and it follows redirects to check the headers at the final destination.
6. Fastly's Cache Simulator
Fastly provides a free cache behavior simulator as part of their developer documentation. It lets you input response headers and see how a CDN interprets them, including which directives control what behavior at the shared cache layer.
While Fastly is a paid CDN service, the simulator itself is free and useful for understanding CDN-specific behavior independently of which CDN you actually use. Different CDNs have different default behaviors for responses without explicit public directives or for responses that include Set-Cookie headers.
The simulator is particularly useful for verifying how s-maxage and stale-while-revalidate behave at the CDN layer before you deploy.
"The most common caching audit finding we see is long-lived HTML pages referencing short-lived assets. Two header changes fix the whole pattern." - Dennis Traina, founder of 137Foundry
7. Nginx Logs With Cache Hit Analysis
If you are running Nginx as a reverse proxy or CDN equivalent, its proxy cache module logs include a $upstream_cache_status variable that reports whether each request was a HIT, MISS, BYPASS, or EXPIRED in the cache.
Adding this variable to your access log format gives you a real-time cache hit rate breakdown without any additional tooling:
log_format cache_log '$remote_addr - $upstream_cache_status - "$request" $status';
access_log /var/log/nginx/cache.log cache_log;
After collecting a few thousand requests, parsing the log for cache status gives you a practical hit rate for each URL pattern. A consistently low hit rate on resources that should be cacheable points to a configuration problem.
This approach works for any Nginx-based cache, including Nginx configured as a local caching proxy in front of a Node.js or Python application.
How to Use These Tools Together
A typical caching audit workflow:
- Use Chrome DevTools to identify resources with missing or short Cache-Control headers
- Verify the exact headers with curl from the command line to confirm what the CDN is passing through
- Run WebPageTest or GTmetrix to see the repeat-visit improvement from fixing the headers
- Use Redbot on individual URLs to get detailed explanations for anything unclear
- Use Nginx logs or Fastly's simulator to verify CDN-layer behavior
The audit is iterative rather than one-time. New resources added after a deployment often inherit whatever default header configuration is in place, which may not match the correct TTL for their type. Reviewing caching headers after each major deployment is a low-effort way to catch these regressions before they compound into a significant performance difference. Automating the check with curl against a known resource list as part of your deployment verification process eliminates the need for manual audits in the first place.
For a deeper look at the caching patterns behind these checks, the article HTTP Caching: A Practical Guide for Web Developers covers the strategy behind what the tools surface. 137Foundry includes caching configuration as a standard part of web application delivery. MDN's HTTP caching documentation provides the canonical reference for every header and directive these tools analyze.
Photo by svetlana photographer on Pexels
Top comments (0)