A few months ago, I had some great discussions with some like-minded people that work on big web applications. Several of us asked the same question:

How are new standards and browser features going to support our goal of making the whole web faster?

I was specifically interested in Ads. Can HTML5 help content owners and ad networks make ads faster? Ads frequently block rendering, because ad snippets include external <script> tags that cannot be deferred because the script response relies on document.write() to make inline modifications to the document.

Framing ads with <iframe>

Placing ads within an <iframe> can eliminate render blocking behavior because framed resources can load in parallel. Content providers don’t generally choose to do this for several reasons:

  • Infrastructure: The content provider must implement a server side “shim” resource to host the <iframe> contents and the ad snippet.
  • Latency: Framing effectively adds another costly level of indirection for ad fetches.
  • Slow by Default: Ad networks generally don’t provide framed snippets and content providers need special knowledge to safely make changes.

Ad networks don’t provide snippets that frame ads for several other reasons:

  • Robustness: <iframe> dimensions are absolute. Contents can’t exceed boundaries, so expandable ads are not supported. <iframe>s limit flow options within a document and cannot inherit style from the host page.
  • Matching and Accounting: The referrer exposed to the ad network when ads are framed doesn’t match the target document, making it difficult for ad networks to crawl and comprehend the context of the pages they are displayed on.

<iframe> has some new features in HTML5 that address these issues head-on:

<iframe srcdoc>

The srcdoc attribute enables <iframe> contents to be specified inline, so ad snippets can be framed and ad resources can load in parallel with other content. The referrer indicated when following links within the frame is the URL of the host document, so accounting and matching aren’t harmed.

Yes, the contents of the <iframe> are specified as an HTML attribute.

<iframe seamless>

The seamless attribute enables <iframe> contents to flow like any other DOM element, making expandable or dynamically sized ads possible. <iframe> contents can inherit style from the parent document.

Migration

Ad snippets that support seamless/srcdoc will need to provide graceful fallback to non-framed behavior for the foreseeable future. Below is an example ad snippet that uses seamless/srcdoc when supported and injects the snippet into the DOM when not supported:

Provided Ad Snippet:

<script type="text/javascript"><!--
  ad_width = 300;
  ad_height = 250;
//--></script>
<script type="text/javascript" src="http://www.example.com/ad/show_ads.js"></script>

Modified for seamless/srcdoc:

 <iframe src="about:blank" seamless srcdoc="
   <script type=text/javascript><!--
     ad_width = 300;
     ad_height = 250;
   //--></script>
   <script src=http://www.example.com/ad/show_ads.js></script>
 ">
 </iframe>
<script> 
    // Support for pre-srcdoc browsers
    var iframes = document.getElementsByTagName("iframe");
    var iframe = iframes && iframes[iframes.length-1];
    var srcdoc = iframe && iframe.getAttribute('srcdoc');
    if (srcdoc && !supports_srcdoc()) {
      iframe.parentNode.removeChild(iframe);
      document.write(srcdoc);
    }
 </script>

* supports_srcdoc() is a function that determines whether a browsers supports the srcdoc attrbiute.

This is a very simple example that doesn’t address edge cases. For example, some ad networks rely on sequential fetching to ensure the same ad doesn’t get displayed twice. This is easy enough to support and shouldn’t have any impact on our ability to load host page resources in parallel.

If you run ads on your content, I hope this motivates you to consider seamless and srcdoc. As of this writing, no browsers have released support for these features. But that’s good news: You have a chance to influence these implementations if our needs aren’t yet met.

ABOUT THE AUTHOR
Kyle Scholz photo

Kyle Scholz
Staff Software Engineer, Web Search Infrastructure, Google

Kyle leads a team focused on front end infrastructure for Web Search at Google. Most recently, he helped launch Google Instant. He is a coauthor of Google Page Speed and contributor to open source projects including JSViz. He blogs occasionally at kylescholz.com