Speeding up 3rd party widgets using ASWIFT

This is a summary of the talk by Arvind Jain, Michael Kleber from Google at velocityconf about how to write widgets using same domain iframe using document.write. Speed improvements of over 90% in loading widgets with this change.

  • Web is slow
    • Avg page load time 4.9s
    • 44 resources, 7 dns requests, 320kb
    • Lot of 3rd party widgets
      • digg/facebook/etc
  • Measurements of 3rd party widgets
    • Digg widget
      • 9 HTTP requests, 52 kB
      • scripts block the main page from downloading
      • stylesheets blocks the main page from rendering in IE
    • Adsense takes up  12.8% page load time
    • Analytics takes up < 5%   ( move to async widget )
    • Doubleclick takes up 11%
  • How to make Google AdSense “fast by default”
    • Goals / Challenges
      • Minimize blocking the publishers page
      • Show the ad right where the code is inserted
      • Must run in publishers Domain
    • Solution (ASWIFT) – Asynchronous Script Written into IFrame Tag
      • Make show_ads.js a tiny loader script
      • Loader creates a same-domain iframe (using document.write)
      • Loads the rest of the show_ads into the iframe by document.write() of a <script> tag
      • This loading of iframe is asynchronous.
    • Browser specific surprises
      • Problems with parallel downloads of same script in IE
      • Iframe creation inside <head> in Firefox has a problem
      • Requesting headers in Chrome was buggy
      • Forward-Back-Reload behavior is buggy (refetching instead of using cache)
      • document.domain vs friendly iframes

Urs Holzle from google on “Speed Matters”

From Urs’ talk at the velocity2010 conference [ More info : Google, datacenterknowledge ]

  • Average web page – 320kb, 44 resources, 7 dns lookups, doesn’t compress 3rd of its content
  • Aiming for 100ms page load times for chrome
  • Chrome: HTML5, V8 JS engine, DNS prefetching, VP8 codec, opensource, spurs competition
  • TCP improvements
    • Fast start (higher initial congestion window)
    • Quick loss recovery (lower retransmit timeouts)
    • Makes Google products 12% faster
    • No handshake delay (app payload in SYN packets)  [ Didn’t know this was possible !!! ]
  • DNS improvements
    • Propagate client IP in DNS requests (to allow servers to better map users to the closest servers)
  • SSL improvements
    • False start (reduce 1 round trip from handshake)
      • 10% faster (for Android implementation)
    • Snap start (zero round trip handshakes, resumes)
    • OCSP stapling (avoid inline roundtrips)
  • HTTP improvements (SPDY):
    • Header compression
    • Stream multiplexing and prioritization
    • Server push/hints
    • 25% faster
  • Test done
    • Download the same “top 25” pages via HTTP and SPDY, network simulates a 2Mbps DSL link, 0% packet loss – Number of packets dropped by 40%
    • On low bandwidth links, headers are surprisingly costly. Can add 1 second of latency.
  • Public DNS:
    • reduces recursive resolve time by continuously refreshing cache
    • Increases availability through adequate provisioning
  • Broadband pilot testing going on
    • Fix the “last mile” complaint
    • Huge increase of 100x
  • More developer tools by Google
    • Page speed, speed tracer, closure compiler, Auto spriter
  • More awareness about performance