While working with Grunt builds, I've come across the rev
task and the cachebreaker
task for revision / cache busting of static assets.
One uses file name overwrites, and the other adds a timestamp as a query param. And apparently, one is more preferable than the other.
Why is one better than the other?
One of the comments on the link you provided says it best:
"Once you have unique names you can use very aggressive caching headers too, which is great for performance."
With a timestamp you have this version in their example:
<script type="text/javascript" src="@routes.Assets.at("javascripts/main.js")?nocache=@(new Date().getTime())"></script>
It adds a unique timestamp each time the script is requested. This means the browser never caches it.
Alternative, but similar method is to add an internal counter. Something like this:
<script type="text/javascript" src="@routes.Assets.at("javascripts/main.js")?version=1234"></script>
This one is a little better - because each time you change something in your assets, you change the version number. The browser would then load a version only once, and hold it in cache until you build a new version of your static assets.
The downside is that you have to somehow keep track of the version number. You can use something static, like a part of git commit, but still watch over this version + then you're dependant on git (or svn or whatever you use).
The hash version, such as javascripts/main.ab4c6c83e4fa9c.js
has these benefits:
So with these, you don't care about dates, files, anything, you just create your Javascript. You also tell the browser to cache it for as long as it will, like a year or forever. And you're certain that if you switch between versions, the user gets the correct one.