One of our main goals is to provide our customers with a great cache hit rate, with an average of over 95%. If your pull zone is displaying a low cache hit rate, it means that the requests are not being cached on our servers and we always fetching them from your origin URL first. This not only stresses your server but also provides. If you are seeing anything below 70%, it is is very likely an indicator of a performance problem caused by an incorrect configuration, but luckily, there are a few easy ways to test and fix this.
Look at the 'Cache-Control' header of your files
The first thing that we recommend you to do is have a look at your Cache-Control headers on your static files. Our servers will strictly follow this header in order to determine if the files should be cached, and for how long.
Some of the indicators of a Cache-Control header error:
-
The Cache-Control is missing.
-
The value is set to no-cache
-
The value is missing the max-age directive
-
The value contains a very low max-age value
You can easily check this using the curl command that would look as follows:
curl -I http://static.examplesite.net/css/style.css
HTTP/1.1 200 OK
Date: Fri, 03 Mar 2025 16:09:24 GMT
Content-Length: 303142
Connection: keep-alive
CDN-Cache: HIT
CDN-PullZone: 1010
Server: BunnyCDN-NY1-885
Cache-Control: max-age=2592000
If you found any of the problems above, it's is likely the reason why your hit rate is so low. Luckily, there is a relatively easy solution for this. You can utilize our caching overrides if you have entirely static content for example:
Or use Edge Rules to cache specific files/extensions for a specific amount of time:
Are you using dynamic query strings when linking to your static files?
This is also a very easy and big indicator why things are not being cached. We look at each URL as a unique entity, so if the query string changes, it won't get loaded from cache as our servers will assume this might be a different URL. For example, if you are linking to files with query strings like this /style.css?v=5ga356q and the next time like this /style.css?v=qwf34f we will treat these two URLs as two different files.
This can be used with good advantages, for example, when making sure that the user has the latest version of the file, but when used incorrectly, it might happen that the strings are changing, while representing the same content.
Luckily, we provide an easy way to solve this.
In your dashboard, simply go to Pull Zones -> Caching -> General and in the Vary Cache setting, you will see a section called URL Query String. All you have to do now is disable this feature.
Our system will now automatically treat /style.css?v=qwf34f and /style.css?v=5ga356q as two identical URLs and will always serve the same cache file for both, instantly improving your cache hit rate.
Note: Be aware that disabling this means all query variants of a file are treated the same. Please review your own project workflow to consider if this can be disabled or not - it may have an adverse affect on the content you wish to serve to users.
Is your Pull Zone new or did you just do a cache purge?
When you first create your Pull Zone, the cache hit rate slowly builds up, so if you just created it, you might want to simply wait for a day and you should be seeing an increase in the cache hit rate as hours go by. The same goes if your Pull Zone was just purged. If you purge cache, we recycle everything already stored on our servers and start loading your resources fresh from the server.
If any of the two is true, you might simply wait a bit to see if the cache hit rate goes up and if not, have a look at point 1 and 2 of this article.
Do you use utilize a lot of Dynamic Cache?
If ‘Smart Cache’ is enabled, a large amount of dynamic content is treated as non-cacheable (more details found here: Understanding Smart Cache ). This can adversely affect your statistics especially on domains which expect a large amount of that are seen as dynamic assets.
Is your cached content regularly requested?
Naturally there is limited capacity on the network storing files; we don't store the files forever when cached. We have a dynamic caching system that essentially means after a period of time (usually 5 days to a week) if a file that was previously cached on the network but not requested, that file may be ejected from the cache, meaning more MISS can be expected. The more popular requests are, the better the HIT rate can be overall on your domain.
Do you serve largely static cached content?
Permacache might be a good option for you - where the files are stored in our storage permanently when the URLs are requested on the CDN. Permacache however does not present/increase cache efficiency metrics (essentially if a file is MISS, but on permacache HIT), its still reported as a MISS on CDN cache metrics.
Do you serve mass requested assets simultaneously?
For some users, livestreaming for example can become a strain on the origin infrastructure, as mass numbers of users can make requests for the same assets simultaneously (effectively meaning cache MISS for all) and increasing origin load, and subsequently keeping cache HIT rate low. We have a feature called ‘Request Coalescing' - this funnels a mass number of requests within a region/metro into a single upstream origin request - reducing origin load and increasing cache HIT rate for these situations. This is highly recommended for livestream/live event scenarios.