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
- 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
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
This talk by Sean and Alistair is one of the talks I couldnâ€™t attend today due to conflicts, but Iâ€™m glad the slides are already up.
Performance measurement is often the starting point for most web applications and that canâ€™t be done without understanding what goes on between the browser and the server.
Jonathan Ellisâ€™ started up a storm when he posted an entry about CouchDB about 6 months ago. He questioned some of CouchDBâ€™s claims and made an attempt to warn users who donâ€™t understand practical issues around CoughDB very well.
After reading his post and some comments, it looked like he was specifically concerned about CouchDBâ€™s ability to distribute/scale a growing database automatically.
Its a good read if you are curious. He has stopped accepting comments on his blog, but that shouldnâ€™t stop you from commenting here.
As Jan pointed out in the comments Jonathan is assuming â€œdistributedâ€ means â€œauto-scalingâ€ which is not true.
— links from the blog.. Cassandra dynomite Sawzall Pig