Ensuring Web Site Performance – Why, What and How to Measure Automated and Accurately

Posted: October 10, 2011 | Author: Snapjudge | Filed under: ASP.NET, Performance | Tags: Ajax, App, Apps, ASP, Dynatrace, Monitoring, Notes, PDF, Perf, perfmon, Performance, UI, User Interface, Web | Leave a comment »

By dynaTrace

Using network analysis tools like HTTP Watch or Fiddler one can visualize the individual downloads in a timeline view

there are different stages of perceived performance and perceived response time.

The First Impression of speed is the time it takes to see something in the browsers window (Time To First Visual). We can measure that by looking at the first Rendering (Drawing) activity. Get a detailed description about Browser Rendering and the inner workings the Rendering Engine at Alois’s blog entry about Understanding Browser Rendering.

The Second Impression is when the initial page is fully loaded (Time To OnLoad). This can be measured by looking at the onLoad event which is triggered by the browser when the DOM is fully loaded meaning that the initial document and all embedded objects are loaded.

The Third Impression is when the web site actually becomes interactive for the user (Time To Interactivity). Heavy JavaScript execution that manipulates the DOM causes the web page to become non interactive for the end user. This can very often be seen when expensive CSS Selector Lookups (check out the blogs about jQuery and Prototype CSS Selector Performance) are used or when using dynamic elements like JavaScript Menus (check out the blog about dynamice JavaScript menus).

How to Speed Up sites by more than 50% in 5 minutes

Minute 1: Record your dynaTrace AJAX Session

Always turn on argument capturing

The reason I do that is because I want to see the CSS Selectors passed to the $ or $$ lookup functions from various JavaScript frameworks like jQuery or Prototype. The main problem I’ve identified in my work are CSS Selectors per className that cause huge overhead on pages with many DOM elements. I wrote two blogs about the performance impact of CSS Selectors in jQuery and Prototype.

Minute 2: Identify poorly performing pages

1. Having high JavaScript execution.

2. :arge amount of Rendering Time – that is time spent in the browser’s rendering engine

3. Page load times (time till the onLoad event was triggered) of more than 5 seconds!!

4. Very high Network Time although it doesn’t have a very bad page load time. This means that we have content that was loaded after the onLoad

Minute 3: Analyze Timeline of slowest Page

1. The script ?? takes xxx ms when it gets loaded

2. an XHR Request at the very beginning takes xxx ms

3. we have about 80 images all coming from the same domain – this could be improved by using multiple domains

4. we have calls to external apps like facebook, google ads or google analytics

Minute 4: Identify poorly performing CSS Selectors

they change the class name of the body to “en” which takes 550ms to execute.

The site makes heavy use of the CSS Selectors to look up elements by class name. This type of lookup is not natively supported by Internet Explorer and therefore jQuery has to iterate through the whole DOM to find those elements. A better solution would be to use unique IDs – or at least add the tag name to the selector string – this also helps jQuery as it first finds all elements by tag name (which is natively implemented and therefore rather fast) and then only has to iterate through these elements.

Minute 5: Identify network bottlenecks

The solution for this problem is using the concept of domain sharding. Using 2 domains to host the images allows the browser to use twice as many physical connections to download more images in parallel. This will speed up page the download of those images by 50%.

Besides the problems with CSS Selectors and Network Requests we see problems with poorly performing JavaScript routines (very often from 3rd party libraries), too many JavaScript files on the page, too many XHR (XmlHttpRequests) Requests to the server and slow responses from the server of those XHR Requests.

Optimizing Data Intensive Web Pages by Example

Using tools like dynaTrace AJAX Edition for Internet Explorer, YSlow or PageSpeed for FireFox or DevTools for Chrome enables automating web site performance measuring in manual and automated test environments.

URLs Measured Tab: check out ShowSlow. The site is really great. It combines YSlow and PageSpeed metrics and visualizes them in a really nice way.

I then took a close look how many URLs this page is displaying. Obviously ShowSlow really has become a victim of its own success – it is over 9000 URLs. So, did they do something wrong? Actually what happened is quite typical for an iterative development approach. You build an application that satisfies certain requirements and take care of further requirements later. Additionally, you normally don’t expect to be so successful so fast.

