This excerpt is from Even Faster Web Sites .
This raises several questions:
How much does this save?
How do you find where to split the code?
What about race conditions?
How do you download “everything else” later?
The first three questions are tackled in this chapter. How to load “everything else” is the topic of Chapter 4, Loading Scripts Without Blocking.
It turns out that Facebook executes only 9% of the downloaded
onload event is called. This is computed by
executed up to the
event. The counting stops at the
onload event because
functionality needed after this point can, and should, be downloaded after
the initial page has rendered. I call this a post-onload
download. (See Chapter 4, Loading Scripts Without Blocking for various lazy-loading
the percentage of functions downloaded that are not executed before the
onload event for 10 top U.S. web sites.
On average, 75% of the functions downloaded are not executed during the
initial rendering of the page. Thus, if downloading of these unexecuted
be dramatically reduced.
Admittedly, the 75% estimate might be exaggerated; some of the
unexecuted functions might be required for error handling or other special
conditions. The estimate is still useful to illustrate the point that much
terms of function count, not size. If we assume a constant function size,
75% represents an average 189 KB that doesn’t have to be downloaded until
onload event, making the
initial page render more quickly.
% of functions not executed
that were executed by the time of the
onload event. This list can be used to manually
rendering and another file to be downloaded later. However, because some
of the unused functions may still be necessary for error-handling and
other conditional code paths, splitting the code into an initial download
higher-order features, including function scoping and
eval, make the challenge even more
Doloto’s decisions about where to split the code are based on a
downloads. For many web applications, it is preferable to define a single
split at the
onload event, after
nonblocking techniques described in Chapter 4, Loading Scripts Without Blocking. Waiting to start the
additional downloads on demand after the user has pulled down a menu or
clicked on a page element forces the user to wait for the additional
other systems are publicly available, developers need to split their code
manually. The following section discusses some of the issues to keep in
mind when doing this.
In a situation where the delayed code is associated with a UI element, the problem can be avoided by changing the element’s appearance. In this case, the menu could contain a “Loading…” spinner, alerting the user that the functionality is not yet available.
Another option is to attach handlers to UI elements in the
lazy-loaded code. In this example, the menu would be rendered initially as
lazy-loaded code would both contain the menu functionality and would
attach that behavior to the menu using
attachEvent in Internet Explorer and
addEventListener in all other browsers.
A good example of splitting the initial payload is Google Calendar. Figure 3.2, “Google Calendar HTTP waterfall chart” shows the HTTP requests that are made when Google Calendar is requested. I call these charts HTTP waterfall charts. Each horizontal bar represents one request. The resource type is shown on the left. The horizontal axis represents time, so the placement of the bars shows at what point during page load each resource was requested and received.
 Fourteen scripts are downloaded when logged-in users visit this page. If the user is not logged in, fewer scripts are used.
 Firebug is the preeminent web development tool, available at http://getfirebug.com/.
 See http://www.quirksmode.org/js/events_advanced.html for more information.
 Firefox 2 is the one exception.
If you enjoyed this excerpt, buy a copy of Even Faster Web Sites .
Copyright © 2009 O'Reilly Media, Inc.