Web 2.0 Notes: Optimizing the Frontend

This was the one-year follow-up after Steve Souders did his first presentation (at last year’s Web 2.0) on optimizing the performance of frontends. He’s done some amazing work collecting best practices, including a whole decision tree on the best methods to inject script into a page, based on browsers, the need to access scripts cross-domain, etc.

As far as immediate applicability to my work at Instructables, this was by far the most interesting talk of the conference for me. Rough notes after the jump.

Even Faster Web Sites
Focus on Web Operations, room 2002, Friday 1:30 PM
Steve Souders (Google)

Here’s a link to the slides. As a preview, below is the money shot: a full decision tree for how and when to use any one of six different methods for dynamic script inclusion:

In addition, I had a very interesting conversation with badass engineer/analyst Artur Bergman who has suggested some ninja moves to get us past the the external script loading problems that we’re having at Instructables. I’d previously been stumped, so this may be something of a coup.


As of a couple years ago, Souders’ career had been all about the backend architecture of huge web properties (Yahoo for eight years, now Google.) When he stepped back from all the DB and caching optimization he was doing, however, he realized that 90% of the user’s wait time was occurring on the front end, which he calls “The Performance Golden Rule.” This was true even with primed caches, and across the vast majority of top web sites (certainly of the top ten, excepting Craigslist, Google, and MS LiveSearch.) For the last few years, therefore, he’s focused on optimizing the speed of the frontend. His “14 Rules” presentation at Web 2.0, last year, was the public debut of this idea.

Since then, he’s:

  • Released YSlow. Some criticism for the “negative” aspect of the rankings that it puts out. [Good point: it’s probably more motivating to think of performance issues as places where there’s still fat to be turned into page views.]
  • Published “High Performance Web Sites” by O’Reilly
  • Set up the Velocity conference for this summer (June 23-24), a conference on web site performance and availability optimization.

New Ten Rules: Even Faster Web Sites

The first three: Javascript

Why focus on Javascript? This is the main offender for performance hits. This is clear from the Page Detailer screenshots that most web sites have 20%-40% of script download and interpretation time. This is because Javascript blocks parallel downloads and rendering. The browser doesn’t know if script will modify the DOM, so it has to wait while interpreting before doing anything else.

  1. Split the initial payload: In facebook, only 9% of the 550k of script that was used was needed before onload. The advice here is to separate your code out into what’s needed during rendering and what’s need afterwards. This can be done manually using Firebug, but there is also a Microsoft product called Doloto which does this automatically.
  2. Load scripts without blocking:
    • Here are the six:
      1. Do DOM-based script element injection into the HEAD [like JSLoad does. no document.write can be used, though; addressed in my question, at bottom]
      2. XHR Eval: eval AJAX response text. Domain must be the same, however.
      3. XHR Injection: set innerHTML to AJAX repsonse text. Domain must be the same, however.
      4. Script in iframe. In addition to domain constraint, vars much go up to window object to be accessed
      5. Script DOM element
      6. Script Defer. Only supported in IE, but just tells IE it’s safe to keep rendering/working. Must be in same block?
      7. document.write a script tag. Not recommended.
    • Some of these will trip the busy indicator, some won’t (see preso.) Note that this feedback is sometimes desirable.
    • When you need to ensure that scripts execute in order: (see preso)
    • When you don’t have dependencies (e.g. external badges, ads, and APIs): (see preso)
    • The winner is:(decision tree, in preso)
      • This would be useful as a client-side implementation (JSLoad!); he hasn’t made one yet.
      • Also very useful as a server-side implementation, to reduce code going over the wire.
    • Inline Scripts Block Rendering. Long executing inline scripts block rendering of the entire page. Move this code to external scripts as specified above, or use a timeout to initiate execution for later (300-400ms, maybe.)
  3. Don’t scatter scripts: For example, inline scripts after stylesheets block downloading. These tiny scripts kill parallelism of following HTTP requests.

The notes here are really just a preview. The gold is in the slides.

Some Tools:

  • IBM Page Detailer: tool of choice for packet sniffing.
  • http://cuzillion.com (by Souders) can help us check many many variant tests quickly.

Here’s the key question I asked, relevant to Instructables: What to do about the fact that document.write doesn’t work with head tag injection? Steve pointed me to Artur Bergman’s, who’ss doing some crazy overloading of document.write. Artur and I talked, briefly, afterwards, and he showed me what he was doing with Wikia (e.g. http://nwn.wikia.com). Very, very useful. This may get folded into JSLoad

Related Posts:

One Response to “Web 2.0 Notes: Optimizing the Frontend”

  1. John Adams Says:

    Hey eric – I think I met you at web2.0. I gave the talk on the Snarkatron and we’d discussed writing up the Snarkatron for instructables and bringing it to maker faire.

    Drop me an email if it’s you. Thanks.