We like to blog about real life scenarios to demonstrate practical examples on how to manage application performance. In this blog I will tell you how we internally improved page load time for some of our community users by 3.5 seconds by simply following our own web performance guidelines that we promote through our blog, community articles and our Performance Report in dynaTrace AJAX Edition and dynaTrace AJAX Premium Version.

Step 1: Identifying that we have a problem

We had users complaining about long page load times when entering http://community.dynatrace.com. Testing it locally showed acceptable page load time – not perfect – but not too bad either. In order to verify the complaints we looked at the actual end user response time captured by dynaTrace User Experience Management. Focusing on our Community Home Page we saw that we in fact have a fair amount of users experiencing very high page load times. The following screenshot shows the Response Time Histogram of our Community Home Page.

Response Times ranging from 1 to 22 seconds for our Community Home Page
Response Times ranging from 1 to 22 seconds for our Community Home Page

I was also interested in seeing whether there are any particular browsers experiencing this problem. The next screenshot therefore shows the Response Time grouped by Browsers:

Mobile Browsers have a significant performance problem when loading our home page. My first thought is latency problems
Mobile Browsers have a significant performance problem when loading our home page. My first thought is latency problems

Now we know that we really have a performance problem for a set of users. I assume that the real long load times are somehow related to network latency as the main user group uses a Mobile Safari. Let’s continue and analyze page load behavior.

Step 2: Analyzing Page Load Behavior

Analyzing Page Load Behavior of http://community.dynatrace.com and looking at the Network Roundtrips shows one of our problems immediately. The following screenshot highlights that we have a chain of 6 redirects from entering http://community.dynatrace.com until the user ends up on the actual Home Page – http://community.dynatrace.com/community/display/PUB/Community+Home. Depending on Network Latency this can take several seconds and would explain why mobile users experience very long page load times.

The following screenshot shows that even on my machine – being very close to our web servers – it takes 1.2 seconds until the browser can actually download the initial HTML Document:

6 Redirects take 1.2 seconds to resolve. On a mobile network this can up much higher depending on latency
6 Redirects take 1.2 seconds to resolve. On a mobile network this can up much higher depending on latency

We often see this particular problem (lots of redirect) with sites we have analyzed in the past. Now we actually ran into the same problem on our own community portal. There are too many unnecessary redirects leaving the browser blank and the user waiting for a very long time. First problem therefore is to eliminate these redirects and automatically redirect the user to the home page url.

A second problem that became very obvious when looking at the dynaTrace Browser Performance Report is Browser Caching. We have a lot of static content on our Community Pages. Caching Ratio should therefore be as high as possible. The Content Tab on our Report however shows us that 1.3MB are currently not cached. This is content that needs to be downloaded every time the user browses to our Community Page even though this content hardly ever changes:

dynaTrace tells me how well my web page utilizes client side caching. 1.3MB are currently not cached on a page that mainly contains static content
dynaTrace tells me how well my web page utilizes client side caching. 1.3MB are currently not cached on a page that mainly contains static content

The report not only shows us the percentage or size of content that is cached vs. not-cached. It also shows the actual resources. Seems that our system is configured to force the browser to not cache certain images at all by setting an expiration date in the past:

Lot of static images that have an expiration header set to January 1st 1970 forcing the browser not to cache these resources
Lot of static images that have an expiration header set to January 1st 1970 forcing the browser not to cache these resources

Step 3: Fix and Verify Improvements

Fixing the redirects and caching was easy. Instead of 6 redirects we only have 1 (as we have to switch from http to https we can’t just do a server-side url rewrite). Optimized caching will have a positive impact for revisiting users as they have to download fewer resources and with that also safe on roundtrips.

The following image shows the comparison of the page load time before and after the improvements:

Improved Page Load Time by 3.5 seconds due to better caching and optimized redirect chains
Improved Page Load Time by 3.5 seconds due to better caching and optimized redirect chains

The improvements of 3.5 seconds are significant but we still have many other “opportunities” to make our Community Portal faster. One of the next areas we want to focus is server-side caching as we see a lot of time spent on our application servers for our content pages that are created “on-the-fly” by evaluating Wiki-Style Markup code. More on that in a later blog post.

Conclusion and More

You have to analyze performance from the end user perspective. Just analyzing page load time in your local network is not enough as it doesn’t give you the experience your actual end users perceive. Following the common web performance best practices improves performance and should not only be done when your users start complaining but should be something you constantly check during development

There is more for you to read: