Step 1: Use dynaTrace AJAX to trace browser activities on our target site
If you haven’t downloaded the FREE dynaTrace AJAX Edition – go ahead and do so at http://ajax.dynatrace.com/pages/download/download.aspx.
After starting the dynaTrace AJAX Edition start tracing the following example (empty your browser cache for the exact same results that I got):
- Go to http://www.utah.travel
- Select Attractions -> National Parks
- Now change the Theme to Adventure
Now close the browser and go back to dynaTrace AJAX Edition. The recorded session will show up under the Sessions folder in the Cockpit.
Step 2: High Level Analysis using the Summary View
I highlighted the numbers that are interesting for us:
- Page Load Time on that page is 17.703s -> this is the time till the browser triggered the onLoad event meaning that the initial page has fully been loaded
- Almost all of that time can be contributed to Network activity – 17.336s
- 144 images were downloaded on that page. Everything came from the Network as opposed to the local browser cache. This is because I had an empty browser cache
- The Network Breakdown shows us that most of the time (29.639s) was spent on the server. Server Time is the time measured from the last byte of a single request to the first byte of the response. That means that it also includes the initial network latency and is not 100% server time – but – it is very close
- For completeness: We also see DNS Time and Connect Time. DNS Time is the time it takes to lookup a domain name. If you embed resources from many different domains this might become a problem. This is often seen on sites that host multiple external ads or include scripts from different external locations. Connect Time is the time it takes to establish a physical connection to the server. This depends on the number of domains involved as well as whether you use HTTP or HTTPS. The HTTPS Handshake is accounted to the Connect Time. For more information on HTTP/HTTPS overhead check out my blog about 101 on HTTPS Performance Impact
You may ask yourself now – so – why does the table on the top say 17.336s but the sum of the Pie-Chart is more like 46s. The time in the chart accumulates times from parallel activities whereas the time in the table does not. Every browser has multiple physical connections open to a single domain. If you have multiple domains you end up with even more connections where content is downloaded in parallel. In the next section we look at the timeline view – this will show exactly what activity is going on in parallel.
So far we have found out that we have a huge number of images and we spend a lot of time requesting that content from the server.
Step 3: A closer look on the Timeline View to see where resources actually come from
The pinkish colour in the Network section represents our 144 images. It seems that some of the images are served from two flickr.com servers (farm3.static.flickr.com, farm4.static.flickr.com). Most of the images however come from www.utah.travel. We can see how these images get downloaded in sequence (always two at a time in my case as I am using Internet Explorer 7). It takes a total of about 15s from the first image to the last.
The first recommendation is to reduce the number of images. Using CSS Sprites is the way to accomplish this.
The second recommendation is to serve these images from multiple domains. This concept is called Domain Sharding. When using multiple domains, e.g.: image1.utah.travel, image2.utah.travel then the browser can use additional physical connections to download these resources in parallel.
Explaining the Network time difference as seen in the Summary View: If we look at the Timeline we can see parallel network activities. There are a total of 8 domains involved. Every browser uses a different number of physical connections per domain to download content. The total time of all these requests accumulated is the time shown in the Network Pie Chart. The top table in the Summary View shows the non-accumulated time – in the case above we can see that the Network Activity was done after about 17.5s – that’s also when the onLoad was triggered.
Step 4: Looking at the individual Network Requests and find out how much time could be saved
Go back to the Summary View and double click on the Chart that shows the 144 images. dynaTrace AJAX Edition will open the Network View showing only these 144 images:
What this view shows us really nice is the so called Wait Time. The Wait Time is the time a single request had to wait in order to be served by a physical connection. The browser – after parsing the initial HTML document has a list of resources to download. Due to the physical network connection limitation it can only download a few at a time putting the others into a waiting queue. The grey bar in the Time Chart shows us really nicely how long those images on that page had to wait before they could be downloaded. The colour coding additionally tells us which of these resources took the longest time to download from the server. Not to my surprise these were those resources of large size (images in the size between 100 and 250k).
If we go with the recommendations from the previous step (Domain Sharding and CSS Sprites) we can reduce the number of roundtrips, the impact that latency has on us and we can reduce the waiting time for objects as we will have more physical connections available. Instead of the 18s it took me to load the initial page with an empty cache I am sure we could cut this time at least in half.
Step 5: Testing Caching Settings
Lets do the same test again – now – with a full browser cache from our last session. Go ahead and trace another session and hit the same 3 pages. Then open the Summary View:
Good news first – most of the images (140 to be precise) are actually retrieved from the local browser cache. But – have a look at the Network time (9.027s) and especially the Server Time (16.805s). It is a bit odd that the remaining objects (6 images, 2 html and 2 others) would take such a long time – it is possible – but – let’s have a closer look. Drill down to the Network View for the home page:
The Cache column tells us that most of these images indeed were served by the local cache – but – and this is what’s interesting – all of these requests also had a Network Time, Wait Time and Server Time. How is this possible? Simply explained – it is a missing Expires Headers for those images. If no Expires Headers are set the browser sends a IF-MODIFIED-SINCE request to the server which is returned by the server that it has not been modified and so the image is actually taken from the local cache. But still – we have these roundtrips to the server that are very expensive – especially if we have high latency. Check out the following link and browse down to Add an Expires Header for more information on this.
Sorting the Network View by Cached Column we can look at only those elements that have to be retrieved from the server:
We are down to 10 requests. If you sum up the Network Column we get 3.5s of Network traffic that seems to be necessary. That’s quite an impressive cut down from 9s that we have right now (that’s more than 60% speed gain!!).
Go ahead and do the same exercise for the other pages in your recorded session and see what else you can find. I hope this was useful information in how to analyze “resource hungry” web sites.
You can also check out a recorded webinar I did with Monster.com. We talked about how they use the dynaTrace AJAX Edition in their testing environment to ensure web site performance of their job portal.
If you have any web sites that you analyzed and you want to share your approach and your findings let me know. Sharing these findings and best practices will be beneficial for all of use. Thanks