A little while ago I talked about setting up a rails app to use Amazons Cloud Front.  This is just a little snippet on how to use a cache buster.  It was an adaptation of what we have and this article I found on how to do it in rails 3.  Follow the article I linked to and then use the following initializer instead of the config setup (production.rb) as described in the article:

if AppConfig['asset_base_domain'] ActionController::Base.asset_host = Proc.new { |source| (url,qs) = source.split(/\?/) append_host = '' if AppConfig['cloudfront_enabled'] append_host = "/r-#{qs}" end if url.end_with?('js') "http://js.#{AppConfig['asset_base_domain']}#{append_host}" elsif url.end_with?('css') "http://css.#{AppConfig['asset_base_domain']}#{append_host}" else "http://images.#{AppConfig['asset_base_domain']}#{append_host}" end } end

The web is full of stuff we see everyday, maybe multiple times in a single day. The Google Homepage, the Facebook logo and layout being 2 prime examples. Question is, do you think your browser always loads everything fresh from the servers on every single page load? Answer, of course not.

If your browser realizes that it has already downloaded a webpage or image, it will normally refer back to is stored version (known as the cache). This helps speed up your internet as only the dynamic content is retrieved from servers, whilst files already on your computer fill in the regular parts.

Here we assume this is the users second visit to Facebook. The logo, Sign Up button and Login widget are the same each time, so these are loaded from the browser cache. The large image on the left is different each time, so this needs to be dynamic and load fresh from the web with every visit.

So why do marketeers care about cache so much, and why is it usually to blame for everything?  In order to count properly (impressions and to some degree clicks), the 3rd party (publisher, adserver, affiliate network, exchange etc.) must be contacted in some way by the user. If the file is retrieved from the cache and not the 3rd party's servers, then they will have no idea that the event occurred. Cue naughty cache comments. Cached inventory causes differences in reporting volumes (which is what people care about), but more importantly it removes control of what is delivered (the thing people should care more about). A cached banner will never rotate, effectively spoiling any sequencing or retargeting. We can get over counting discrepancies, but poor media performance cannot be rectified with a handshake.

How can a defeat this pesky Cache Monster? Simply adding a random/changing part to the url is enough to trick the browser into thinking the content is "new".   

Any tag you generate from an adserver or affiliate network should come with some instructions or an indication of where to put a cache-buster. If it doesn't call your rep straight away, and if they don't know, permission from me to slap them round the face with a freshly caught salmon (I believe line caught is the best these days from an ecological stand point). Cache-busting is the single most important thing for your publishers to take care of, so the same punishment applies to them if they neglect to implement it.

If we look at a DoubleClick Ad tag:

<SCRIPT language='JavaScript1.1' SRC="http://ad.uk.doubleclick.net/adj/N137./ BXXXXXXX.2;ord=[timestamp]?"></SCRIPT> <NOSCRIPT> <A HREF="http://ad.uk.doubleclick.net/jump/N137./ BXXXXXX.2;ord=[timestamp]?">   <IMG SRC="http://ad.uk.doubleclick.net/ad/N137./ BXXXXXXX.2;ord=[timestamp]?" BORDER=0 WIDTH=728 HEIGHT=90 ALT="Click Here"></A> </NOSCRIPT>

Here I've highlighted the 3 instances that need a cache buster. DoubleClick indicate where a cache-buster is required with [timestamp]. Other companies may use {TIME}, {RANDOM} or [CACHEBUSTER], but it's all the same thing. The reason Time is bought into this, is because it's an easy random number to generate, since the time is ever changing.

If you are a publisher and using DFP (DART for Publishers) then you will use %n as your cache-buster value. Publishers using the wonderful OpenX platform should use {random} and refer to the Magic Macros list here.

That's right, 99.9% of publisher tools have a cache busting macro built in, so no excuses!