Steve Souders of Google is speaking on Even Faster Web Sites. I've read Steve's book and loved it. It's the kind of book you read in the morning, use to make changes to your site in the afternoon and at the end of the day, you've made a huge difference.

Usually, a small percentage of the time (10%) a browser spends putting a page in front of the user is spent downloading the HTML document. Making the Web server faster might save compute time or storage, but it doesn't do much for the user's perceived response time.

80-90% of the end user response time is spent on the front end of the page load experience, so start there. You'll have a greater potential for impact. The changes are simpler than backend tuning. And finally, they've been proven to work. I can personally vouch for that.

Steve created rules or high performance Web sites and built them into a Firefox extension called YSlow. Running in on www.windley.com, shows that I don't do so well. I get a grade of "F." I'll have to work on that!

Steve's writing a new book that focuses on some new rules. Javascript is the place to focus. Javascript requests can have a big impact. They block parallel downloads because once they start executing nothing else happens. Steve created Cuzillion to allow people to create test pages easily that show browser behavior for particular choice.

Steve shows a table that shows that Facebook, for example downloads 1Mb of javascript and only executes 9% of them. Of the top ten sites on Alexa, the average is 252Kb with 26% of the functions executed. S

The first new rule is to split the initial payload. Split JavaScript between what's needed to render the page and everything else. The is largely something you have to do manually. Finding all the possible code paths is hard.

The next rule: avoid script blocking. There are numerous techniques to avoid script blocking. Most of these require some refactoring of the JavaScript code because you're downloading and then using a technique to eval what got downloaded. On technique that doesn't is appending the script after the page has loaded. One big difference between these techniques is how they affect the busy indicators. Some people get nervous when the page is "still loading" even when it's rendered and downloading scripts. On the other hand, if the status bar says "done" and the page hasn't rendered completely people will reload unnecessarily.

Long inline scripts block rendering and download. You can initiate execution with a setTimeout, move it to an external script, or use the defer attribute (IE only). Don't scatter them in the page and don't put it between the stylesheet and any other resource.