{"id":206274,"date":"2015-08-14T11:49:51","date_gmt":"2015-08-14T18:49:51","guid":{"rendered":"http:\/\/css-tricks.com\/?p=206274"},"modified":"2017-10-12T14:25:17","modified_gmt":"2017-10-12T21:25:17","slug":"strategies-for-cache-busting-css","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/strategies-for-cache-busting-css\/","title":{"rendered":"Strategies for Cache-Busting CSS"},"content":{"rendered":"

Major performance gains are to be had from browser caching CSS. You ensure your server is set up<\/a> to send headers that tell the browser to hang onto the CSS file for a given amount of time. It’s a best-practice that many if not most sites are doing already. <\/p>\n

Hand-in-hand with browser caching is cache busting<\/em>. Say the browser has the CSS file cached for one year (not uncommon). Then you want to change the CSS. You need a strategy for breaking the cache and forcing the browser to download a new copy of the CSS.<\/p>\n

Here are some ways.<\/p>\n

<\/p>\n

The CSS has to be cached for this to matter…<\/h3>\n

Just to make sure, here’s what some healthy looking headers look like for a cached CSS file:<\/p>\n

<\/figure>\n

We’re looking for that Cache-Control<\/code> and Expires<\/code> header. I’m not a server config expert. I’d probably look at the H5BP server configs. But here’s some kinda classic Apache\/HTAccess ways to get that going:<\/p>\n

<FilesMatch \"\\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)(\\.gz)?$\">\r\n  Header set Expires \"Thu, 15 Apr 2020 20:00:00 GMT\"\r\n<\/FilesMatch><\/code><\/pre>\n
<IfModule mod_expires.c>\r\n  ExpiresActive on\r\n  ExpiresByType text\/css                  \"access plus 1 year\"\r\n  ExpiresByType application\/javascript    \"access plus 1 year\"\r\n<\/IfModule><\/code><\/pre>\n
Query Strings<\/h3>\n
Most browsers these days will see a URL with a different query string as a different file and download a fresh copy. Most CDN’s even support and recommend<\/a> this.<\/p>\n
<link rel=\"stylesheet\" href=\"style.css?v=3.4.1\"><\/code><\/pre>\n
Make small change? Change it to:<\/p>\n
<link rel=\"stylesheet\" href=\"style.css?v=3.4.2\"><\/code><\/pre>\n
You could potentially make it easier on yourself by setting a server side variable to use in multiple places. Thus changing it would break cache on lots of files at once. <\/p>\n
<?php $cssVersion = \"3.4.2\"; ?>\r\n\r\n<link rel=\"stylesheet\" href=\"global.css?v=<?php echo $cssVersion; ?>\"><\/code><\/pre>\n
Perhaps you could even use Semantic Versioning<\/a>. You could also define a constant<\/a>.<\/p>\n
Changing File Name<\/h3>\n
Query strings didn’t always work. Some browsers didn’t see a differnt query string as a different file. And some software (I’ve heard: Squid<\/a>) wouldn’t cache files with query string. Steve Souders told us not to<\/a>.<\/p>\n
A similar concept was to change the file name itself. Like this in the HTML:<\/p>\n
<link rel=\"stylesheet\" href=\"style.232124.css\"><\/code><\/pre>\n
You would handle this programmatically, not literally change the file name in your project. Since that file doesn’t actually exist on the server, you’ll need to perform some trickery to route it to the right file. Jeremy Keith covered his technique<\/a> for this fairly recently.<\/p>\n
RewriteCond %{REQUEST_FILENAME} !-f\r\nRewriteRule ^(.+).(\\d+).(js|css)$ $1.$3 [L]<\/code><\/pre>\n
That tells the server to ignore those numbers in JavaScript and CSS file names, but the browser will still interpret it as a new file whenever I update that number.<\/p><\/blockquote>\n
He uses Twig, so the templates he uses are ultimately like:<\/p>\n
{% set cssupdate = '20150310' %}\r\n\r\n<link rel=\"stylesheet\" href=\"\/css\/main.{{ cssupdate }}.css\"><\/code><\/pre>\n
I’m sure you can imagine a version of that in any backend language (like ASP<\/a>). Level up by making a build tool or deployment script update the variable itself.<\/p>\n
Basing Cache Busting “Number” on File Updated Date<\/h3>\n
While searching around about this cache busting stuff, you’ll see a lot of advice recommending you use the server to check when the file was last updated to create the cache busting “number” (number, meaning, whatever thing you change to bust cache).<\/p>\n
function autoversion($url) {\r\n  $path = pathinfo($url);\r\n  $ver = '.'.filemtime($_SERVER['DOCUMENT_ROOT'].$url).'.';\r\n  return $path['dirname'].'\/'.str_replace('.', $ver, $path['basename']);\r\n}<\/code><\/pre>\n
<link href=\"<?php autoversion('\/path\/to\/theme.css'); ?>\" rel=\"stylesheet\"><\/code><\/pre>\n
I can’t speak well to this. It seems to me<\/em> that asking your server to dig up this information on every pageview would be pretty intensive and dangerous in production. In the past I’ve done things like “I’ll just have PHP output the dimensions of the image in data attributes!” only to find it grinds the server to halt. Anyway, beware.<\/p>\n
ETags<\/h3>\n
ETags kinda seem like a good idea, because the whole point of them is information to check if the browser already has a copy of that file. <\/p>\n
But most advice out there says: “turn off your ETags headers”. Yahoo says<\/a>:<\/p>\n
The problem with ETags is that they typically are constructed using attributes that make them unique to a specific server hosting a site. ETags won’t match when a browser gets the original component from one server and later tries to validate that component on a different server, a situation that is all too common on Web sites that use a cluster of servers to handle requests.<\/p><\/blockquote>\n
Another issue is that they just aren’t as effective as actual caching. In order to check an ETag, a network request still needs to be made<\/a>. It’s not just the downloading of files that affect performance, it’s all the network negotiation and latency stuff too.<\/p>\n
Again, not an expert here, but here’s what’s generally recommended to turn them off in Apache land:<\/p>\n
<IfModule mod_headers.c>\r\n  Header unset ETag\r\n<\/IfModule>\r\nFileETag None<\/code><\/pre>\n
Framework Does It For Us<\/h3>\n
Rails Asset Pipeline<\/h4>\n
I have a little experience with the Rails Asset Pipeline<\/a> and Sprockets<\/a>. It’s kind of a dream system if you ask me. I link up stylesheets in templates:<\/p>\n
<%= stylesheet_link_tag \"about\/about\" %><\/code><\/pre>\n
And it produces HTML like:<\/p>\n
<link href=\"http:\/\/assets.codepen.io\/assets\/about\/about-7ca9d3db0013f3ea9ba05b9dcda5ede0.css\" media=\"screen\" rel=\"stylesheet\" type=\"text\/css\" \/><\/code><\/pre>\n
That cache busting number only changes when the file changes, so you only break cache on the files that need broken. Plus it has methods for images and JavaScript as well.<\/p>\n
WordPress<\/h4>\n
If you use a page<\/em> caching tool in WordPress, like W3 Total Cache or something, you probably have to be less afraid of that filemtime<\/code> business being too server intensive.<\/p>\n
Gilbert Pellegrom posted a WordPress-specific technique<\/a> using it:<\/p>\n
wp_register_style( 'screen', get_template_directory_uri().'\/style.css', array(), filemtime( get_template_directory().'\/style.css' ) );\r\nwp_enqueue_style( 'screen' );\r\n\r\n\/\/ Example Output: \/style.css?ver=1384432580<\/code><\/pre>\n
The WordPress plugin Busted!<\/a> does this same thing behind the scenes. Just does it kinda automatically to everything.<\/p>\n
CodeKit<\/h3>\n
CodeKit doesn’t have a built in method for changing file names, but it does have a way to execute Shell scripts under circumstances you set up.<\/p>\n
<\/figure>\n
Michael Russell has a blog post<\/a> about how you can inject timestamps into file themselves, which I’m sure you could modify to change the filenames instead.<\/p>\n
Build Tools<\/h3>\n
All the popular task runner \/ build tool thingies have plugins to help change file names. Sufian Rhazi has a post<\/a> on doing it in raw Node.js as well. <\/p>\n
Grunt<\/h4>\n