At Google we’re constantly trying to make the web faster — not just our corner of it, but the whole thing. Over the past few days we’ve been rolling out a new and improved version of show_ads.js, the piece of JavaScript used by more than two million publishers to put AdSense advertisements on their web pages. The new show_ads is small and fast, built so that your browser can turn its attention back to its main task — working on the rest of the web page — as soon as possible. This change is now making billions of web pages every day load faster by half a second or more.
The old show_ads did lots of work: loading additional scripts, gathering information about the web page it was running on, and building the ad request to send back to Google. The new show_ads has a different job. It creates a friendly (same-origin) iframe on the web page, and starts the old script with a new name, show_ads_impl, running inside that iframe. The _impl does all the heavy lifting, and in the end the ads look exactly the same. But there’s a substantial speed advantage: many things happening inside an iframe don’t block the web browser’s other work.
How much of an effect this has depends on context: a page with nothing but ads on it isn’t going to get any faster. But on the real-world sites we tested, the latency overhead from our ads is basically gone. Page load times with the new asynchronous AdSense implementation are statistically indistinguishable from load times for the same pages with no ads at all.
The new show_ads is a drop-in replacement for the old one: web site owners don’t need to do anything to get this speed-up. But these dynamically-populated friendly iframes are finicky beasts. For now, we’re only using this technique on Chrome, Firefox, and Internet Explorer 8, with more to come once we’re sure that it plays well with other browsers.
And what if you’ve built a page that loads AdSense ads and then manipulates them in exotic ways not compatible with friendly iframes? (This is the web, after all, land of “What do you mean that’s ‘not supported’? I tried it, and it worked!”) You can set “google_enable_async = false” for any individual ad slot to revert to the old blocking behavior. But if your site loads ads in some tortuous way because you were looking for latency benefits, consider giving the straightforward invocation of show_ads.js a whirl. Because now, we’re fast.
Subscribe to:
Post Comments (Atom)
This comment has been removed by the author.
ReplyDeleteCongratulations! I couldn't help thinking though that if the latency overhead from Google ads is "basically gone", then the Ads Latency Team is now... redundant! Oh well - I hear Facebook's hiring ;-p
ReplyDeleteGood news
ReplyDeleteExcellent news for wpo workers!
ReplyDeleteSweet, this is awesome! Nice work Michael and team. Is it possible to load the code itself asynchronously as well (ok, now I'm just greedy).
ReplyDeleteI understand the need to limit browsers, but it seems like just those 3 is a little restrictive. For example, I use Opera, which would likely work with this new method if I masked my user agent. Would it make more sense to blacklist?
ReplyDeleteIs Adsense still serving content from third parties? (Bad example: an ad for McDonalds coming from mcdonalds.com.) Last time I checked this is what caused the biggest slowdown, at least according to the timelines on various speed test sites.
ReplyDelete@Brian: Chrome, Firefox and IE8 cover at least 80% of visitors which is a pretty big chunk.
Would you consider making it possible for sites to directly include the appropriate iframe, rather than having the script construct it? That would allow Google ads without including third-party scripts directly on the site.
ReplyDeleteNice job. Thank you!
ReplyDelete@BrianH, they did say they'll roll it out to other browsers once they're sure it works well with them. Patience, good sir, they're working as fast as they want. :P
ReplyDeleteAnd so interesting how this excludes Safari (built with webkit which is same underlying engine as Chrome so therefore more likely to be supported...)
ReplyDeleteAnd note, this basically suggests that google is admitting that their ad code was previously slowing down the internet in a visible way.
Why not just run Adblock Plus and never pay to see those ads again -- and block adware spying/tracking at the same time?
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteor, put another way, you've fixed code that was slowing down our web.
ReplyDeletegood spin though
Fans of other browsers: fear not, we plan to extend as soon as it's safe to do so. The async iframe technique is delicate enough, though, that each of the three browsers we're launching on now had some idiosyncrasies that we had to address — and several we didn't launch on certainly have new and different ones.
ReplyDelete@Matt, thanks for your concern for my job security. But see the comments from @Patrick Meenan and @Anon4yqABAte: Ads Latency Team has no shortage of future work.
—Michael Kleber
So I guess I'll turn on an adblocker for adsense then until you fix the performance bug for Safari.
ReplyDeleteI would read this, if I didn't have to squint.
ReplyDeleteSetting the line-height to 160% and using a slightly bigger font to reduce the words per line would make this blog a much better read.
I'd love to see the code. Is there an unminified version available?
ReplyDeleteThat was much needed as Google Pagespeed always use to show up an optimization tip for external scripts loading on my blog.
ReplyDelete- Sagar
http://aspiredtechie.com
Michael,
ReplyDeleteWhile this is a welcome move, it is still not as efficient as it should be.
Right now, our website uses 8 js files 1 is ours (minified and combined) and 7 from Google:
1 G Analytics js file
6 Adsense js files
We are seriously thinking of dropping Adsense because of that.
Cheers
Definitely a welcome move, but Adsense is still slow and unfortunately this also didn't fix a core issue causing javascript errors for many users over many years (which should be an easy fix...). Very frustrating...
ReplyDelete"Unable to post message to http://googleads.g.doubleclick.net. Recipient has origin mydomain.com"
Solution is at the following, please deploy:
http://stackoverflow.com/questions/2541797/javascript-errors-from-google-adsense
Yeah, sam feeling as comment from CXNET and MISH15 ... there are several errors that need to be fixed. Since this new feature is up, we also noticed problems in Firefox 3.6, that loading of the page freezes on loading AdSense files and scripts, and never finishes ! Reloading page brings up the adsense banners almost immediatly and page works ok. Till next click ...
ReplyDeleteAlso, most of the adsense codes and scripts come up as problematic and slow on ANY measurement tool, including Google Webmaster Tools !!! Google Chrome says
Combine external JavaScript (7)
7 JavaScript resources served from pagead2.googlesyndication.com.
I'm not seeing these improvements on DFP. When will these be rolled out?
ReplyDeleteHow about dfp? It is still blocking loads. When will this been upgraded?
ReplyDeleteHey hotshots, how do you handle expandable ads without a buster?
ReplyDeleteFirefox for Mobile is blocking Adsense ads by default, leaving a white spot. This is killing revenue streams. How can FF block ads by default? It is time to stop using Firefox? What is Google doing about it?
ReplyDeleteWhen can we expect SSL support? Can i have a copy of the .js file in my server and point to that file istead of google server?
ReplyDeleteI was happy with the new iframe method until I noticed flash ads now overlap *everything*, including lightboxes and the semi-transparent backgrounds behind lightboxes. It looks incredibly tacky when it happens, like I'm trying to force visitors to click ads or something by having them overlap lightboxed content.
ReplyDeleteCan't flash ads be set to wmode=transparent to fix this? I do it manually with the new YouTube iframes, but I don't dare try anything with Adsense.
I've noticed that even with the faster loading ads, they still have to finish loading before body.onload is called. This isn't exactly "async".
ReplyDeleteI need to run script in body.onload that decides which form field to focus on. But this script doesn't run until the ads are finished loading. This makes it appear that my site is a poor performer.
Can this be addressed somehow?
Hi
ReplyDeleteLoad time without adsense is 1.4 seconds
Load time with 1 adsense block is 2.9 seconds
You say it basically does not take any extra time. Thats either completely wrong, or there might be some extra tricks I don't know.
The saga continues. I just started using head.js to async. load all my large script's (jQuery, jQuery-UI, etc.) and the speed difference is incredible! In Chrome (Linux 15.0.874.106), pages load almost twice as fast. Simply incredible.
ReplyDeleteBut, now the pages load so fast that the google adsense code, even at the bottom of the page, loads before all external css has had a chance to been fully applied, and thus seems to trigger adsense meltdown. My guess is, that since my adsense div's are "resized" by incoming application of ext. css (some added dynamically for mobile vs. pc), adsense code believes them to be moved or manipulated.
What a shame. I can't fully use the new speed because the google ad's die prematurely. If anyone knows of a way to make the ad's wait until the async. javascript and ext. css loads, I would love to hear about it.