Cache busting solves the browser caching issue by using a unique file version identifier to tell the browser that a new version of the file is available. Therefore the browser doesn't retrieve the old file from cache but rather makes a request to the origin server for the new file.
Cache busting is a way to prevent browsers from caching your ad content. Cache busting adds a random string to your ad tag each time the tag fires — typically a random number. Because the tag has a different number each time, the browser sends a new request each time.
To enable cache-busting for individual files, select a file, then check the "Cache-bust the output file" checkbox. Note: If you don't see this checkbox, verify that your file's Output Action is set to "Process/Compile".
A cache-buster is a small URL-parameter that should always be added to the tracking pixel URL. If the cache-buster is not added, the browser will re-use previously recognized elements of a website again and again on almost every page. This is a problem for ads, banners and tracking pixels.
The param ?v=1.123
indicates a query string, and the browser will therefore think it is a new path from, say, ?v=1.0
. Thus causing it to load from file, not from cache. As you want.
And, the browser will assume that the source will stay the same next time you call ?v=1.123
and should cache it with that string. So it will remain cached, however your server is set up, until you move to ?v=1.124
or so on.
Two questions: Will this effectively break the cache?
Yes. Even Stack Overflow use this method, although I remember that they (with their millions of visitors per day and zillions of different client and proxy versions and configurations) have had some freak edge cases where even this was not enough to break the cache. But the general assumption is that this will work, and is a suitable method to break caching on clients.
Will the param cause the browser to then never cache the response from that url since the param indicates that this is dynamic content?
No. The parameter will not change the caching policy; the caching headers sent by the server still apply, and if it doesn't send any, the browser's defaults.
It is safer to put the version number in the actual filename. This allows multiple versions to exist at once so you can roll out a new version and if any cached HTML pages still exist that are requesting the older version, they will get the version that works with their HTML.
Note, in one of the largest versioned deployments anywhere on the internet, jQuery uses version numbers in the actual filename and it safely allows multiple versions to co-exist without any special server-side logic (each version is just a different file).
This busts the cache once when you deploy new pages and new linked files (which is what you want) and from then on those versions can be effectively cached (which you also want).
As others have said, cache busting with a query param is usually considered a Bad Idea (tm), and has been for a long time. It's better to reflect the version in the file name. Html5 Boilerplate recommends against using the query string, among others.
That said, of the recommendations I have seen which cited a source, all seem to take their wisdom from a 2008 article by Steve Souders. His conclusions are based on the behaviour of proxies at the time, and they may or may not be relevant these days. Still, in the absence of more current information, changing the file name is the safe option.
It will bust the cache once, after the client has downloaded the resource every other response will be served from client cache unless:
In general this should be fine, but it's possible for this to not work if there is an intermediate cache (a proxy) that is configured to ignore the request parameters.
For example, if you are serving static content through Akamai CDN, it can be configured to ignore request parameters to prevent cache busting using this method.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With