Quote:
Originally Posted by Ace of Babes
If you're a frequent visitor to code.google.com for product updates and reference materials for Google APIs you're working with, you might have noticed that the page loading time (or page rendering time depending on how you see it) has reduced in varying degrees in the past several weeks.
As you'll see below, we've made several changes to help reduce user-perceived latency. This is not an exhaustive list of all improvements we've made recently, but these are the major ones we've made.
As Steve Souders emphasizes as the "Performance Golden Rule" in his book High Performance Web Sites, "only 10-20% of the end user response time is spent downloading the HTML document. The other 80-90% is spent downloading all the components in the page (p.5)".
We agree. That's why we focused our effort on reducing the number and size of downloads (HTTP requests) for the "components" throughout Google Code.
Combined and minimized JavaScript and CSS files used throughout the site
Downloading JavaScript and CSS files blocks rendering of the rest of the page. Thus, to reduce the number of HTTP requests made on the initial page load, we combined frequently-used JavaScript and CSS files into one file each. This technique has brought down 20 HTTP requests down to just 2. We also minimized the files by stripping out unnecessary whitespace and shortening function/variable names whenever possible.
Implemented CSS sprites for frequently-used images
There are 7 images prominently used throughout Google Code, including the Google Code logo, the googley balls at the bottom of every page, the plus and minus signs as well as the subscribe icon inside each blog gadget.
Although browsers usually download several images in parallel, we concatenated these images into one image so only one HTTP request would be made. Of course, concatenating several images into one required us to make several changes in HTML/CSS. For example, instead of having:
Code:
<img src="/images/plus.gif" />
We had to change it to:
Code:
<div style="background-image:url(/images/sprites.gif); background-position:-28px -246px; width:9px; height:9px">&</div></span>
where sprites.gif is the concatenated image and background-position and width/height carefully calculated. |
Firstly, I wouldn't advocate that approach because of the problem of interoperability between different browsers of displaying elements in a relative way - from previous experience, having to work around IE's stupid box model was hellish enough, so why would I want to, as a designer, introduce more pain for myself?
As well as that, surely this concatenated image is simply going to be the size of all the sprites added together - but what if everyone only wants to use one sprite at, say, 130 bytes per sprite? For instance, your site has a total of 100 x 130 byte sprites for the user to choose from, making this concatenated image around 13 KB. Now, say 100 people load a thread page with 5 posts in, with each post having just 1 sprite - so each pageload, in sprite terms, causes 5 x 13 bytes = 65 bytes per user of bandwidth, which with 100 people's pageloads, causes around 6.34 KB of sprite bandwidth in total - verses one pageload from one user with the concatenated sprite causing over double that amount of 13 KB; 100 users pageloads with the concatenated sprite image would cause bandwidth to rocket to 100 x 13 = 1.26 MB.
As the above was just a small example, I'm sure it's easy enough to see how this idea scales poorly when more than 100 pageloads are concerned. Not to mention, of course, you said that most browsers don't cache properly; so why would they magically not cache the 130 byte sprite, but suddenly decide to cache the 13 KB concatenated sprite? They wouldn't - so each consequent pageload by the same user would require yet another request for a 13 KB image, which is going to be slower than a few requests for a 130 byte image.
And now to wait to be proven wrong - as always in life.