So you might not know exactly what cache busting is by name, but I am sure you have seen it in source code before. We’re talking about when a CSS file looks something like style.css?v235236. So what is that exactly? Well, if you are using static asset caching (if not, take a look at our article on Web Performance) and setting Expires Headers on your server OR you are using a plugin for WordPress like W3 Total Cache or WP Super Cache, you might have run into an issue where you’ve aggressively cached your assets (like you should), but then you make a change to a CSS or JS file and suddenly that change is not being displayed on the site, as if you never updated it. The problem is, if you (or your plugin) tells the client to store this resource for, let’s say a month, and you update your file within that month, the browser will not serve up the newest, most up-to-date version of your script or style. This obviously isn’t good. Let’s take a look at how we can bust that cache and set really long Expires Headers and call it a day (or year).
Basically, what you want to do is tell the browser, “hey, you know that asset you have cached for this, well it’s changed, use this one instead”. Now, there are a lot of ways to go about this and I would suggest using a build script to rev the filename, but that is not what this tutorial is about. What we’re going to focus on specifically is how to do this simply on a site you already have built and may not be using build scripts for production. I’m also going to caveat this method by saying, if you’re using something like WordPress, you should be using wp_enqueue_style and wp_enqueue_script to serve up your CSS and JavaScript and not placing them directly in your header.php or footer.php file, but again, we are just looking at a method that can be used and in fact can be used across any platform, the concept is the same.
So let’s look at how you would normally load a CSS resource:
<link rel="stylesheet" media="screen" href="stlye.css">
Now if that resource gets cached for a month and you update it 3 days later, your users are still going to be seeing the original stylesheet. Basically what we want to do is append a version to the end using a fragment that won’t disrupt the rendering of the file. What we want to add is a ? followed by a v= and a timestamp. In theory, you could append whatever you wanted, you could append random numbers or the names of your favorite dinosaurs, it doesn’t matter, as long as it changes every time you update your file. We will use the PHP filemtime() function and append the timestamp of when the file was modified like so:
<link rel="stylesheet" href="style.css<?php echo '?v=' . filemtime( 'style.css' ); ?>">
So what we are doing here is first we are dynamically pointing to the correct file using the bloginfo() function and then we are appending a ?v to the end with a filetime(file) function to make it spit out something like:
<link rel="stylesheet" media="screen" href="style.css?v=1353454965">
Not necessarily readable to a human, but it’s a nice dynamic way to update the filename every time you make a change. Piece of cake. Now we can set really long expires headers and not worry about it. Just a reminder, when using WordPress you should be using the built in enqueue script and style functions mentioned above, there is a version parameter where you can use this same technique and load up your assets correctly, just wanted to write out a proof of concept for those who have been hearing about cache busting but may not know what it is exactly.