Sowrey.org

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 IE
  • XHR 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