practice
Doi: 10.1145/1409360.1409374
Want to make your Web site fly?
Focus on frontend performance.
By steve souDeRs
high-
Performance
consumption. But how much does the
backend affect the user experience in
terms of latency?
The Web applications listed here are
some of the most highly tuned in the
world, and yet they still take longer to
load than we’d like. It almost seems as
if the high-speed storage and optimized
application code on the backend have
little impact on the end user’s response
time. Therefore, to account for these
slowly loading pages we must focus on
something other than the backend: we
must focus on the frontend.
Web sites
Google Maps, Yahoo! Mail, Facebook, Myspace,
Youtube, and amazon are examples of Web sites
built to scale. they access petabytes of data sending
terabits per second to millions of users worldwide.
the magnitude is awe-inspiring.
users view these large-scale Web sites from a
narrower perspective. the typical user has megabytes
of data that they download at a few hundred kilobits
per second. users are less interested in the massive
number of requests per second being served, caring
more about their individual requests. as they use
these Web applications they inevitably ask the same
question: “Why is this site so slow?”
the answer hinges on where development teams
focus their performance improvements. Performance
for the sake of scalability is rightly focused on the
backend. database tuning, replicating architectures,
customized data caching, and so on, allow Web
servers to handle a greater number of requests.
this gain in efficiency translates into reductions in
hardware costs, data center rack space, and power
the importance of
frontend Performance
Figure 1 illustrates the HTTP traffic sent
when your browser visits iGoogle with
an empty cache. Each HTTP request is
represented by a horizontal bar whose
position and size are based on when
the request began and how long it took.
The first HTTP request is for the HTML
document ( http://www.google.com/ig).
As noted in Figure 1, the request for the
HTML document took only 9% of the
overall page load time. This includes
the time for the request to be sent from
the browser to the server, for the server
to gather all the necessary information
on the backend and stitch that together
as HTML, and for that HTML to be sent
back to the browser.
The other 91% percent is spent on
the frontend, which includes everything
that the HTML document commands
the browser to do. A large part of this is
fetching resources. For this iGoogle page
there are 22 additional HTTP requests:
two scripts, one stylesheet, one iframe,
and 18 images. Gaps in the HTTP profile (places with no network traffic) are
where the browser is parsing CSS, and
parsing and executing JavaScript.
The primed cache situation for
iGoogle is shown in Figure 2. Here
there are only two HTTP requests: one
for the HTML document and one for a
dynamic script. The gap is even larger
because it includes the time to read the
cached resources from disk. Even in
the primed cache situation, the HTML
document accounts for only 17% of the
