What is a Cache Buster?

A cache-buster is a unique piece of code that prevents a browser from reusing an ad it has already seen and cached, or saved, to a temporary memory file.

What Does a Cache-Buster Do?

The cache-buster doesn’t stop a browser from caching the file, it just prevents it from reusing it. In most cases, this is accomplished with nothing more than a random number inserted into the ad tag on each page load. The random number makes every ad call look unique to the browser and therefore prevents it from associating the tag with a cached file, forcing a new call to the ad server.

Cache-busting maximizes publisher inventory, keeps the value and meaning of an impression constant, and helps minimize discrepancies between Publisher and Marketer delivery reports.

What Does a Cache-Buster Code Look Like?

Typically, a java script function like the one below powers a cache buster. An example of a cache buster looks like this:

<script type="text/javascript" language="JavaScript">

This code is put toward the top of the page within the site’s <body> tag and creates a random number for the “ord” value in the ad tag. So, when a browser hits a tag, it builds the ad tag like this –


If the browser then returns to the same page later on, the same tag might look like this, where everything remains the same except for the random number.


Why Does a Browser Cache in the First Place?

When a browser navigates to a web page today, the Publisher’s Content Server sends it an HTML file with instructions on how to format the page and where to retrieve all the images, text, and other pieces of the page.  Downloading this information all takes time and memory to accomplish for the browser, so it tries to save as much of the information as possible for future use in temporary folders (the cache) on a user’s hard drive.

This technique lets a browser surf through a website much faster.  It’s less important in an age of high speed fiber optic connections, but made a huge difference in the days of 56K modems, when each page took seconds if not minutes to load.  And, since most web pages are built on templates, many elements of a site are used on every page, for example, the site’s logo.  Why fetch the same image again and again when the browser can save it once, and simply reference the same file on every page? The browser is smart enough to read the HTML code for each page and recognize what content it already has and just skip to the next line of code to look for the unique and previously unseen data.

This would certainly work for the ads on the page, too.  If a user loaded a publisher’s homepage for example, then went to an article page, then back to the homepage, the ad tag would be exactly the same and the browser would just re-use the ad it called the first time if a cache-buster was not implemented. Since Publishers get paid for every impression though, they don’t want this to happen, they want the browser to call or consume another impression so they can charge for it. Advertisers might like the idea of free impressions, but when pressed, most would tell you cache-busting is a good thing for them, too. Recycled ads screw up reports, mess with ROI calculations, and add an uncertainty factor to campaign data, not to mention create tension between Publishers and Advertisers via discrepancies.

