What is cache busting?

Cache busting is way to ensure that the browser will download a new version of your file. This is easily accomplished using a simple technique of appending a ? with some unique characters at the end.


The browser sees this as a different file and will then download and cache this new file. Each time the browser see’s a different string it will download the file and cache it. Some methods use a revision number, a date, random number, or a signature as a query string parameter. Taking a look at the example above you will see a version number is specified at the end of the .css file to do the cache busting.

SharePoint 2010 uses a technique which involved computing a MD5 hash signature of the file and appending a ?rev={MD5HASH} to the link. This technique works very well because the computed hash won’t change unless you change something in the file.  Also the computed MD5 hash will be unique to ensure that the file will appear new to the browser. For all you super technical people, yes MD5 is not guaranteed to be unique, there is a very very small chance of the hash being the same. This technique of the computed MD5 hash signature is used for both CssRegistration and ScriptLink in SharePoint 2010. If you are interested in more detail then reflect into Microsoft.SharePoint.dll –> Microsoft.SharePoint.Utilities –> SPUtility –> MakeBrowserCacheSafeLayoutsUrl

Cache busting for CssLink

When using CssRegistration the files need to be relative to the Layouts folder, more specifically LAYOUTS\1033\STYLES\{CssFile}.



If you do not keep the files in the LAYOUTS\1033\STYLES then you will receive an error


Below is the rendered html output of the CssRegistration tag above


You can see that “/_layouts/1033/styles/” is prepended to the ‘Name’ property provided in the CssRegistration tag and your .css file is successfully cache safe.

Cache busting for ScriptLink

When using ScriptLink the files need to be relative to the Layouts folder. Unlike the CssRegistration, ScriptLink has a property called ‘Localizable’.  In the asp tag below I specify Localizable=”False”

If you don’t specify Localizable=”False” then you need to put the files relative to the Layouts\1033 folder.



Below is the rendered html output of the ScriptLink tag above


You can see that the “/_layouts/” is prepended to the ‘Name’ property provided in the ScriptLink tag and your .js file is successfully cache safe.

What if I am deploying files to the Style Library?

In the scenario where you are deploy CSS to the Site Collection style library then there is no automated way of using the SharePoint cache busting from the CssLink, however you can take a look at Chris O’Brien’s posting – Avoiding bugs from cached JavaScript and CSS files in SharePoint. In this posting he has a solution in which he creates a new class inheriting from CssLink and adds his own mechanism of cache busting. He also mentions that there is no equivalent way to do the same for JavaScript files stored in the content db.


SharePoint 2010 provides an easy way to do cache busting on CSS and JS files stored in the LAYOUTS folder.

If you store your files in the ‘Style Library’ or content DB then you have to revert to manual methods or get creative with your own solutions.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.