views:

401

answers:

3

Some display advertising campaigns are very JavaScript heavy and it has a jarring effect on page load time because the ad is generally inline JavaScript - the useful parts of the page doesn't render until the ad did its thing.

A solution seems to be to load the ad in an iframe in order to display useful content to a user while the ad loads in the background and "snaps into place" when it is ready.

I've been told a number of drawbacks of an iframe approach:

  • You are limited in the types of campaigns you can host - for example, no expanding ads that roll over content.
  • If you have multiple ad units on one page you can't have combined campaigns.
  • Advertisers avoid iframes because it is easier to game the system with false impressions

Are these real concerns? If so, are there any workarounds or should I keep display ads on page?

+1  A: 

Those are valid concerns. I would also add that:

  • When search engines find the advertisement, they will add them to their database as separate web pages, i.e. the link in the search results will be to the ad page (iframe), not to the page that contains the iframe.

  • It is more difficult for users with limited accessibility to navigate to the ads and click on their links. For example, if the user has keyboard access only.

Bruno Rothgiesser
I was hoping to also get some workarounds or ways that people deal with these issues.
leonm
A: 

@Bruno I wouldn't think that - you could always disallow the folder in which you place the iframe files in your robots.txt.

Also - I doubt if very many users use just a keyboard these days!

No offense meant!

+1  A: 

In my experience we have not had any problems with placing display advertising in IFRAMEs.

  • We still have ads that display expanding content over the rest of the page. For this to work, it requires the company delivering the creative to support "iframe busting" which does require you to host a special file on your web server. Pointroll, Eyewonder and the like support this. The actual calls to the ad network (doubleclick in our case) don't change really. Note that we have a policy of allowing expandable IFRAME content only on user-click; perhaps that is a key factor that enables this technique.
  • I'm not sure what a "combined campaign" but I'm not sure how it'd be impacted. Our calls to Doubleclick don't change - all the same parameters are supported in terms of identifying the site, zone, location, size, tile etc.

We moved to an IFRAME model from Javascript mostly for the freebie "asynchronous" aspect of IFRAME loading and also because it acts as a sandbox; we found cases where faulty ad creative could overwrite our whole DOM and blow up the page on certain browsers.

There are now techniques that can be used to load content via Javascript and still be asynchronous (XHR injection) but its not for the faint-of-heart and is likely to be incompatible with ad serving anyway due to the need to serve content off the same domain.

Note that moving to IFRAMEs won't reduce page load time as measured by any kind of browser plugin, but it will at least background-load the ads meaning the browser won't halt rendering for the Javascript. We've also experimented with techniques that utilize Javascript to defer the enabling of the IFRAME src parameter until a time that we're ready to let the Ads start downloading (for example, after the above-the-fold parts of the page have rendered). However, its a fine balance between showing the paying Ad content and your page's main content.

Tim