In fact, if you are having an issue with 3rd party discrepancies where the publisher numbers are much higher than the advertiser numbers, the first thing you should check is that a cache-buster is in place and working.


  1. I mean even though the javascript is generating a random number, it is loading the same script


    to bust a browser cache, I thought a tried an true method was adding a query param to the src or href attribute, as is done in your blog:

  2. Well it’s certainly true there is one method – a query string will do the trick, too, and is probably more common among dynamic web pages from a content point of view, but in terms of ads, I think you’ll typically see the random number generator technique. The reason being is that because the systems that produce the ad are often owned by more than one company, so they need a static URL to reference. You can often find the ad’s location on the CDN, such as an Akamai by looking at the src, and because that address is static, you have to make something else about the call dynamic. Since DoubleClick’s DFP product is one of the most common adservers out there and has perhaps the most transparent cache buster, I wanted to showcase that method in particular.

  3. Any thoughts on how these random number generated cache busting scripts work on WP sites that utilize aggressive cacheing plugins like W3 Super Cache. We’re having trouble with one sponsor where the numbers being reported by their 3rd party verification script are wildly lower than the numbers we see….

  4. Hi Emily,

    If you are using Doubleclick, you usually need to implement a shortcode that calls a system macro – in Doubleclick’s case I believe the macro is %n, but I would check with your support rep to be sure. If you aren’t on Doubleclick you can still likely use a shortcode, which your ad server can provide you with, or which they may have already implemented in the tag itself for you.

    Good luck!


  5. I actually use WP Super Cache on my site, and serve ads as well, and I haven’t seen an unexpected variance in the figures, so I’m not sure I would point the figure there. It sounds like you only have a cache buster on the publisher side tags, and not the advertiser tags. To prevent browser caching you need a buster in both places, otherwise the browser keeps generating a call to you, but still caches the advertiser’s redirect. If you are only serving one ad, or mostly this one ad, you’ll be especially susceptible to the discrepancy issue you mention, because a greater percent of the impressions will go to the same group of users, which will cache the ad.

    Typically the publisher needs to implement a cache buster macro on the advertiser’s tags by inserting their ad server’s cache busting macro into the advertiser’s tags. Usually if the tags you receive are dynamic, you’ll see some kind of {timestamp} value, which you need to replace with your own ad server’s cache busing macro.

    Hope that makes sense, I’m pretty sure that’s what your problem is –


  6. Ben,

    I did a google search for [CACHEBUSTER] when I found your article. I’m trying to decide, is this something that would behoove me to leave in, or should I take out? Also, if I took it out (in case I wanted to send an email with just a hyperlink to my landing page) would the link and all elements of it still work (minus the cache busting)?

    Also, if doing a PPC campaign, does having the cachebuster help, hinder or is it indifferent when it comes to the way your numbers are tracked. I have no intentions of modifying any links, just trying to learn so that I can use all of my codes and links effectively.


  7. Hi Jonathan,

    If you care about unique requests to an asset, then you should leave it in, or if you expect to serve a different message on each call, you should leave it in. If, on the other hand, you just want to serve a static asset, then you may not really need it. I would say it’s little work to put in, and you get more options by having it there, so I would defer to having it if there’s not a compelling reason either way. It’ll be better training for potential future needs to always check for it and implement it if you’re in the digital ad game.

    In terms of a PPC campaign, you’d want to have a cachebuster in place, because you’d want to know how effective the distribution points of your message are. If you don’t have a clean impression number for your denominator in a CTR calculation, how can you expect to optimize the campaign?

    Hope that helps!


  8. Just so you know, [CACHEBUSTER] does not indicate that there is a cachebuster there. It is indicating that is where the cachebuster needs to go. The [CACHEBUSTER] portion of your ad tag needs to be replaced with a macro that calls a unique variable.


  9. Hi Rajesh,

    Sorry for the late reply – iFrame busting in the context of digital advertising is the method by which certain rich media ads are allowed to expand on a user’s screen, as well as some javascript-based technologies scrape information from the page.

    For example, if a publisher wanted to enable an advertiser’s tag to expand from 300×250 to 600×500, and was using an iFrame to load ads asynchronously on their page, they would need to allow the advertiser’s tag to “break” the pre-set dimensions of their iFrame. Technically speaking though, because the rules on which Javascript was built does not allow two iFrames to talk to each other if they are from different domains – for example, a publisher domain and a 3rd party ad server domain – there isn’t a way for the 3rd party ad tag to tell the publisher’s page that it needs to serve an image larger than that of the iFrame.

    So to address this problem, rich media vendors ask that publisher place a file in the publisher ad server’s subdomain. This file doesn’t really have a name in the ad tech world, some just call it a publisher file, others call it a bridge or gateway file, but all rich media companies have it. This file’s location must be known to the rich media vendor, and then what happens is when a rich media tag loads into that publisher’s iFrame, it quickly looks up that file (some javascript), sends some various parameters (things like the unique identifier for the ad that needs to serve) to the that file, which then makes another request to the rich media vendor. Basically, the 3rd party ad tag redirects itself through the publisher file so that the request appears to come from the publisher’s domain, because the javascript is hosted on the publisher’s domain. That solves the problem of allowing the iFrame to talk to the publisher’s page, and the iFrame is thereby allowed to expand.

    I know this is probably a little confusing – Pointroll has a good explanation on their side, and an example file you can actually look at: https://wiki.pointroll.com/display/PRRC/iFrame+Delivery+Specs

    Other technologies that want to bust iFrames are technologies like ad verification, which want to know the URL of the page they are serving on so they can report it back to an advertiser. This is where I start to get out of my technical depth – I know a single or even two nested iFrames can be busted by various clever javascript coding to scrape information from the page, but I’m not exactly sure how that is done. If you got a sample tag and could understand JS, you could probably look at the response code and figure it out.

    Hope that’s helpful!


Leave a Reply

Your email address will not be published. Required fields are marked *