3 hacks to improve CDN performance and to reduce cost

Using a CDN is a major step for improving the performance and scalability of your website or application. However, to get the most out of a CDN service, it should be tuned and optimized to your particular needs. Customized CDNs will increase service performance and efficiency while also reducing the cost.

In this article, we will talk about three best-practices to improve performance and to reduce costs. Let’s start with “the log hanging fruit”, simple adjustments that can lead to big rewards and we’ll work our way up in complexity to some more advanced configurations.

Optimization #1:  Use Gzip

GZIP is a file format for the compression and decompression of files (like CSS or JavaScript files). It is an open source, first introduced by Linux systems. It contains many software tools, implementations and use cases. It is commonly used when data is in static or for while in transit. By using compressed text files, you can save-up to and between 60% and 85% of the actual size, which means that a typical file, of 100KB, would be compressed up to and between 15KB-40KB, an average of 50% performance boost and reduce costs. For a long time now, modern browsers have supported GZIP. Files are being sent to the browser in a GZIP compressed format, the browser extracts these files in a very efficient way and renders them as part of the page load process.

GZIP can be enabled on your origin server, but alternatively, the BitsNGo CDN can be set to compress the textual files. In order to do that, click on “More Options” and toggle “ON” for GZIP.

You may read more on GZIP

RFC: https://tools.ietf.org/html/rfc1952

Wiki: https://en.wikipedia.org/wiki/Gzip

Optimization #2:  Ignore Query Strings (if possible)

A query string is a piece of data affixed to a URL, which modifies the request.
This is often used to pass dynamic information, such as User IDs. For example:
example.com?userid=1234

When such Query Strings get added to static content, by default the CDN will treat each Query String variation as a different object, which in turn will send a new request back to the origin and store a new object on the CDN cache.

In many cases images or static content is not altered by changes in the Query String, so making a new request to the origin for them is a waste.

If the content which is delivered by the CDN does not need to change based on Query Strings, you may prevent the CDN from fetching different objects due to query String variations.

You can disable it by clicking on “More Options” and selecting “OFF” for “Honor Query String”. See screenshot:
You may read more on Query String

RFC: https://tools.ietf.org/html/rfc3986#section-3.4

Wiki: https://en.wikipedia.org/wiki/Query_string

Optimization #3: Setting a Default TTL (Time to Live)

The TTL (Time to Live) is the amount of time a resource will be kept on the browser cache and CDN cache before it is fetched again from the origin. The TTL is set for web resources by the Cache-Control header, using the “max-age” or “s-maxage” directives.
Here is an example of a typical entry (time value in seconds):
Cache-Control: max-age=300

This directive (browser cache and CDN cache), means that once the respective object is fetched, it won’t get fetched again or revalidated for 300 seconds / 5 minutes. Meaning, once an item is cached by the browser, it will not be requested from the CDN again for 5 minutes. The CDN will serve these requests for 5 minutes without requiring revalidation from the origin.

To improve the efficiency of the service, we want to limit the number of times, resources need to be fetched or validated from the origin, whilst also ensuring that fresh content will be available to users. To optimize resources, we want to set the TTL at the highest value possible for the type of content we are delivering.

The optimal TTL settings that should be used will vary from site to site, depending on the nature of the site. For instance, a news organization site with constantly updating content, will need a short TTL of 1 minute, to ensure visitors are always getting the latest news (while 1 minute TTL may seem short, it is an appropriate amount of time for a news website that serve thousands of requests per minute). However, a quite static natured site, can afford a much longer TTL, such as 1 week or 1 month, depending on the frequency of changes to the site.

It is also possible to set separate TTL values to the browser cache and CDN cache. By default the “max-age” will be respected by both the browser and CDN.
However if we include the “s-maxage” directive, the CDN will only respect the “s-maxage”.

For example: Cache-Control: max-age=300, s-maxage= 86400

This means that the browser will check for fresh content on the CDN after 300 seconds (5 minutes), however the CDN will only revalidate the content with the origin once in 86400 seconds (1 day).

This type of setting reduces the number of times the CDN will go to the origin, but it allows the browser to check more often. Why would the browser need to check more often? Although the content will respect the TTL, it is possible to purge all the content from a CDN upon request. If the content is manually purged, we want to allow the browsers to get the newest content right away (rather than have to wait an entire day).

You may read more on TTL, max-age and s-maxage

RFC (HTTP/1.1): https://tools.ietf.org/html/rfc7234#section-5.2.2.8