Building for Cache Invalidation

It is important to find the right balance between long cache durations on resources for faster pages and reduced origin traffic while still being able to publish changes to your users quickly. Achieving this is necessary regardless of whether you use Squixa or not for your website.

Even without Squixa, or any CDN, it is good practice for a website to set long cache periods on mostly static resources (ie CSS, JavaScript, images). This gives end users a better experience by allowing them to re-use these previously downloaded resources and reduces load on your origin. The problem with this is that you may deploy an update to your CSS or Javascript, etc but the end users' browsers will still have the old version cached and won't request an update until the cache expires. At best the user doesn't get the changes until much later, at worst it breaks how the site looks and behaves when different versions of cached static resources expire at different times and get mixed together.

Naturally, you cannot ask your users to force-refresh or clear their browser cache in these circumstances, so you need a way to force a browser to request the latest version without you knowing in advance when you might release an update and without setting the cache expiry time so short that you reduce the site speed and add extra load on the origin.

A popular solution is cache-busting (aka cache-breaking) query strings. This solution involves appending a query string to the URL of a static resource with a value that is ignored by the website but is simply present to cause the URL to be different and subsequently trigger browsers and caching proxies to (re-)download the resource from the origin.

Here is an example stylesheet reference that you may find in a HTML page that is not using a cache-buster:

<link href="/styles/mysite.css" type="text/css" rel="stylesheet"/>

Here is the same reference again but this time with a cache-buster query string added:

<link href="/styles/mysite.css?v=12345" type="text/css" rel="stylesheet"/>

The "?v=12345" is the new part. The "v" key name is unimportant, choose anything short and unique that your origin will ignore. The "12345" value just needs to be something that changes when you want to force downstream caches to re-download the resource. Often the last-modified time of the file ("mysite.css" in this example) is converted to Unix epoch format and used (eg "?v=1426826927"). Other alternative values include: the time when the site was last deployed, the hash of the file's contents (eg MD5), or the version control commit identifier from when the file was last changed.

All that matters is that the value only changes when the content changes and stays the same when the content stays the same.

A website built in this style will work well with end user browser caches and CDNs and will of course also work well with Squixa.

Without cache-busting query strings in your URLs (or an equivalent mechanism) you'll need to use Squixa's on-demand cache flush feature, or wait until the caches expire naturally. As a bonus, Squixa's cache flush feature will also effectively force end-user browser caches to reload static resources because it implements a very similar mechanism as described above.

Have more questions? Submit a request

Comments

Powered by Zendesk