What this analyzer reads and why it matters

Every time a browser or a CDN fetches a file from your server, the response carries headers that decide whether that file can be saved and reused, and for how long. This Cache-Control analyzer fetches a URL and reads the four headers that govern caching: Cache-Control, Expires, ETag, and Last-Modified. It then translates them into plain language, tells you how long the resource will be considered fresh, and flags weak or missing rules that force browsers to re-download content they could have kept. Good caching is the cheapest speed win available, because the fastest request is the one that never leaves the user's device.

Without correct caching headers, a returning visitor downloads your logo, stylesheet, and scripts all over again on every page view. With correct headers, those same assets load instantly from disk, and your server is spared the work entirely. The analyzer exists to show you, file by file, whether you are getting that benefit or leaving it on the table.

Decoding the Cache-Control directives

Cache-Control is the modern, authoritative header, and it speaks in directives. The max-age directive sets the freshness window in seconds, so max-age 31536000 means the file may be reused for a year without re-checking. The public directive lets shared caches like CDNs store the response, while private restricts it to the user's own browser. The directive no-cache is widely misunderstood: it does not mean do not store, it means store but revalidate with the server before each reuse. The directive that truly disables caching is no-store, which tells everything to keep no copy at all.

Two more directives matter for fingerprinted assets. The immutable directive promises the file will never change at this URL, so the browser will not even revalidate until the max-age expires, which is ideal for hashed filenames. The stale-while-revalidate directive lets a cache serve a slightly stale copy instantly while it fetches a fresh one in the background, giving users speed without serving truly old content. The analyzer surfaces each of these so you can see exactly what permission you have granted.

ETag, Last-Modified, and revalidation

ETag and Last-Modified power conditional requests, which are how a browser checks freshness cheaply. An ETag is a fingerprint of the file's contents, and Last-Modified is its timestamp. When a cached copy expires, the browser sends the saved ETag back in an If-None-Match header, or the timestamp in an If-Modified-Since header. If nothing changed, the server replies with a tiny 304 Not Modified response and no body, so the browser keeps its copy and skips the full download. This is far faster than re-fetching the whole file.

Revalidation is good, but it is not free. Every 304 still costs a network round trip, which is painful for users on high-latency mobile connections. That is why long max-age values matter for assets that never change. If your stylesheet has a content hash in its filename, you should cache it for a year with immutable and skip revalidation entirely, rather than forcing a 304 check on every visit. The analyzer helps you tell the difference between healthy revalidation and needless round trips.

How to read the analyzer output

Start with the freshness window. The tool converts max-age or Expires into a human duration, so you can judge it instantly. For truly static, versioned assets, you want something close to a year. For an HTML page that changes often, you want a short window or a revalidation strategy, not a long cache that would serve stale pages. A mismatch, such as a one-year cache on a frequently updated homepage, is a red flag the tool will help you spot.

Next, check for conflicts and gaps. If both Cache-Control max-age and an Expires header are present, modern browsers obey max-age and ignore Expires, so a contradictory Expires is just noise. If Cache-Control is missing entirely, browsers fall back to heuristic caching based on Last-Modified, which is unpredictable and varies by browser. The analyzer flags missing Cache-Control as a weakness precisely because you should never leave caching to guesswork.

The mistakes this tool catches most often

The first classic mistake is caching HTML too aggressively. If your main document carries a long max-age, visitors and CDNs will keep serving an old version of the page long after you publish updates, which can hide new content from users and even from re-crawling. HTML usually wants a short max-age, or no-cache so it revalidates, while the heavy static assets it references get the long cache.

The opposite mistake is just as common and more wasteful: sending no caching headers on static assets, so every image, font, and script re-downloads on each visit. Another frequent error is using no-cache when the author meant no-store, or relying on the old Pragma no-cache header, which modern browsers largely ignore. Setting a cookie on a static asset response is a subtler trap, since many CDNs refuse to cache anything that sets a cookie, silently turning your edge into a slow pass-through. The analyzer brings all of these into the open.