We can additionally put the style definition into a separate file which will be cached. This will reduce download size even more. Another interesting side effect of this change is the reduction in layout calculation time.

The problem we now have to solve is how to populate the table. If we would write all rows immediately via JavaScript this will definitely make our web page completely unresponsive. So I decided to render only the first 200 rows and then dynamically render an additional 100 rows when the user scrolls to the end of the page.

Andi wrote an interesting blog post about String concatenation problems in IE.

What are our takeaways? First, avoid repetitive markup on pages as much as possible. In our case, just getting rid of the style definitions helped us to reduce the payload by 1.7 MB. As we have seen this is especially important for data-driven sites, as each additional byte of content multiplies by the number of data items presented.

Secondly, you have to be careful with the markup-to-actual-data ratio. In this case it was rather low. Admittedly this will be different for other web pages; however, you always should keep this in mind. Especially for datadriven services you should consider only sending the actual data and build the markup on the client side. In this case you additionally have to be careful regarding JavaScript execution time.

From an application design perspective this means we have to separate our application into the classical three MVC layers.

• The model layer – meaning the “pure” data – which in our case was put into the JSON file.

• The controller layer – which in our case is the HMTL page itself and the JavaScript logic to dynamically manipulate the DOM.

• The view layer – in our case the style definitions – which are separated from all the other two layers.

Hands-On Guide: Verifying Web Site against Performance Best Practices

• Time to First Impression/Drawing:
- Recommendation: < 1s is great. <2.5s is acceptable

• Time to onLoad: 8.25s
- Recommendation: < 2s is great. <4s is acceptable

• Time to Fully Loaded: 8.6s
- Recommendations: < 2s is great. <5s is acceptable

• Number of HTTP Requests: 201
- Recommendations: < 20 is great. < 100 is acceptable (This one is a hard recommendation as it really depends on the type of website – but – it is a good start to measure this KPI)

• Number and Impact of HTTP Redirects: 1/1.44s
- Recommendations: 0. Avoid Redirects whenever possible

• Number and Impact of HTTP 400′s: 1/0.71s
- Recommendations: 0. Avoid any 400′s and 500′s

• Size of JavaScript/CSS/Images: ~370kb/220kb/890kb

- Recommendations: It is hard to give a definite threshold value. Keep in mind that these files need to be downloaded and parsed by the browser. The more content there is the more work on the browser. The goal must be to remove all information that is not needed for the current page. I often see developers packing everything in a huge global .js file. That might be a good practice but too often only a fraction of this code is actually used by the end-user. It is better to load what needs to be loaded in the beginning and delay load additional content when really needed

• Max/Average Wait Time: 4.31s/1.9s
- Recommendations: < 20ms is good. < 50ms is acceptable (as you can see – we are FAR OFF these numbers in this example)

• Single Resource Domains: 1
- Recommendations: 0. Try to avoid single resource domains. It is not always possible – but do it if you can

Usage of Browser Caching

Browsers can cache content such as images, javascript or css files. Caching elements greatly improves browsing behavior for revisiting users as they do not need to download the same resources again.

Network Resources and Transfers

This area of analysis focuses on unnecessary requests for all users (not just for revisiting users caused by wrong cache settings). The first types of requests that should be avoided are HTTP Redirects (300′s), Authentication Issues (400′s) and Server-Errors (500′s).

Application Server-Side Processing Time

• First request on the page -> usually returns the initial HTML
• Requests that return HTML -> generated content (this also may include static HTML pages)
• Requests on URL’s ending with aspx, jsp, php
• Requests that send GET or POST parameters data to the server
• All XHR/AJAX Requests

Here are some MUST READS:
• Best Practices from Google and Yahoo
• Blog from Steve Souders and John Resig (jQuery)
• dynaTrace Blogs on AJAX and Performance Almanac

Additionally you should check out How to Get Started with dynaTrace AJAX Edition and the Webinar we had with Monster.com to better understand how dynaTrace AJAX Edition can help you analyze your website.

---