Cody Lindley | June 11, 2010
The issue at hand today is simply this: what are the weightiest optimizations that can be implemented when constructing web pages? This area of web development is best categorized as load-time optimizations. This article is going to examine the most critical load-time optimizations for crafting a speedy web page.
In another article I will be covering run-time optimizations. Run-time optimizations focus on the performance of a web page once it has already been downloaded by the client (e.g. a web browser). Specifically, it is concerned more with the interaction and experience the user engages in once the web page is already down loaded. In this article, however, we will concern ourselves with load-time optimizations. Load-time optimizations are specifically geared at shaving off the time required to load a web page and all subsequent page loads.
Before looking at some load-time optimizations I would like to make a recommendation. Use a measuring stick to test load times! I know that it might seem silly to point out such an obvious recommendation, but measuring is extremely important. In my experience, far too many developers forgo measuring page performance. So, very simply put, make measuring web page performance a part of your daily routine as a web developer.
My measure stick of choice is found at http://www.webpagetest.org. As a quick preview of this tool have a look at a "Web Page Test" done on the homepage of this site.
The "Web Page Test" is used to measure the loading time of a web page. Above and beyond just measuring load times, it can be used to diagnose why a web page might be running slowly. In a nutshell, it will provide the details required to understand the most costly parts of your HTML page architecture as it pertains to file sizes, http requests, and document rendering.
Specifically, the “Web Page Test” online tool takes a detailed look at the HTTP activity that occurs during the loading of a web page. It then takes this activity and provides several charts, graphs, visuals, and reports for understanding what is occurring during each http request. In addition, it also provides insight into how HTTP requests effect, as a whole, each other and how this pertains to the bottom line, which is total load time.
Honestly, grokking this tool is as simple as just visiting the site and using it. If you are reading this article and seeking performance based answers then the functionality and information provided by this tool will make perfect sense once you just start using it. I encourage you to open a browser window now and use the “Web Page Test” tool to test a web page. If you require a bit of a primer on how to leverage this tool you might checkout the screencast from Dave Artz. Dave is the Director of Website Optimization at AOL. So, he might a know a thing to two that could be helpful.
Now, just because this is my favorite measuring stick does not mean that it will be yours. There are several tools available that provide very similar, if not identical metrics.
Below is a list of some well known alternative tools for measuring web page loading times. I find myself leveraging many of these tools in combination with the aforementioned “Web Page Test” tool from AOL.
Now that we have a measuring stick and we can test optimizations and locate optimization opportunities, let's move on to looking at some actual page optimizations.
I like to keep things simple and digestible. So, we are only going to focus on five optimization categories in a sea of optimizations. These categories are: Reducing HTTP requestsReducing file sizeOrdering includes for speedDistributing the loadChecking Sever Response Times
This optimization simply comes down to reducing the number of files that a web page requires. By reducing dependencies for images, stylesheets, and scripts we can avoid the bottleneck that can occur due to the browser getting tied up in downloading (HTTP requests) assets.
When building web pages we should strive to reduce dependencies and thus HTTP requests. This can be done by:
This will come as no surprise, I hope. Small files are loaded and parsed faster than bigger files. Knowing this we should always be striving to shrink file sizes (images, css, js, html) down to the minimal acceptable size given our desired outcome. Below we examine five ways in which we can cut down file size.
Believe it or not, the order in which dependencies are included in a web page can directly effect how long it takes for a browser to render and completely load a web page. This is due to the way in which browsers manage HTTP request. And, specifically, how a browser HTTP request handles the various types (.css vs. .js) of dependencies. Below, I detail two techniques of including dependencies that can improve page load time.
Distributing the load can be a very complex topic. In general, a web browser will only open so many connections with one host name. However, if we distribute our dependencies to 3 or 4 host names, the browser can open up simultaneous connections pulling dependencies from different servers at the same time. Of course, there are limits. Have a look at browserscope for a good over view of which browsers support what. To distribute the load and get simultaneous connections working in our favor we can leverage the following solutions.
Not everything comes down to how fast a client (e.g web browser) can load and parse an HTML page. The server plays a role as well. Before you optimize for a client, it might make sense to verify there are no bottle necks on the server-side. These issues can span the gamut from complicated SQL queries, poor database models, overloaded servers, and poor application architecture, to name just a few.
In general, if a web page is loading slowly make sure to verify the slowness is not coming from the server. I have been in a situation where no matter what optimizations were applied the server simply was not responding in an acceptable time. This was due to issues on the server. Our optimizations on the client-side helped loading times to a degree, but when the server was taking 7 to 8 seconds to respond to an HTTP request, our client-side optimizations did little to improve loading times. A lot of time on that project was wasted optimizing the wrong problem. After that project, when faced with performance loading issues I will always first check to see how fast the server is actually responding to HTTP requests.
Web page performance has become a rather large and complex field of study. This article has only scratched the surface of this field of knowledge. In reality, being an optimization engineer is a job role in and of itself. In fact, companies these days are hiring optimization engineers, as well as creating entire departments based simply on the practice of optimizing code for delivery on computers and mobile devices.
If you want to dig deeper than what was discussed here and continue your understanding of load-time optimizations I highly recommend investigating the following resources:
If he is not wielding client-side code he is likely toying with interface/interaction design, PHP, MVC frameworks, iPhone development, jQuery, Dojo, or authoring material and speaking at various conferences. When not sitting in front of a computer, it's a sure bet he is hanging out with his wife & kids in Boise, Idaho, training for triathlons, skiing, mountain biking, road biking, alpine climbing, reading, watching movies, or debating the rational evidence for a Christian worldview. Currently he is working as a contractor/freelancer.
More MSDN Magazine Blog entries >
Browse All MSDN Magazines
Subscribe to MSDN Flash newsletter
Receive the MSDN Flash e-mail newsletter every other week, with news and information personalized to your interests and areas of focus.