Matt RaibleMatt Raible is a Web Architecture Consultant specializing in open source frameworks.


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

[OSCON 2008] Even Faster Web Sites by Steve Souders

Steve works at Google on web performance and open source initiatives. To begin his talk, Steve is running YSlow in "autorun" mode. This runs YSlow Performance tests on the top 100 sites according to Alexa. Before Google, Steve was at Yahoo for 7 years. You can download Steve's slides from his site (don't ask me where).

iGoogle with an empty cache: 9% of the time is spent getting the HTML document. The % of time of what a webserver does is a pretty small percentage of the overall picture. If the cache is primed, the time goes up to 17% of the time.

80-90% of the end-user response time is spent on the frontend. Start there.

There's a greater potential of improvement on the frontend. If you improve the backend performance by 50%, chances are the end-user only sees a 5% improvement.

The 14 Rules are encapsulated in the YSlow plugin. At OSCON last year, Yahoo released YSlow. 500,000 downloads since it was released. Following the release of YSlow, Steve wrote High Performance Web Sites.

High Performance Web Sites, Vol 2. The 3 most important rules are:

  • Split the initial payload
  • Load scripts without blocking
  • Don't scatter inline scripts

Why focus on JavaScript? A lot of the top sites use JavaScript. For example, up until a few weeks ago, Facebook served up 1MB of JavaScript, uncompressed. Scripts block parallel downloads and page rendering. To see it in action, go to

Any content below a <script> is blocked from rendering - even if it's already cached in the browser. Cuzillion is an open source project that Steve is releasing that allows you to add components to a page and test their performance.

Split your JavaScript between what's needed to render the page and everything else. Load "everything else" after the page is rendered. To do this, you can use Firebug to do it manually, or you can use Doloto from Microsoft to automate the splitting of your files. solves the script blocking problem by using JS DOM to allow for parallel downloading. There's 6 techniques for doing this:

  • XHR Eval (must have same domain as page)
  • XHR Injection (same domain)
  • Script in iFrame (same domain)
  • Script DOM Element (domains can differ)
  • Script Defer (only supported in IE, domains can differ)
  • document.write (not recommended, parallelization only works in IE)

How do these techniques cause "browser busy" indicators? XHR Eval and Injection don't trigger any indicators. You need to choose when you want to show busy indicators. It's good to show them when you want to show your users that something is processing (but not for lazy-loading JavaScript that's not required for load). For the different techniques, most don't ensure order of parsing.

Based on 3 factors, Steve can tell you which technique is best to use. These three factors are 1) the URL of the page and script 2) if you want busy indicators and 3) if you care about order. Steve thinks it would be awesome if web frameworks could support this to write out JavaScript appropriately for the developer's input.

Long executing inline scripts block rendering and downloads. If you know you're going to have scripts like this, you can solve it with a couple workarounds:

  • Initiate execution with setTimeout(>250 for Firefox)
  • Move JavaScript to enternal script with advanced downloading techniques
  • Use defer attribute for IE

In Firefox 2, stylesheets block parallel downloads just like scripts. IE doesn't. However, IE will block when you have a stylesheet followed by an inline script. To solve, it's best to move line scripts above stylesheets or below other resources. use <link>, not @import.

Takeaways: focus on the frontend, run YSlow, focus on JavaScript (split initial payload, load scripts w/o blocking, don't scatter inline scripts).

Three Announcements:

Posted in The Web at Jul 24 2008, 04:23:12 PM MDT 8 Comments

Here are some older version of the slides on Steve's site

Posted by Daniel Sterling on July 24, 2008 at 11:11 PM MDT #

"Steve works at Google on..... Before Google, Steve was at Google for 7 years" - presumably that should be Yahoo

Posted by Niall on July 25, 2008 at 04:16 AM MDT #

@Niall - thanks for pointing that out. Fixed now.

Posted by Matt Raible on July 25, 2008 at 08:50 AM MDT #

I've been using more and more JavaScript in my web UIs over the years and I so need to start paying attention to this stuff. Thanks for this great summary. Thanks to Steve, too, of course.

Posted by David on July 26, 2008 at 06:39 AM MDT #

Consider using HttpFox instead of HTTPWatch. HttpFox is free and does everything HttpWatch does... I've been very impressed so far.

Posted by Lincoln on July 26, 2008 at 10:26 PM MDT #

Great article Matt! Do you know by any chance if Doloto is available for download anywhere?

Posted by Kai Grabfelder on July 29, 2008 at 05:18 AM MDT #

I'm actually just trying to build one of those "busy" indicators for a site using AJAX right now... don't suppose there were any good suggestions of how to do that?

Posted by Robert Watkins on August 01, 2008 at 05:34 AM MDT #

Also important to consider that the 'script DOM element' technique will use the browser's cache whereas XHR techniques will always fetch the resource from the remote server.

Posted by David on August 17, 2008 at 09:09 AM MDT #

Post a Comment:
  • HTML Syntax: Allowed