Cache busting is the process of uploading a new file to replace an existing file that is already cached. This is useful because the cache will often take a long time to expire from all of its various locations and cache busting properly ensures that any changes to a file be visible to end users sooner, rather than later.
This article will explain the various methods of cache busting and how to leverage them.
Filename and File Path versioning
If there is a JavaScript file named script.js that is already cached by the StackPath CDN, but you have an update ready for the file. Depending on when the last cache expiration was, you may have to wait for up to a week before the update would be visible to your customers! That's where cache busting with Filename or File Path Versioning comes in. If you upload the update with Filename Versioning or File Path versioning, your update will immediately be available and the StackPath CDN will immediately start to cache it, letting the original file expire from caches unnoticed.
Filename Versioning is the method of including the version in the file name, before the type. For example:
style1.css
body
{
background-image:url(‘back.png’);
background-color:#cccccc;
}style2.css
body
{
background-image:url(‘back-2.png’);
background-color:#cccccc;
}style3.css
body
{
background-image:url(‘back-3.png’);
background-color:#cccccc;
}File Path Versioning is the process of including the version in the directory or path for the file. For example:
Uploading the update to style.css into the directory styles/v1/style.css
body
{
background-image:url(‘back.png’);
background-color:#cccccc;
}styles/v2/style.css
body
{
background-image:url(‘back-new.png’);
background-color:#cccccc;
}styles/v3/style.css
body
{
background-image:url(‘back-newest.png’);
background-color:#cccccc;
}These methods work equally well for cache busting, as neither will interfere with any caching mechanisms and can be infinitely updated to reflect the modified file. The StackPath CDN can also request, and cache these without any problem, or extra configuration; and as a bonus, they will not trigger any optimization suggestions in webpage speed tests.
Make sure to adjust the HTML of your website to reference the new versions of files when using Filename or File Path versioning, since they are uploaded as completely separate files.
Versioning with Query Strings
A Query String is a unique set of parameters that can identify separate files within the same file hierarchical path. This is usually done by adding a '?' followed by the string that indicates the differences to the end of the file. This can be used for cache busting because most cache mechanisms will use the query string as a separate file.
style.css
body
{
background-image:url(‘back.png’);
background-color:#cccccc;
}style.css?back=2
body
{
background-image:url(‘back-2.png’);
background-color:#cccccc;
}style.css?back=3
body
{
background-image:url(‘back-3.png’);
background-color:#cccccc;
}
Usually, the StackPath CDN will cache these as completely separate files, so there is a separate cache for script.js?ver=2 and script.js?ver=3. Under most circumstances, this will be alright, as the differences in the versions are what we want to separate. However, this is not ideal for caching content that is the same across versions.
To prevent this behavior of separately caching files, we provide the option to force the StackPath CDN to ignore query strings. Setting the Query String Control setting to 'Ignore Query Strings' will remove the query string from any requests our servers make to your origin server, so the CDN will only cache and serve one version of a file.
Many website speed test tools, including Pingdom and Google PageSpeed Insights, will present an optimization suggestion to remove Query Strings. There are numerous WordPress plugins that can handle this for you.