figure 4. stylesheet followed
by inline script in www.msn.com/.
ing. This seems like it would be a rare
problem, but it afflicts four of the top
ten sites in the U.S: eBay, MSN, MySpace, and Wikipedia.
page load. Instead of loading more
pages for each action or piece of information requested by the user, as was
done in Web 1.0, Web 2.0 apps use
Ajax to make HTTP requests behind
the scenes and update the user interface appropriately. This means that
instead is there to provide functionality that the user might need in the
that is used immediately, delaying immediate content for the sake of future
functionality that may never be used.
Table 2 shows that for the top 10 U.S.
Web sites, an average of 74% of the functionality downloaded is not used immediately. To take advantage of this opportunity, Web developers should split
the code that’s used immediately (~26%)
and the code for additional functionality (~74%). The first script should be
downloaded just as it is today, but given
its reduced size the initial page will load
more quickly. The second script should
be lazy-loaded, which means that after
the initial page is completely rendered
this second script is downloaded dynamically, using one of the techniques
listed in the next section.
˲ script in iframe
˲ script DOM element
˲ script defer
˲ document.write script tag
You can see these techniques illustrated in Cuzillion (http://stevesoud- Life’s too short, Write fast code
ers.com/cuzillion/), but as an example At this point, I hope you’re hooked on
let’s look at the script DOM element ap- building high-performance Web sites.
proach: I’ve explained why fast sites are impor-
var se = document.createElement efforts, specific best practices to follow
(‘script’); for making your site faster, and a tool
se.src = ‘http://anydomain. you can use to find out what to fix. But
com/foo.js’; what happens tomorrow, when you’re
document.getElementsBy TagName back at work facing a long task list and
(‘head’).appendChild(se); being pushed to add more features in-
</script> stead of improving performance? It’s
A new DOM element is created that important to take a step back and see
is a script. The src attribute is set to the how performance fits into the bigger
URL of the script. Appending it to the picture.
head of the document causes the script Speed is a factor that can be used
to be downloaded, parsed, and execut- for competitive advantage. Better fea-
ed. When scripts are loaded this way, tures and a more appealing user inter-
they don’t block the downloading and face are also distinguishing factors. It
rendering of other content in the page. doesn’t have to be one or the other. The
point of sharing these performance
best practices is so we can all build
Web sites to be as fast as they possibly
can—whether they’re barebones or
I tell developers “Life’s too short,
write fast code!” This can be interpret-
ed two ways. Writing code that executes
quickly saves time for our users. For
large-scale Web sites, the savings add
up to lifetimes of user activity. The oth-
er interpretation appeals to the sense
of pride we have in our work. Fast code
is a badge of honor for developers.
Performance must be a consideration intrinsic to Web development. The
performance best practices described
here are proven to work. If you want to
make your Web site faster, focus on the
frontend, run YSlow, and apply these
rules. Who knows, fast might become
your site’s most popular feature.
Load scripts without Blocking
As described in “Rule 6: Put Scripts at
the Bottom,” external scripts block the
download and rendering of other content in the page. This is true when the
script is loaded in the typical way:
<script src=”foo.js” type=”text/
But there are several techniques for
downloading scripts that avoid this
˲ XHR eval
˲ XHR injection
Don’t scatter inline scripts
These first two best practices about
with external scripts. Inline scripts also
impact performance, occasionally in
significant and unexpected ways. The
most important guideline with regard
to inline scripts is to avoid a stylesheet
followed by an inline script.
Figure 4 shows some of the HTTP
traffic for http://www.msn.com/. We see
that four stylesheet requests are downloaded in parallel, then there is a white
gap, after which four images are downloaded, also in parallel with each other.
But why aren’t all eight downloaded in
This page contains an inline script
after the fourth stylesheet. Moving
this inline script to either above the
stylesheets or after the images would
result in all eight requests taking place
in parallel, cutting the overall download time in half. Instead, the images
are blocked from downloading until
the inline script is executed, and the
inline script is blocked from executing
until the stylesheets finish download-
1. Penick, h. Harvey Penick’s Little Red Book: Lessons
and Teachings From A Lifetime In Golf. simon and
2. souders, s. High Performance Web Sites: Essential
Knowledge for Front-End Engineers. o’reilly, 2006.
c Note that these requests are made on different
hostnames and thus are not constrained by
the two-connections-per-server restriction of
some browsers, as described in "Rule 1: Make
Fewer HT TP Requests."
Steve Souders ( http://stevesouders.com) works at google
on Web performance and open source initiatives. he is the
author of High Performance Web Sites and the creator of
yslow, cuzillion, and hammerhead. he teaches at stanford
and is the co-founder of the firebug Working group.