Any web application is always vulnerable to performance degradation and increased latency, even with a CDN implemented.

Think about what happens when a web request is sent from a client to an origin: It is fragmented, encapsulated into datum packets, and then sent over the backbone of the Internet through parallel ISP routes, traversing thousands of switches, routers, and data centers.

Sharks are out of your control

Therefore, one must accept that such complex systems are naturally prone to obeying Murphy's Law, which holds that: "If anything can go wrong, it will." A Georgian woman scavenging for copper, a shark eating fiber optic submarine cables, and cyber-terrorist-scuba-hackers are just a few of the things that have gone wrong.

Changing cache settings is possible

Aside from mother nature and human curiosity, you can control certain variables. Among them is the cache of your CDN. It can ensure that 99.99% of your web app's resources are utilized, the speed is maximum, and the latency is minimal when configured correctly.

Take control of your cache

Cache-Policies describe how, when, and why your web assets are cached by a web server.

An effective cache policy minimizes cache misses, maximizes cache hits, and maintains a base level of cache warmth. Understanding all the configuration files that govern these policies can be a daunting task, even for experienced system administrators. Despite this, there are specific things you can do that will direct most of the issues you'll encounter.

Those topics will be discussed below, but let's first learn how to track your cache hits and misses. Analyzing metrics and monitoring your cache hit ratio play a crucial role in optimizing your cache.

An Introduction to Cache Hit Ratios

Your CDN's cache hit ratio measures the percentage of requests it can fulfill from its internal cache (Cache HIT: Client to Edge) compared to requests that it must send to your Origin (Cache MISS: Client to Edge to Origin).

When cache hit ratios are high, web apps load faster, origin stress increases, latency increases, and connections are dropped. When cache hit ratios are low, web apps load significantly slower. Requests that miss the cache (via CDN edge nodes) often take longer to respond than direct requests.

In simple terms, the cache hit ratio represents how well your CDN is being utilized and configured.

Maintaining a Cache Hit Ratio

Cache hit ratios can be defined by a simple formula:

(Cache Hits / Total Hits) x 100 = Cache Hit Ratio (%)

   Cache Hits = recorded Hits during time t

   Total Hits = all requests recorded during time t

   t = time frame of observation

In the actual formula, time t becomes irrelevant as it’s cancelled out. Also keep in mind that the ratio must be less than or equal to 100 as the total amount of requests must be greater than or equal to Cache Hits.

For any web app, a cache hit ratio of 99% is possible. This depends, however, on the functionalities and design of the web app on the origin server. Web apps with a lot of user-generated content or more frequent updates may have a lower cache hit ratio.

With that said, if your cache hit ratio is below 80% on static files, your CDN is either poorly configured or not performing properly.

Understanding Cache Hit Ratios

There are other ways to label cache performance besides cache hit ratios, which measure CDN cache performance in percentage terms. A cache term such as the following is often used for this purpose.

  • An empty or too stale cache is referred to as a cold cache. In general, cache hit ratios hover below 15% or display sharp negative slopes toward zero.
  • It is the most ambiguous of the three cache states -- warm cache declines in performance (turns cold) or a cold cache increases in performance (turns hot while priming assets from the source).
  • Effortful, fast, and utilized is what every cache strives for: the Hot Cache. Simple enough.

Optimizing Your Cache Hit Ratio

Optimization #1: Modify cache control headers

The origin server sets a number of HTTP headers on each object it serves, some of which tell browsers and other web clients how long an object is considered fresh. Properly configured cache control headers on the origin inform the CDN of the age and freshness of each object.

If the origin is unable to set cache control headers on all objects, the CDN can set them. It can also override existing ones set by the origin. The CDN’s ability to do this can give you the leverage you need to serve content faster from the edge.

Reading HTTP headers

A number of HTTP headers control caching. These headers can set the maximum age of an object, an expiration time, or even specify that an object is not to be cached at all.

HTTP response/requests headers can be viewed with a number of different open source tools and libraries. There are browser-based extensions as well as cURL, the definitive library for command line interfaces across OSX, Unix, Linux and Windows.

Headers for common cache control

  • The Last-Modified parameter indicates when the object at that URL was last modified
  • Objects are identified in caches by ETags, which serve as unique identifiers
  • A cache-control rule specifies the maximum time between requests for an object.
  • A cached object's expiration date

It may not always be optimal to set the cache lifetime to 365 days (max-age: 31556900).

Your content should be presented at a time that suits you. It may be appropriate to cache assets for seven days if they change about every two weeks. It may be prudent to implement a version control query string on your backend if the asset is frequently accessed. Managing a CDN setting like Cache Query String would be required for the latter. Please see below for more details.

Cookies should be stripped as part of optimization #2

Objects that set cookies on the client side are not acting like static objects. The CDN assumes that objects with cookies are dynamic since it can't tell what's going on behind the scenes at the origin server. Every time they are cached, they will be missed.

To determine if your origin is setting cookies, look for the "Set-Cookie" header in the HTTP Response header. These tools are open source and can be used for this purpose.

You will notice that the Set-Cookie value changes for the same object in the following response headers. CDNs are forced to revalidate assets on every request, resulting in Cache MISS.

Response #1

Response #2

Some CDNs can ignore cookie data from the origin server if it isn't possible to change cookies on the origin server. In this way, the CDN is able to cache objects more efficiently.

Authentication, session identification, and other scenarios require cookies. Cookies, by nature, are un-cacheable, which means files containing them can't be cached either. For this reason, it is important to ignore cookies when requesting assets from your CDN.

CDN should ignore query strings as optimization #3

Interacting with web applications and APIs, aggregating user metrics, and providing version information for objects are all done with query strings. Static object URLs with query strings can be misinterpreted as unique objects and will request the origin server on every request. Consequently, cache hit ratios decrease unnecessarily.

The CDN should be able to ignore query strings on static object URLs if the origin server cannot remove them.

CDN query strings can be ignored via StackPath's control panel

It is important to note that query strings sometimes represent unique content and are warranted. The default query string is therefore honored by content delivery networks like StackPath.

The MD5 checksum

A Unix or Linux command prompt can be used to check if two static objects change when query strings are used. Both the MD5 checksums and the static objects must be the same.

MD5sum hash values in this case are identical. The query string should therefore be ignored. Queries with different hashes would represent dynamic content that shouldn't be cached.

This means query strings are tailored to each new user and most likely enhance the user experience when used to change content on static URLs. As a result, the CDN shouldn't cache them.

Make sure your ratio is long-term successful by auditing it

Even if the performance of your web app is above average, you should continue to monitor your cache hits and misses. You can reduce response times by milliseconds or even seconds by ticking or unticking a box in the CDN's control panel.

If you edit code that affects entire apps or individual microservices that are connected to your CDN sites/zones, you should always review your hits and misses every week, if not every day.