How to Check If Website Caching Is Working: Cache Hits and Load Speed Analysis

Your site may already have a CDN, browser caching, or page caching set up, yet the access speed doesn't seem to change much. In this situation, you can't just check whether the caching rules are enabled in the backend. What really needs to be confirmed is: after a user sends a request, is the resource actually being returned from cache?

To determine whether website caching is working, you can usually start with several aspects: Cache-Control, Age, HIT/MISS status, repeated request results, and TTFB. Only by looking at "is there caching," "is there a cache hit," and "did it get faster after the hit" as separate questions can you judge whether the cache configuration is actually doing its job.

This article approaches it from a practical testing perspective, explaining how to check website caching, what HIT and MISS each mean, and what else to check when the cache is hitting but the site is still slow.

1. What Counts as Website Caching Being Effective?

When people talk about website caching, there isn't just one kind. Looking at the entire chain of a user accessing a website, caching can exist in the browser, at CDN edge nodes, on the web server, or even inside the website application itself.

For example:

• The browser caches static files like images, CSS, and JavaScript;

• The CDN caches origin resources at edge nodes closer to the user;

• Servers like Nginx and Varnish cache pages or API responses;

• CMS platforms like WordPress use page caching plugins;

• Redis and Memcached cache database query results.

For the average site owner, there are two things that get the most attention during actual testing.

First, is the browser still repeatedly downloading the same resources?

Second, after using a CDN, are requests actually hitting the CDN cache instead of going back to the origin every time?

Although both of these fall under "caching," the testing methods aren't exactly the same.

Also note that a website loading faster doesn't by itself prove that caching is hitting; conversely, a resource showing HIT doesn't mean the entire page is necessarily fast.

Caching is just one link in the website performance chain, so when testing, it's best to look at cache status and actual load times together.

2. Is Website Caching Working? Check the Response Headers First

The most direct testing method is to look at the HTTP Response Headers returned for website resources.

Using Chrome as an example, open the page you want to test, then press F12 to enter Developer Tools and switch to:

Network → Select a resource → Headers → Response Headers

It's best to start by checking static resources like images, CSS, and JavaScript, since these are usually the easiest to configure caching for.

1. Check Cache-Control

Cache-Control is one of the most common response headers for determining caching strategy.

For example:

Cache-Control: public, max-age=86400

Where:

public means this response is allowed to be stored by shared caches;

max-age=86400 means the cache is valid for 86,400 seconds, or 24 hours.

This tells you the server has explicitly told the browser or intermediate cache nodes: this resource can be cached for a certain period of time.

You might also see:

Cache-Control: no-cache

Or:

Cache-Control: no-store

These two are often confused, but they actually mean different things.

no-cache doesn't mean caching is completely forbidden; rather, before reusing cached content, the server usually needs to be asked to verify whether the resource is still valid.

no-store is stricter and generally means the response content should not be stored at all.

So when checking caching, you can't just see no-cache and immediately conclude "the site has no caching." You need to analyze it together with other response headers and the actual request status.

2. Check Age

If the site uses a CDN, you can also look for Age in the response headers.

For example:

Age: 328

This can usually be understood as: the resource has been stored in some shared cache for 328 seconds.

After some time, request the same resource again. If you see:

Age: 356

and the number is still increasing, it's very likely the resource has been kept in the cache node and hasn't been fully re-fetched from the origin.

However, not all CDNs return Age, and you can't judge whether the entire caching system is working based on the Age field alone.

Different CDNs have different cache status fields, rules, and ways of returning them, so it's best to also look at HIT, MISS, and other results.

3. How to Read HIT and MISS

For CDN caching, HIT and MISS are the two most common and easiest-to-understand statuses.

Different providers may use different header names, for example:

X-Cache: HIT

Or:

CF-Cache-Status: HIT

Although the fields differ, the way to interpret them is basically the same.

HIT

HIT generally means the current request has hit the cache.

In other words, a usable copy of the resource already exists on the CDN node, and the request can be returned directly from cache without re-fetching the full content from the origin.

For static resources like images, CSS, JavaScript, and downloadable files, a normal cache hit usually significantly reduces origin server load.

MISS

MISS means the current cache node doesn't have usable cached content available, so it usually needs to fetch from the origin.

However, a single MISS doesn't mean the cache configuration has failed.

For example, when a CDN node receives a request for this URL for the first time, it may simply not have a local cache yet. The first request goes back to the origin, and only after the resource is cached can the second request potentially become a HIT.

So what's really worth paying attention to is:

The same resource is accessed multiple times in a row and still keeps showing MISS.

That's when you need to dig deeper into the cache rules.

Besides HIT and MISS, you may also see some other statuses.

