Hanging out with Schill today, and he’s giving me some really great suggestions on what to see. Although the CM team did suggest something different, he’s saying we should see this one. Naturally, Schill knows the guy, but from his POV, this is a cannot-miss session.
Presenter: Steve Souders, Google
Used to be Chief of Performance at Yahoo, doing the same thing at Google now
Backend performance fairly trivial to handle
Backend time produces up to HTML; frontend is parsing HTML and loading other assets
80-90% of end-user response time spend on frontend; start there to optimise
Need to try follow the 14 rules (similar to the notes that appear in YSlow!)
Why focus on JavaScript? - Has a painful impact on loading pages
Scripts block parallel downloads and execution
Cuzillion is an automated script performance testing app
Split the load - Only 9% of JS is needed on a Facebook page, but have to wait for 550k to load before any of it is used
Split into at least two parts: What’s needed to render the page, and everything else
Separate manually (Firebug can help); Doloto from Microsoft can help automate this
Parallel scripts - Write out the DOM elements to load the JS using JS (obj.createElement(“script”)), which allows parallel execution
Set up XHR eval to execute without blocking (some refactoring needed)
XHR injection, which allows XHR to attach the code (no refactoring needed)
Can insert code into iFrames as they run as parallel (note: must be on the same domain; some refactoring might be necessary for object reference)
<script defer src=””>works only in IEXHR techniques don’t trigger the browser busy indicators (e.g. spinning logo, mouse cursor); script in iFrame
Long executing inline scripts block rendering of the entire page - workarounds: execute using setTimeout
move inline to external (see above)
Firefox blocks parallel downloads when downloading stylesheets - load inline scripts before stylesheets
