6 Steps to identify the major web site performance problems on pages like masters.com
Remark: The analysis in this blog was done on masters.com on March 24th 2010. By April 2nd 2010 masters.com was re-launched with a new look and feel. Some of the problems highlighted in this blog are still on the re-launched site. I will publish another blog analyzing the current site, compare it with the old one and highlight the changes. ALL the highlighted problems in this blog are however often seen and therefore I hope you enjoy and learn from this blog. Here we go …
It used to be that the only people who would tune in for the Masters were readers of Golf Digest. This year, however, you can add to that base audience the readers of People, InTouch, and even the National Enquirer. While Tiger Woods may not appreciate all the increased attention, it can only help boost ratings for the Masters itself. The problem is that if all those viewers try to visit www.masters.com, they might find themselves waiting a long time to see if Elin turns up.
In order to understand some of the issues that might come up this week – even before Tiger takes the first tee – I did an analysis of www.masters.com. Like earlier analyses I did for vancouver2010.com and utah.travel, I want to show you how to analyze a popular site like masters.com, and highlight potential problems based on my experience and web site performance best practices like those from Yahoo and Google
Step 1: Define and Record the Use Case
- go to http://masters.com (I leave the www out of the URL to also see how much overhead the redirect will create)
- I check out who the 2010 Tournament Invitees are
- Click through the individual menu items like News & Photos, The Course, …
- On the players page I select Tiger Woods to see his Bio
- Go the Leader Board to check out the latest scores and play with the Font Size Adjustment option (to make the font bigger)
Step 2: The first page load time is the most important one
The following observations can be made on that page by looking at the data shown in the Summary View:
- It takes almost 10 seconds till the onLoad event is triggered. The onLoad event is triggered when the initial HTML document and all embedded resources are downloaded
- It takes 3 seconds till the first drawing activity -> the user sees a blank white page before the browser starts rendering some of the images
- 6 XHR Requests are made to retrieve dynamic content prior to the onLoad event -> Can these be delayed? Can these be merged into fewer calls?
- We have high server network time – some of this time is influenced by network latency but it still seems that the servers are pretty busy delivering the (mainly) static content.
Step 3: Can we speed up downloading all these resources?
Drilling into the TimeLine view reveals where these resources come from and what happens on that page over time:
- The redirect from masters.com to www.masters.com takes almost 500ms
- There is another redirect from www.masters.com to www.masters.com/en_us/index.html taking almost 400ms -> one of these redirects would be sufficient as masters.com could directly redirect to the final index.html page saving 500ms
- All network resources are delivered from a single domain limiting the user to download more resources in parallel -> use the concept of Domain Sharding to allow the browser to use more physical connections in order to download more resources at the same time. Adding a second domain would for instance reduce the time to download all content by roughly 50%.
Step 4: How good is my 2nd visit experience?
In order to see how local caching is used I can go ahead and analyze the HTTP headers for cache-control settings. In order to get a quick overview I simply record another dynaTrace AJAX Session browsing to the masters.com homepage. This time I don’t clear my cache as I want to test how many requests come from the cache and which ones are still downloaded from the network:
To solve this problem it is recommended to use far-future expires headers. Check out the RFC for Cache Control as well as the Best Practices on this topic by Yahoo and Google. Unless there is a reason to constantly download these files (in case they really frequently change) it is better to leverage the local browser cache and reduce download times.
Step 5: AJAX for any price?
The PurePath shows us the following information:
- messages.js makes the XHR request to retrieve messages.xml
- The retrieved content is an XML document containing a messageText element with the text “The 2010 Masters is scheduled for April 5-11″ -> this request takes 300ms
- The XHR message response handler takes this XML Element and puts it into a DIV tag
- The total execution time of this operation takes 324ms
Unless there is a very good reason for using XHR in a use case like this I recommend to simply generating the initial HTML with the text that should be displayed. Even if the server has to do some additional processing here to e.g.: replace placeholders with the actual text I am sure this won’t take up 300ms.