Caching, SEO, and AI crawlers in 2026

Strong caching feeds directly into Core Web Vitals. Returning visitors who load assets from cache see a much faster Largest Contentful Paint, and repeat-view performance is part of the real- world field data Google grades. Caching also reduces origin load, which keeps Time to First Byte low even under heavy crawl pressure. A server that is not busy re-serving the same files responds faster to everyone, including search bots.

Caching matters for AI visibility too, but with a nuance. AI crawlers like GPTBot and PerplexityBot benefit from a fast, cache- backed origin, yet they should always receive your current content, not a stale snapshot. The right pattern is long caches on immutable assets and short, revalidating caches on the HTML those crawlers actually read. That way the page is fast to fetch but never out of date when an AI engine pulls it to build an answer.

Vary, cookies, and the shared-cache traps

Two more headers quietly decide whether a shared cache like a CDN will store your response, and the analyzer reads them because they cause some of the most confusing caching failures. The Vary header tells caches that the correct response depends on a request header, for example the Accept-Encoding header for compression. A sensible Vary on Accept-Encoding is fine. A Vary on a header that takes many values, such as User-Agent or Cookie, effectively shatters your cache into a separate copy for every variation, which usually means almost nothing is ever reused. If your hit ratio is poor despite long max-age values, an overly broad Vary header is a prime suspect.

Cookies are the other silent cache killer. Most CDNs will refuse to store a response that sets a cookie, on the reasonable assumption that a cookie signals personalised content. The problem is that site frameworks often set a session cookie on every response, including responses for plainly static pages, fonts, and images. The result is a CDN that detects perfectly but caches almost nothing, because each response arrives carrying a Set-Cookie header. The fix is to stop sending cookies on routes and assets that do not need them, so the edge is allowed to do its job.

The public and private directives interact with all of this. Mark a response private and you forbid shared caches from storing it, which is correct for a logged-in dashboard but wrong for a public article. Mark a public page private by accident, and your CDN will pass every request through to the origin. Reading these directives together, Cache-Control plus Vary plus any Set-Cookie, is how you explain why a response that looks cacheable on paper is being treated as dynamic in practice, and the analyzer puts them side by side so the cause is obvious.

Cache busting and how to update safely

The reason long caches feel risky is the fear of shipping an update that visitors never see because their browser is still holding the old file. The answer is cache busting, and the cleanest version is fingerprinting. When you build a site, give each static asset a filename that includes a hash of its contents, so a changed file gets a brand-new name. Because the URL is different, the browser treats it as a fresh resource and downloads it, while the unchanged files keep their old names and stay cached. This is what lets you set a one-year immutable cache on assets without ever serving stale code.

For content that must change at a fixed URL, such as an HTML page, the answer is not a long cache at all but a short one with revalidation, so the browser checks in frequently and picks up edits quickly. If you ever need to force everything to refresh immediately, most CDNs offer a purge or invalidation that clears the edge cache on demand, though browser caches on the visitor's own device will still expire on their own schedule. Understanding which layer holds a stale copy, the browser or the edge, tells you whether a purge will help or whether you simply have to wait out the max-age. The analyzer shows you the max-age so you know exactly how long that wait would be.

What to do after you run it

Build a simple two-tier policy. Give versioned static assets, the ones whose filenames contain a hash, a max-age of about one year with public and immutable, since a new deploy produces a new filename anyway. Give HTML and any resource that can change at the same URL a short max-age or no-cache so it revalidates, keeping content fresh while still skipping full downloads through 304 responses.

Once you update your server or CDN configuration, re-run the analyzer against several URL types, an HTML page, an image, a stylesheet, and a font, to confirm each tier got the right header. Pair this with a CDN detector to make sure the edge is honouring your rules, and watch your repeat-view load times drop. Caching is invisible when it works, which is exactly why a tool that makes the headers visible is worth running before and after every change.