Don't Let Third Parties Slow You Down Arvind Jain, Michael Kleber Google

Web is slow Average page load time: 4.9s Pages are complex: on average, 44 resources from 7 domains, and 320KB A lot of what's loaded is third party content o Digg o Facebook Connect o Twitter o Tribal Fusion o Yahoo Widgets o GlamMedia o DoubleClick, AdSense,...

Typical Example: Digg Widget digg_id = ‘digg-widget-container’; //make this id unique for each widget you put on a single page. digg_title = ‘Top 10 list from Technology’; snippet code as of Feb 23, 2010 Impact: 9 HTTP requests, 52 kB transferred over the wire. scripts block the main page’s content from downloading stylesheet blocks the main page from rendering in IE.

Latency Impact: Knockout Lab Load some publisher pages with and without third party content Testing our own code's effect on top 100 publishers' latency: AdSense: Responsible for 12.8% of pageload time Analytics: < 5% (before launch of the asynchronous GA snippet)‏ Doubleclick: 11.5% Our internal measurements of some other snippets:

Making Google AdSense Fast By Default

The Problem google_ad_width=300; google_ad_height=250; <script src="

The Goal Minimize Time Blocking the Publisher Page No retagging! Put the ad right here: Must run in publisher domain

Our Solution: ASWIFT –Make show_ads.js a tiny loader script –Loader creates a same-domain iframe –Loads the rest of show_ads into the iframe by document.write() of a tag. Asynchronous Script Written into IFrame Tag

Our Solution: ASWIFT var adsHtml = ' google_ad_width=300;... '; document.write(' '); var idoc = document.getElementById('foo'). contentWindow.document; idoc.open(); idoc.write(adsHtml);

Results Old show_ads.js47 ms288 ms ASWIFT11 ms32 ms Time spent blocking the page, once the script has loaded. median90th %ile

Browser-specific Surprises Parallel downloads of same script in IE Iframe creation inside in Firefox Request headers in Chrome Forward-Back-Reload behavior

Browser-specific Surprises Parallel downloads of same script in IE Some web pages have multiple ad blocks on them. If you use this technique in multiple iframes at the same time, IE seems to sometimes abort a second frame's fetch when the fetch for the first frame completes. We handle this by serializing the fetches, only doing it in one iframe at a time.

Browser-specific Surprises Iframe creation inside in Firefox In Firefox, when you document.write an tag from, there's no way to get a handle on the DOM object until. In this case, we don't use this technique.

Browser-specific Surprises Request headers in Chrome Chrome developer tools showed malformed HTTP headers on the requests inside the iframes. Fortunately, wireshark showed that the requests were fine; the dev tools were reporting incorrectly. (Whew.)‏

Browser-specific Surprises Forward-Back-Reload behavior When a user reloads a web page, this technique causes some browsers to reissue the request created by the show_ads_impl javascript. (The JS doesn't rerun; the URL it generated the first time is reloaded.) Be warned, since this behavior might be different than what happened before.