Note that different CDNs may define these statuses differently. For an accurate judgment, it's best to also check the corresponding provider's cache rules.

4. Requesting Twice in a Row Is More Meaningful Than Looking at One Result

When actually testing website caching, I generally don't recommend drawing conclusions from a single resource request.

Suppose you're testing:

https://www.example.com/static/app.js

On the first visit you see:

X-Cache: MISS
TTFB: 186ms

At this point you can't immediately assume caching isn't working.

Request the same URL again. If the result becomes:

X-Cache: HIT
TTFB: 38ms

This actually shows caching is working fairly normally.

On the first request, the CDN node didn't have the file and needed to fetch it from the origin; after the resource was stored, the second visit returned directly from edge cache, so the time to first byte dropped noticeably.

If after refreshing multiple times in a row it's still:

X-Cache: MISS

Then focus on checking:

• Whether the resource is allowed to be cached;

• Whether the CDN cache rules cover this URL;

• Whether the TTL is set too short;

• Whether cookies are causing the cache to be bypassed;

• Whether URL parameters keep changing.

"First MISS, second HIT" is perfectly normal, and a single MISS shouldn't be treated as a caching problem.

5. How to Tell If Browser Caching Is Working

CDN caching and browser caching are not the same thing: CDN caching happens between the website server and the user, while browser caching happens on the user's own machine. Even if the CDN is already showing HIT, if the browser still re-downloads a large number of static resources on every refresh, page load efficiency can still suffer.

In Chrome, open:

F12 → Network

Then refresh the page normally and look at resources like images, CSS, and JavaScript. In the Size or Transferred column, you may sometimes see: (memory cache) or (disk cache).

memory cache generally means the resource is read directly from browser memory; disk cache means the browser reads it from local disk cache. In these cases, the browser usually doesn't need to fully re-download the file.

There's also a detail that's easy to overlook during testing: in Chrome Developer Tools' Network panel, there's a Disable cache option. If this is checked, browser caching may be temporarily disabled as long as Developer Tools stays open.

Many people test caching with Disable cache checked, refresh repeatedly, see resources always being re-requested, and end up mistakenly thinking caching isn't working.

So before testing browser caching, it's best to confirm the state of this option first.

6. After a Cache Hit, Check Whether TTFB Changed

To judge whether caching is valuable, you can't stop at "it shows HIT."

What really needs to be observed is: after the HIT, did request speed improve?

For example, testing the same static file the first time:

Cache: MISS
TTFB: 220ms

Requesting again:

Cache: HIT
TTFB: 42ms

This kind of change is fairly typical.

It shows the first visit needed to go through the CDN back to the origin, while the second could return directly from the cache node, reducing the origin round-trip, so TTFB dropped noticeably.

But if the actual result is:

MISS: TTFB 180ms
HIT: TTFB 165ms

Although the cache status changed from MISS to HIT, the actual response time for this visit didn't improve much.

In this case, you can't keep focusing entirely on cache configuration and should check other factors.

For example:

• Is the CDN node too far from the user;

• Is the current ISP line quality poor;

• Is DNS resolution reasonable;

• Is HTTPS/TLS connection setup taking too long;

• Are static files too large;

• Does the page itself still have a large number of third-party requests.

So when testing caching, it's best to follow one principle:

First check whether it's a HIT, then check how much faster it actually got after the HIT.

Only when both results hold true can you say caching isn't just "working in the configuration" but is actually doing something in real-world access.

7. After Adjusting Caching, You Can Re-Test Overall Website Speed

Browser Developer Tools are better suited for analyzing whether a specific resource is cached, while website speed testing is better suited for observing whether overall access performance has actually changed after cache adjustments.

For example, if you've modified the following configurations:

• Extended image cache duration;

• Adjusted Cache-Control for CSS and JS;

• Modified CDN cache rules;

• Expanded the scope of static resource caching;

• Cleared old cache and rebuilt it.

After making these adjustments, you can use Chahu to re-test your website's speed and observe changes in actual website response and access speed across different network environments.

At this point, the focus isn't on looking at a single speed test number in isolation, but on comparing the results before and after your adjustments.

For example, if response times were previously high in certain regions and dropped noticeably after you adjusted the caching strategy, that tells you the optimization actually had an effect on real traffic.

If the cache is already returning HIT normally but some regions are still noticeably slow during speed tests, then the problem probably isn't the cache.

At that point you should keep checking: DNS resolution, network routing, CDN nodes, origin response, and the page resources themselves.

This approach is more meaningful than staring at a single HIT status, because what end users actually feel is page load speed, not some cache field in the backend.

8. You Can Check Website Caching in This Order

