The market for content delivery networks (CDNs) has grown outward in the last decade to encompass more flexible – and cheaper – offerings.  That means many sites that couldn’t afford a CDN a few years ago are now dipping their toes in.  But with a democratized market also come mistakes.  Without the professional services provided by higher-end CDN offerings, it’s easy to make seemingly small mistakes in setting cache-control headers that result in higher costs and sub-optimal performance.  These are easy to fix, but you have to know what to look for.

Run down our checklist to make sure your content is set to get the most of the CDN service that you’re already paying for.  (For a great overview of all options available in the world of caching options, see Mark Nottingham’s Caching Tutorial; for a shorter, cliffs-notes introduction, check out Mobify’s excellent blog post.)

1.) Make sure ALL of your static assets are all set to cache-control: “public” (rather than “private” or “no-cache”).

We often see sites on which some static assets (images, CSS, JavaScript) are set as “private” or “no-cache.”  These instructions tell a CDN not to cache that asset, thereby defeating the purpose of the service. The cache-control header for all static assets should be set to “public” in order to leverage the CDN.

2.) If you use an if-none-match header, don’t set an If-modified-since header

“If-none-match” allows you to provide an entity tag (ETag) so that the browser will ask the server if you have changed content, and accordingly provide the visitor with the right version. However, if you also have an “if-modified-since” header with a date/time stamp, the browser will make a second (redundant) request to the server for information, even though it already knows the content is unlikely to have changed given the ETag information. This second request takes time, thus affecting performance, and also increases the cost you’re incurring from your CDN provider.

One such extra request here or there won’t make a measurable difference, but if numerous assets per page cause extra requests, and if many users hit that page on a daily basis, they will add up.

3.) Set an expires header with a long max-age

 
Even better, this header allows the browser to avoid sending requests from both if-none-match and if-modified-since headers altogether.  The expires header will override those other header behaviors by telling the browser that nothing has changed and to grab the currently cached version of the asset.  Max-age is set in seconds, up to 1 year, but typically a day (86400 seconds) is a recommended setting.

The drawback to this technique is that you must use a method called versioning (see #4) in order to update content.  That’s why we recommend only setting an expires header for content that’s not frequently changed, such as your logo, and to set an if-none-match header for any content that changes on a regular basis.  (This helps to avoid potential confusion or mistakes with regard to versioning, especially if there are a number of people updating content on the site).

4.)   Use versioning

If you set an expires header with a long max age for an asset, any updates made to that asset won’t be seen by visitors until the max age is expired. To overcome this and get your fresh content out to visitors ASAP, you must alter the URL of the asset. A minimally disruptive way to do this would be to “version” the URL by adding an incremental number to the end of the URL each time it’s updated, for example: “logo.png?v1” “example.png?v2” etc.

Learn More
There’s a lot to learn in the world of cache control headers, so we recommend you reference Mark Nottingham’s Caching Tutorial and Mobify’s blog post for more.  If you’re looking to ramp up your CDN performance even further, try Yottaa Engagement Cloud free for 14 days.  The service includes our federated CDN, which fully integrates with your existing CDN solution to provide increased footprint as well as our application sequencing and FEO capabilities.