iFrame or JavaScript ad tags?

Published by: Laura McKay , Comicbook.com
Published on: September 16, 2010

I've worked for several publishers (500k-5M UVs - comScore) and deal with this recurring problem:

When testing a new ad server, the executives always say that in-line JavaScript calls to 3rd parties (specifically ad networks) are just too slow. But as we get going, remnant is all we have to fill those spaces. The frequent answer to this issue is to use iFrame ad tags that allow the ad to load asynchronously from the rest of the page. And inevitably the next issue is that we cannot run expandable creative using iFrame tags. Serving expandable creative should be no problem these days.

Ad server customer service teams give work-arounds for JavaScript that may or may not be supported by their own company. And the solution is always a delicate "technical workaround" which frustrates the developers and the ad operations team.

Right now the developers are working on a JavaScript call with a hidden DIV at the bottom of our pages which will render the ads to the correct placements when the ad call is complete.

How are the rest of you solving the iFrame vs JavaScript tagging question?
Do you use iFrame and block all expandable creative? Has this impacted revenue?
Are all of you using a workaround customized for your site needs? If so what ad servers are you using?
If you're not having this problem or have overcome it easily, what ad servers are you using?

Thanks in advance for your input.


Regarding the expanding within iframe issue, nearly all if not actually all rich media providers provide publisher hosted server side "iframe buster" files that the expandables seek out when they detect themselves as being loaded within a frame. When these files (called both as relative and fixed paths, unfortunately, depending on vendor) are hosted and called they allow whatever expandable ad loaded within a frame to break the bounds of it and expand over the frame's set w/h. There are other issues to note with iframes, but for ads, this seems to be the largest. If you go all in with iframes - even by just wrapping your remnant in iframes, if you accept expandable remnant ads - you'll note them all:

1) new vendors need new pub side files
2) atlas requires tag-by-tag modification to include the location of the server side file
3) dfa requires tag-by-tag modification if the location of the server side file if it is not the default dclk location (put it in the default location for ease of use)
4) surveys may need to expand from iframed ad calls - means you need a server side file for your marketers' research partners as well

Also, research the concept of friendly iframes. Apparently they are quite helpful in this aspect of things. I have yet to see or work on an implementation of them however.

Good luck!

the easiest solution would be inline javascript on your pages but serve iframe tags for all your networks. If you can alter your network tags slightly so they add an iframe element instead of using a document.write you could get quite a good speed increase. you will only have the latency of your own adserver loading, be able to serve expandables if you want but remnant will still be loaded asynchronously.

Rocket Fuel