How to analyze and speed up content rich web sites likes in minutes

One of my daily activities is checking interesting blog posts on various performance related topics. Today I stumbled across the blog 10 Cool Websites with Amazing jQuery Effects. I started looking at these pages which really have nice UI features implemented with jQuery. What many of these pages have in common is that they contain a huge number of images that are all hosted on the same domain. Depending on which browser you have this can result in long loading times of all images or other embedded objects such as style sheets, JavaScript files, …

Not only have I seen the problem of too many images on these pages – I also constantly see this with sites I analyze with our AJAX Edition Community members. The Free Dynatrace AJAX Edition offers an easy way to identify how many objects you have on your individual pages – whether these images are cached locally or have to be retrieved for every page request and how much time the browser actually has to wait for requesting individual images. There are other tools out there that focus on network request analysis – such as PageSpeed, YSlow, HttpWatch, Fiddler, … – so – feel free to use them – but – you miss all the cool stuff like JavaScript/AJAX/DOM/XHR tracing that the Dynatrace tool offers as well.

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
After starting the Dynatrace AJAX Edition start tracing the following example (empty your browser cache for the exact same results that I got):

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

Open the Summary View by either double clicking on the Session – or by double clicking on the Summary node underneath the session. What we get is on overview of all the different URLs we have visited. I select the home page URL and then look at the charts underneath that show how many resources were loaded and what took most of the time from a network download perspective (DNS, Connect, Server, Transfer). As mentioned in the intro – Dynatrace AJAX is pretty strong in analyzing JavaScript/AJAX Activity. If this is of interest for you I recommend reading my previous post – How to speed up sites like In this post I want to focus on network activity only. Lets look at the Summary View:

Summary View focusing on Resources and Network
Summary View focusing on Resources and Network

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 🙂
  • We can also see that I spent 16.203s in transferring the content. Transfer Time is the time measures from the first to the last byte received from the response. So I assume that the content is rather large (lots of images, javascript files, …) and therefore takes a long time to transfer.
  • 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

If you right-click on the home page URL in the Summary View and Drill Down to the Timeline View we get a great overview of when those resources got loaded and from which domain get came from. New with Dynatrace AJAX Edition 1.6 (released March 8th) is that the Timeline automatically colour codes the resources and JavaScript triggers:

TimeLine View showing when and where from resources got downloaded
TimeLine View showing when and where from resources got downloaded

The pinkish colour in the Network section represents our 144 images. It seems that some of the images are served from two servers (, Most of the images however come from 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.:, 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:

Network View showing all Image Requests
Network View showing all Image Requests

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:

Summary View showing most of the Images being served by the local cache
Summary View showing most of the Images being served by the local cache

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:

Network View showing that Cached Requests still cause a roundtrip to the server
Network View showing that Cached Requests still cause a roundtrip to the server

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:

Network View showing only those requests that need to be downloaded
Network View showing only those requests that need to be downloaded

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!!).

Next Steps

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 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

Andreas Grabner has 20+ years of experience as a software developer, tester and architect and is an advocate for high-performing cloud scale applications. He is a regular contributor to the DevOps community, a frequent speaker at technology conferences and regularly publishes articles on You can follow him on Twitter: @grabnerandi