SXSWi: Even Faster Web Sites

Author: James Braithwaite

Focus on the frontend, increase percevied performance.

Script block page execution, they block document.ready event. Cuzillion is a tool to test execution flow. There’s a set limit of requests for each domain, ‘connection pool’ is the tech term, so use domain sharding. point to the same resource. Then you can queue up resources and they won’t block, because they served from different domains.

There’s a full breakdown of techniques in the slideshow but using JS to insert JS into the head won’t block, so you can use a main script to trigger loading other scripts. Useful but it gets tech if you need to load a library before another script, e.g. jQuery before jQuery UI. Suspect somebody needs to write a library to do this better. Pay attention to race conditions.

iframes the most expensive DOM element another excuse not use them. iframes also block document ready, which is hard when your serving 3rd party ads. A way around this is to wait for document ready then insert the iframes, they load after the important JS and don’t block your UI. Just bundle them in with (#foo).html = “adcode”

There were also some recommendations about using mod_delate although that spends CPU time, so if you’ve got heavy traffic it might not be applicable. Also Google do some clever stuff with flushing, where part of the page is sent to the browser even if the rest of the page is in flux. It’s interesting, but then they’ve got control of the whole stack. They could/do probably run a modded up apache which is speed focused.

“Google want the web to be instantaneous” interesting choice of words, not fast, or quick but immediate. It’s a utility.

More on Steve’s blog