How To Speed Up Your Web Application from RevaHealth.com on Vimeo.

Web page render time is a critically important metric for any web app. It directly affects a site’s bounce rate because visitors can lose patience and hit the back button. It also affects a site’s conversion rate as visitors who do start browsing can get frustrated and give up. Page render time is a metric that anyone who is developing a web application needs to monitor closely and constantly.

At RevaHealth.com we have always made an effort to keep our page render times fast. We look at our initial page render times and page weight with each build and we try and make effective use of Ajax to speed up our internal page rendering time. However, as with nearly all web application development some non-error metrics gradually slipped until eventually we noticed that our page render time had become unacceptably long. We decided to take a couple of days off from coding new features and cleaned up the code. Here’s what we did.

Before we started, our page render time was about 8 seconds including the calls to Google AdSense, which added 2 seconds. (See the Pingdom trace at Note 2). We tackled 4 key areas to reduce the page load time.

Pingdom 1 - Click for full size

Pingdom 1 - Click for full size

  1. AdSense Optimisation – Two Second Improvement. The most obvious problem was the time it was taking to get the Adwords to load and render. We had up to three sets per page and this was adding about 2 seconds. There seems to be no way to speed this process up. The bulk of our users are interested in our content rather than our ads, so we put the ad units into their own iFrame and let them load after our content had loaded. You can see the effect on our dentists in Dublin page. (See Note 3)
  2. Combining Files – One Second Improvement. In most cases the number of files that a page forces the browser to download is more important to the actual weight of the page. This is because browsers are limited in the number of files that they can simultaneously download, and each file has a latency and bandwidth overhead. Reducing the number of files is frequently the easiest way to improve render time. We were already using a CSS sprite for images, but we had let a few get loose. We tidied this up and combined 5 more images into the sprite. We also got rid of one CSS file and combined 4 JavaScript files into one. The reduction of these 9 files cuts about one second off of render time.
  3. More effective use of simultaneous downloading – Half a Second Improvement. As mentioned above we use a CSS sprite to reduce the number of image files. This sprite was only referenced in the CSS and not in the HTML. This resulted in the HTML being downloaded, then the CSS, and then the sprite in that order. We changed this so that the sprite gets loaded in parallel to the CSS file by calling it in the HTML.
  4. Code Tidy up – Half a Second Improvement. This was never going to give us much of an improvement because we use compression on our web server which reduces the size of our HTML, CSS and JavaScript by about 70% – so despite the fact that the files are relatively large the actual bandwidth overhead is low. Still we managed to cut an uncompressed 30KB off of the HTML, 40KB off the CSS and 40KB off the JavaScript.
Pingdom 2 - Click for full size

Pingdom 2 - Click for full size

So what do we still have to do? By no means have we completed our page optimization and we have plans to knock a further second off of the page load time by:

  1. Dynamic image caching and potentially creating a sprite on the fly
  2. Using a content delivery network for our static images, JavaScript and CSS files
  3. Further optimized JavaScript

Notes

  1. I use the metric render time rather than page load time because what we are trying to measure is user experience – not the time it takes for bits to go down a pipe. Many web 2.0 applications rely on JavaScript to be downloaded and run in the browser before anything of value is displayed to the user. In older browsers this can frequently add a second or more on top of page load until the user is presented with the page.
  2. The trace does not include the dynamic thumbnail images that we pull in for each clinic. There are typically 3 of these images but there may be as many as 12. It also does not include the Google Adsense or Google Analytic calls.

    3. Pingdom

  3. Strictly speaking putting you Google Adsense Ad units into an iframe is against the Google Terms of Service, however Google has provided guidance that as long as you don’t deceive the visitor that the practice is acceptable.

Useful Tools