Last week I blogged about the 6 Steps to identify the major web site performance problems on sites like Unfortunately for me I did the analysis 3 days before they re-launched their website. The site looks really nice now – great job.
They fixed some of the problems I highlighted in the blog and also follow more of the best practices outlined by Google and Yahoo. In order to give them credit for the work they put in I ran another analysis on the new site. It should be interesting for everybody to see what they have changed, what they haven’t changed, what new problems they introduced and how this all impacts the web site performance to the end user.

Merging files to speed up resource loading?

On the old site the initial page loaded 23 JavaScript files and 99 images. This is now down to 2 JavaScript and 13 images. Sounds like a great improvement – but let’s have a closer look:
First of all it is a bit hard to compare two individual pages because the web site changed in terms of its structure. The first page on the old site showed different content than on the new site. Overall there are however definitely fewer images. There are even more options to bring this number down by using CSS Sprites.
The interesting part is JavaScript. A general best practice is to merge JavaScript files into fewer files. This practice was kind of followed – but only kind of: Instead of merging the code into fewer JavaScript files, the code of all required JavaScript libraries on each page was embedded in the HTML document. This approach definitely limits the number of roundtrips to download the code but it has one huge drawback: Caching these files is not possible as they are embedded in dynamically-generated HTML. The following screenshot shows the 8 individual html documents (pages) I requested. Each of these pages includes all JavaScript libraries which make up about 95% of the total document size:

Each HTML Document contains all JavaScript code embedded which contributes to ~95% of Document Size
Each HTML Document contains all JavaScript code embedded which contributes to ~95% of Document Size

In my scenario of the 8 pages I have a total of 2.6MB in HTML document size. This size can be reduced to aprox. 130kb when extracting the embedded JavaScript code into a single JavaScript file. This single JavaScript file would be ~300kb in size and must only be requested once by the client as it can easily be cached in the local browser cache. The JavaScript code itself can also be optimized. Most of the code can be minimized and obfuscated. Some of the libraries also get loaded via a technique described in Faster Loading through eval(). While loading the actual JavaScript might be faster – executing it is much slower. For a detailed analysis on this, check out Step 6: Optimizing JavaScript execution and load performance my previous blog.

The big problem I see here – even though they managed to avoid many roundtrips – is that every user must download ~300kb of HTML for every page request. In times of high-speed internet this might not seem like a problem but a) not everybody has this kind of internet speed and b) their servers are pounded with additional load and network bandwidth to the servers might become a problem with increasing load.

Expensive and too many redirects

I often enter web site Url’s without the www in the beginning, e.g.: instead of Websites usually redirect me to the correct page and I save 3 letters to type :-). Redirects like this are additional network roundtrips which we basically want to avoid in order to speed up the site. Looking at the network activity I can not only see that the initial redirect takes a very long time (4s in my case), it redirects me to another redirect adding another 570ms before I finally end up on the index.html page. The following image shows the 3 network requests when entering the URL without the www domain prefix:

Expensive redirects to get from to
Expensive redirects to get from to

What exactly does the network activity tell us in this case?

  • Initial request takes 4.2 seconds (including DNS lookup, Connect- and Server-Time) and redirects me to The fact that I am in Europe right now probably contributes a bit to the 4.2 seconds as I assume that the web-server sits somewhere in the US.
  • The 2nd request to redirects me to and takes 570ms in total. This redirect could really be avoided by redirecting me to that page in the first place
  • The 3rd request now goes to the actual index.html page which takes 2.4s in my case. Most of the time is transfer time as I am downloading 275kb of data. Again – this time is probably faster if I would sit somewhere closer to the servers – but – as discussed in the previous section this file is so big because it contains all the JavaScript code

For some further reading check out Step 3: Can we speed up downloading all these resources? in my first blog.

IE7 bug causes wrong browser detection and fallback to IE6

When I analyze a web site I always start by looking at the Summary View for my recorded session. I saw something that made me curious:

2468 Text Resources are referenced on these pages I visited