If you just want to quickly determine whether website caching is actually working, you can check in the following order.

Step 1: Check Cache-Control

First confirm whether the resources that need caching have a reasonable caching policy.

Step 2: Check the cache status

Look at the HIT, MISS, Age, BYPASS, and other information returned by the CDN.

Step 3: Request the same URL repeatedly

Don't judge whether caching is working based only on the first visit.

Step 4: Compare TTFB

See whether the actual response time drops noticeably after it changes from MISS to HIT.

Step 5: Check browser caching

Confirm whether static resources are being read from memory cache or disk cache.

Step 6: Re-test overall website speed

After adjusting the caching strategy, observe again whether website access speed improves across different regions and network environments. If the cache is already returning HIT normally but the site is still slow, don't keep tweaking the caching rules over and over. Instead, expand your investigation to DNS, network routing, CDN nodes, origin response, and page resources.

Conclusion

To determine whether website caching is working, you can't just look at whether the "cache" switch is turned on in the backend, and you can't rely solely on a feeling that the page seems a bit faster than before. A more reliable approach starts with actual requests: first confirm that caching policies like Cache-Control are being returned correctly, then observe whether CDN requests are HIT or MISS. After testing the same resource repeatedly, compare the TTFB and actual load time before and after a cache hit.

If resources are already returning HIT normally and the response time drops noticeably after a hit, you can basically confirm that caching is doing its job. If the cache status looks normal but the site as a whole is still slow, the problem is usually no longer the cache itself. Continuing to check origin response, network routing, DNS, file sizes, and third-party resources will typically help you find the real performance bottleneck more easily than repeatedly adjusting caching rules.

Related Q&A

1. Why does a website with strong caching configured on the CDN still frequently return MISS when fetched via a Python script or Curl?

This is usually because automated scripts send HTTP requests with Request Headers that differ from those of a real browser by default (such as missing Accept-Encoding: gzip, br, or including a special User-Agent and Cookie). Many CDN nodes factor the compression support in request headers or the Query String into the cache key. When the characteristics of a script-initiated request don't match the version already cached at the edge node, the CDN treats it as a brand-new request and triggers a fetch from origin. When testing, it's recommended to use curl -I -H "Accept-Encoding: gzip, deflate, br" to simulate standard browser HTTP request headers.

2. After enabling Nginx's proxy_cache, why does EXPIRED keep showing up in the logs even though static resource caching is configured?

EXPIRED means the cache file for that resource does exist on the CDN or reverse proxy node, but its time to live (TTL) has exceeded the validity period specified by the rules. This usually happens for two reasons: first, the time set by proxy_cache_valid in the Nginx configuration is too short; second, the Cache-Control: max-age or Expires value in the origin's HTTP response headers is relatively small and overrides the proxy server's local default caching policy. At this point the node will go back to origin with validation headers, and if the origin content hasn't changed, it refreshes the lifecycle of that cache block.

3. The page uses HTML page-level caching (such as Edge Page Cache). After publishing new content, how do you make a specific page invalidate instantly?

Although full-page caching can greatly reduce time to first byte (TTFB), delayed updates can cause business problems. Relying purely on waiting for the TTL to expire naturally is too inefficient. The industry-standard approach is to trigger an active cache Purge or Invalidate via API. Purge directly deletes the physical file on the node, forcing a fetch from origin on the next visit; Invalidate marks the cache as expired and asynchronously fetches updates from origin in the background, while still optionally serving the old version to users (the Stale-While-Revalidate mechanism) to ensure seamless page loading.

4. Why might first-screen load speed show no noticeable delay under HTTP/2 or HTTP/3 even when the browser's local cache isn't hit?

In the HTTP/1.1 era, browsers limited the number of concurrent connections to the same domain (usually 6). If static resources missed the local cache, it was easy to trigger Head-of-Line Blocking. In HTTP/2 and HTTP/3, however, Multiplexing and the QUIC protocol were introduced, allowing all requests to be transmitted in parallel over the same TCP/UDP connection. Even if a resource triggers a response from a CDN node rather than a local disk read in the browser, the extremely low connection setup overhead masks some of the miss latency in the visual experience.

5. The origin sets Set-Cookie in its response headers. Why does this cause the CDN node to skip caching entirely?

To prevent users' sensitive private data (such as login Session state or personal shopping cart information) from being incorrectly cached by the CDN and distributed to other visitors, most CDN providers have strict security mechanisms in place: as soon as a Set-Cookie field is detected in the origin's response headers, the request is forcibly marked as BYPASS or PRIVATE and is never written to public node storage. If static resources like images or CSS are incorrectly injected with cookies, you need to check the origin server or CMS plugins and strip the Set-Cookie from static resource responses.