Web Performance Calendar

The speed geek's favorite time of year
2011 Edition

Tom (@sh1mmer) is the principal consultant at Jetpacks for Dinosaurs, who help make web sites really rather fast. He is currently working with Walmart Labs on their Mobile products. Tom co-authored Up and Running with Node.js and lives in San Francisco, CA.

There is a famous saying in English, “Measure twice, cut once” which is especially important if you do anything with your hands. Once you’ve cut a piece of wood with a saw and you find you are 5mm too short it’s pretty hard to fix it. While software is hard to waste in the same way you can waste a raw material like wood, you can certainly waste your time.

A resource like the performance calendar is a really great tool for finding ideas to apply to your own work. Many of the authors of this site are lucky in that they spend a significant amount of their time optimizing large sites for companies like Facebook, Yahoo! and Google (and yours truly, Walmart). However many developers have lots of other responsibilities other than performance.

When you have lots of things on your plate measuring more than pays its way. While it is easy to grab a technique that someone has laid out for you and apply it (and you should) you should make sure you target the issues that affect your site the most. I was at a conference a few years ago about JavaScript and an extremely prominent, talented and altogether smart JavaScript expert gave a talk about performance optimization. He gave a number of in-depth tips including unrolling loops and other micro-optimizations.

Here is the thing; When you are the author of a framework used by many thousands of sites every hour you spend optimizing the code pays off on every one of those sites. If you make helper functions used over and over your work repays itself many fold through each small usage. However, when you only care about the one site you maintain unrolling loops probably won’t make a significant or obvious a difference to your users. Optimization is all about picking the correct targets.

This is where we come back to measuring again. When you don’t have a clear understanding of where your bottlenecks are you need to measure before you cut. Measuring performance can be done in many ways and this is also important to consider. Unrolling loops in JavaScript is a very atomic micro optimization. It improves one specific function. However unrolling a loop that loops only twice and is only used by 1% of users is clearly not an important use of time.

The key to measurement is instrumentation. Start at a macro level. What are the most important parts of your site? This might be the ones used the most, or the ones which have the most impact on your business (such as the checkout process). You might find yourself surprised, perhaps you receive a lot of search engine traffic to a page deep in your site that is poorly optimized. Improving that page by 50% might make a much bigger impact than spending the same time getting another 1% improvement on your already optimized homepage. The only way to really know which pages on your site are important are to look at the stats or to discuss priorities with whoever is in charge of the site.

Once you know what’s important, the next task is to figure out what users do with those pages, or again what you want them to do. It’s important to note in this process that what customers do now may be an attribute of the current site and not actually what you want them to do. Identify which parts of your site are used the most by finding the most common tasks on the page. Which page level items (menus, search results) do users interact with most?

So here is our formula for optimizing:

  • Step 1. Use instrumentation to pick which pages/sections to optimize
  • Step 2. Use instrumentation to pick which features to optimize
  • Step 3. Optimize

Measure twice, cut once.

Identifying Pages/Sections

How do you go about picking which pages or sections of your site to optimize? This probably one of the easiest tasks because most conventional metrics give you everything you need to know. Start by seeing which pages get the most views. This will give you a short list of obvious targets. Your homepage is almost certainly one them, and then other popular pages on your site. These should be your shortlist.

The next thing to do is talk to your business owner. That might be your project manager, CEO, whoever. The most popular pages are not always the most important to the business. Checkout and shopping cart are very obvious examples here. If you run an e-commerce site many many people will browse many items, but only a small percentage of people will check-out. This doesn’t mean check-out isn’t important. On the contrary. Checkout is really important, it’s just something that metrics many not help you prioritize.

Now you should have a list of the pages or sections of your site which are a mix of the most popular or important ones to the business. This is your hit list. Keep it up to date periodically. Until you’ve exhausted your hit list don’t bother with other performance issues.

Identifying Features

On modern web sites many pages share the same code on many pages. Look at the code to find these features or use a packet sniffer like Wireshark, Charles Proxy or the Chrome Inspector or the Chrome Inspector on your hit list pages will help you get a list of the remote resources that were accessed. You can also examine your HTTP logs to look at what secondary web service resources are being requested for those popular pages. Those resources could also be a blocking factor in page rendering.

You should also try to identify what your users are doing on each page. This can be difficult. Unless you have a very rich metrics system you probably don’t know where the users’ cursors are, or how much they scroll. What you can probably do, however is look at what where they commonly click to from your hist list pages. This will give you an idea of what is being used the most. For example, on an product description page it might be the “add to cart” button. You should also look at timing, things like navigation menu items are going to get clicked a lot sooner after rendering than an “add to cart” button in general. This is because when people buy things they normally read the product description first. When they are navigating they aren’t reading page content, yet. You can instrument your pages with JavaScript or you can compute the time between page loads per user if you want to be a clever-clogs.

In general the goal is to figure out which things the user will need most readily. As an informal rule of thumb consider prioritizing items to load in this order:

  • Items above the fold
  • Navigation item (Menus, search bar)
  • Items that provide information (Product description, News stories)
  • Items to take an action (Add to cart, etc)
  • Items below the fold

You can check how fast various things load on your site using WebpageTest‘s film strip feature.


The final step is of course optimizing. Remember even within optimizing a feature don’t spend all your time optimizing something that is already optimized when there is something used 90% as much that isn’t. That’s the point of metrics to make good decisions. This goes both for your list of pages and features, and within the code. The goal of optimizing should be to take your measurements and then make the best use of your time to affect the users’ experience. Check out page render and JavaScript profilers and techniques.

There are lots of resources out there, once you know what you need to optimize go and find something to solve your problem, and then measure, measure again.