This is Article #2 of a 4-part series. This article (along with Article #1) serves as a primer for the next two entries in this series, which discuss the most efficient way to put these concepts into practice in your web application. For more a more in-depth look at these concepts, see Yahoo!'s Best Practices for Speeding Up Your Web Site and Google's Speed Tracer tutorial
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.
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.
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.
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.
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.
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.
Stay tuned for Part 3: Optimal Configuration of Caching, Zipping, and (CloudFront) CDN for Fastest Component Loading.