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.
stylesheet stylesheet stylesheet stylesheet image image image image
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 some of the JavaScript that is downloaded is not used immediately, but instead is there to provide functionality that the user might need in the future. The problem is that this subset of JavaScript blocks other content 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 their JavaScript payload into two scripts: 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-
<script type=”text/javascript”> tant, where to focus your performance 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’)[0].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
feature rich.
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.
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/ javascript”></script>
But there are several techniques for downloading scripts that avoid this blocking behavior:
˲ XHR eval
˲ XHR injection
These first two best practices about JavaScript performance have to do 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 parallel?c
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-
References
1. Penick, h. Harvey Penick’s Little Red Book: Lessons and Teachings From A Lifetime In Golf. simon and schuster, 1992.
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.
References:
Archives