Doi: 10.1145/1409360.1409374
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
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
References:
Archives