Improve Page Load Speed (by 80%) by Improving Component Load Speed

In my last post, I discussed why it's becoming increasingly important to ensure your website loads quickly for users (and Googlebots). At the end of the article, I mentioned a quote from Yahoo!'s article, Best Practices for Speeding Up Your Web Site:

80-90% of the end-user response time is spent downloading all the components in the page: images, stylesheets, scripts, Flash, etc. This is the Performance Golden Rule.

In other words, you can get the most "bang for your buck" when it comes to page load optimization by speeding up the loading of your site components (a.k.a. "assets", such as javascripts, CSS stylesheets, images, etc.). In this post, I'll discuss the 3 main techniques used to improve asset load speed.

Asset load optimization often results in a reduction in asset-load-time by 75-90%. Since asset-load-time accounts for 80-90% of your total page-load-time, this equates to an overall reduction in page-load-time by up to 80%!

Below are graphs showing the load time of RateMyStudentRental.com before and after (respectively) implementing the asset-optimization shown here. Using Google's Speed Tracer extension, we can see that total load time decreased from 40 milliseconds down to 15ms.

3 Techniques to Speed Up Asset Loading

So we know that when a user visits your site, their browser must download your javascripts and CSS stylesheets so that your site will display properly. Luckily this only happens once per session by default, because the user's browser will then cache those assets on the user's computer. This means that each subsequent page load, as the user navigates through your site, will simply reload the assets from the user's computer without needing to download them again. But this isn't good enough, we can make it faster.

Better Caching with Expires Header

Remember when I said the browser will cache assets once per session by default? That's not good enough for our purposes. We need to setup our server to explicitly tell users' browsers to cache assets until further notice.

This is difficult to do reliably across all browsers/environments, so the way we accomplish this is by actually telling users' browsers to cache everything for a year (or some other arbitrarily long duration). Then Rails's built-in asset helpers append timestamps to the asset URLs every time you update and deploy your assets. This fools users' browsers into thinking they're looking at a different asset (since the filename has a different timestamp), which makes the browsers re-download and cache the new files when you deploy updates.

We've now discussed telling users' browsers to keep cached versions of our assets for longer than one session. But we still need to speed up that first page visit, by speeding up the user's first download of our assets.

Zipping

Have you ever zipped a file before emailing it to someone in order to make the file-size smaller? Well, most modern browsers actually know how to read a zipped file directly without needing to unzip it. This means that instead of serving full javascript files or CSS stylesheets, you can serve zipped files (often 1/3 or less of the original file-size) and make the page load much faster, since smaller files take less time to download.

Even better is that servers, such as Apache, can check if the requesting browser accepts GZip encoding (the standard zipping algorithm), and automatically serve zipped files if accepted. All you have to do is enable it in your server.

Content Delivery Networks (CDNs)

So far, we've discussed making the files stay cached by users' browsers for longer than one session, and then speeding up the first download by zipping the assets, making their file-sizes smaller. There is still one more thing we can do to make the assets download faster, and that is use a Content Delivery Network, or CDN. A CDN is a group of servers physically scattered all around the world that host and serve copies of your assets for you.

Even though it may seem like data transmission is instantaneous, it still takes time for electrons to travel through wires (even optical networks "only" transmit data at the speed of light, which is not instantaneous). Thus, the shorter the distance we need to transmit data, the faster it will be transmitted. If your existing asset server (by default, the server from which your site is hosted) is located in the US, then your assets will download more quickly for me (located in the US) than it will for my buddy, Dave, in Portugal. The purpose of a CDN is to serve your assets on a per-user-basis from the server in the CDN that is physically closest to that user.

Don't believe me? Just check out the difference in ping time (the amount of time it takes for a computer to contact the server and for the server to respond) for my buddy, Dave, in Portugal pinging my server in the US compared to pinging a CDN server in Europe.

Putting This Knowledge To Use

What have we learned here? We've learned that we can reduce download time by reducing the size of the files being downloaded. GZip compression can reduce text-based files to 1/3rd their original size, which reduces download time by 67%. Then we can move assets to a CDN, which can reduce transmission time by another 67%. Doing the math, we see that component download time is reduced by 90%, which equates to an overall reduction in page load time of 80%.

Now that we've covered the importance of page load speed, and the 3 techniques used to speed up the loading of assets (or site components), we can figure out how best to combine this knowledge into the optimal configuration, and then finally, how to implement this into our own sites.

---