Performance, Scalability and Architecture

Andreas Grabner

Subscribe to Andreas Grabner: eMailAlertsEmail Alerts
Get Andreas Grabner: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: RIA Developer's Journal, ColdFusion on Ulitzer, Adobe AIR on Ulitzer, OpenAjax Alliance News, Microsoft Developer

Article

Top Low Hanging Fruit to Performance Optimize Your Web Site

Steve Souders at the Ajax Experience in Boston

Web Page Performance was one of the big topics at the Ajax Experience in Boston this week. Steve Souders - author of High Performance Web Sites and Even Faster Web Sites - talked about the top things to look into when analyzing web page performance.

Business impact on Web Site Performance

Steve presented some recently published studies from Google, Microsoft and Shopzilla showing how much of a business impact web page performance has. Google and Bing presented a study showing how many people leave the site with degrading page performance and many fewer clicks these users make. Lost users and fewer clicks lead to less generated revenue with their ads.

Shopzilla showed how they could boost their business and save on the hardware side by improving their web site performance:

Shopzilla Performance Summary

Shopzilla Performance Summary

Top Low Hanging Fruits

In Steve Souders opinion, most of the web performance problems relate to how the web page is designed leading to issues like too many embedded resources, too large JavaScript files, missing compression and client side caching. Following is a list of some low hanging fruits in order to speed up web site performance. I am using the FREE dynaTrace AJAX Edition to visualize the individual use case scenarios:

Too many network roundtrips due to too many embedded resources

Analyze the actual network roundtrips when requesting a page. Not all embedded resources (like images, css, ...) get loaded in parallel by the browser. Each browser has a set of physical network connections that are used to downloaded embedded objects. The following dynaTrace network view shows that - when accessing http://280slides.com/Editor - 172 .png images have to be loaded by the browser. It also shows how loading these objects gets deferred due to the network connection limitation of the browser.

Many embedded images slow down overall page page

Many embedded images slow down overall page page

You can use several different techniques to lower the amount of network roundtrips. If images are static think about client side caching. Or consider CSS Sprites to reduce the number of images by merging them into one bigger image. Another technique is Domain Sharding to overcome the network connection limitations.

No optimal use of Caching and Compression

Analyze the embedded objects for the usage of client side caching and compression. Static images can be cached on the browser to reduce network roundtrips on subsequent page requests. Look at the http response to analyze current cache settings and analyze if they could be cached in case they are not. Same thing holds true for compression. Large files can be compressed lowering the required network bandwidth.

Request details showing current cache and compression settings

Request details showing current cache and compression settings

Check out this blog entry by Puneet Sangal that gives guidance on content caching and compression.

JavaScript files blocking browser downloads

When JavaScript files are downloaded by the browser - the browser blocks all other activity, e.g.: downloading additional embedded images. This holds true for older browsers (IE 6, FF 3). Newer versions of these browsers at least parallel load other resources - but - once a JavaScript file is downloaded it will be executed. During execution all other tasks are stopped. Looking at the network request image above shows us that there was a big gab after one of the JavaScript files was downloaded. This tells us that the browser actually executed the JavaScript filed and postponed downloading of the remaining embedded objects. Looking at the JavaScript that got executed shows us where the time was actually spent:

JavaScript Execution blocking additional downloads

JavaScript Execution blocking additional downloads

Check out this blog entry from webdigi - it explains how to avoid blocking content download by JavaScript

Failing network requests

AJAX Frameworks tend to dynamically load embedded objects for different reasons either using XHR (XmlHttpRequest), iFrames or by creating DOM objects. Incorrect constructed URLs lead to failing network requests. Using all different types of frameworks that use techniques like that make it hard to identify where in the JavaScript library these URLs are constructed. With the dynaTrace AJAX Edition you can solve this by drilling from the failed network request in the network view down to the PurePath view showing the JavaScript methods that executed the call:

JavaScript library dynamically constructs URLs

JavaScript library dynamically constructs URLs

In the above example the JavaScript framework tried different network path patterns to retrieve a specific file. Each attempt caused a very expensive network roundtrip (>500ms) totalling up to several seconds to retrieve a certain file.

Any other low hanging fruits?

Books like those from Steve Souders or blog entries from the web performance community cover many approaches and checklists to speed up your web page. Please share your experience and post your feedback on this blog.

More Stories By Andreas Grabner

Andreas Grabner has been helping companies improve their application performance for 15+ years. He is a regular contributor within Web Performance and DevOps communities and a prolific speaker at user groups and conferences around the world. Reach him at @grabnerandi