About Caching Score

Assess how strong the HTTP caching capabilities of any given site is. Caching Score is designed to answer the question — "how will my site survive a high traffic event?".

Guiding principles

  • Simple to use and understand at a glance
  • Provide education around how to interpret the current score
  • Provide information around how to improve the score, and why this matters
  • Be pluggable, and be able to support a wide range of popular CDNs and applications

Frequently asked questions

Caching Score sends HTTP requests to your chosen site, and analyses the HTTP responses headers. As every CDN responds in a slightly different way and has its own quirks, Caching Score has a plugin system to ensure it understands every supported CDN.

When analysing a given site, Caching Score may send a dozen or so HTTP requests to verify its caching abilities.

Rate limiting of scans is in effect to prevent abuse. The limits are fairly generous, and reset every 24 hours.

Anything over a B is OK 👌, anything above an A has had some serious ❤️ and attention poured into it.

Caching Score compliments Core Web Vitals, as they have different focus areas.

Core Web Vitals is more focused on the user experience of the website (with areas that measure loading performance, interactivity and visual stability), whereas Caching Score is more concerned with how cacheable the respective assets are. It would be possible to have a great Caching Score grade, and a terrible Core Web Vitals grade at the same time.

There are currently plugins written for the following CDNs:

  • Akamai
  • Azure CDN
  • Azure Front Door
  • Bunny CDN
  • Cloudflare
  • Cloudfront
  • CDN77
  • Fastly
  • Fly.io
  • Google Cloud CDN
  • Imperva
  • KeyCDN
  • LimeLight
  • Netlify
  • QuantCDN
  • QUIC.cloud
  • Section
  • Squiz Edge
  • Vercel Edge
  • Wordpress VIP

There is also support for generic Varnish reverse proxies as well.

Feedback on how to make Caching Score better is always appreciated, please contact me.

At present, all tests are executed from Sydney, Australia. So long as you are using a global CDN, this will have no negative impact on your score, no matter where in the world your site is actually running from.

There are a number of known limitations of Caching Score:

  • Only 10 seconds is allowed per HTTP request. If your site does not respond in that time, then likely you already know the score.
  • Akamai Bot Manager has been known to block/tarpit Caching Score requests when configured aggressively.
  • Some CDNs can be configured to remove debug headers, and strip useful information headers. This makes Caching Score's job basically impossible.
  • Certain more advanced features (e.g. Serve While Stale) cannot be tested by Caching Score (as the origin needs to be down).
  • Scanning rather large sites like www.google.com and www.facebook.com will not produce accurate scores. These sites don't use traditional CDNs.
  • No support for chaining CDNs (e.g. nesting Cloudfront behind Cloudflare) or caching proxies, only the first reached CDN is counted.

There are 3 IPs HTTP requests can come from (if you wish to allow list them in your firewalls):


The user agent used is cachingscore/1.0, so it will be easy to spot in your logs.

These checks are the combination of years of experience in scaling and optimising large mission-critical websites. The scoring is by no means perfect, and will be tuned over time, as I receive feedback.

Many different opensource libraries were used in the making of Caching Score, here are a few of the more consequential ones:

  • SlimPHP – a PHP based microframework that I like a lot
  • PHP 8.3 – fast and secure
  • Twig – for secure templating
  • Guzzle – a fully featured PHP HTTP library
  • Bootstrap – the component library is great and saves me time

If you do spot an issue with the scoring, HTTP header interpretation, or would like to add support for a CDN that is not currently supported, please reach out.