Web Application Performance has always been one of my favorite topics due to its challenging and complex nature.  Most developers would probably describe web application performance as the length of time and amount of resources that are required for the software to concurrently read the request, process the request, and generate an HTML response.  Typically, this performance is analyzed through the use of load testing to simulate multiple users while measuring CPU, Memory Utilization, Response Time, and Database Connections.  This effort is often conducted in parallel with development efforts and outside the scope of this post.

Site visitors would probably describe web application performance as the amount of time required for the entire page to be loaded into the browser and become usable.  Rich Interactive Web Applications often include the download and execution of several Javascript, CSS, and image files in order for User Interface to function.  Additionally, there are often Javascript and image files for ad serving, analytics, and behaviorial targeting.  Perceived loading time versus actual loading time can be debated and by loading the page components in the proper order, perceived loading time can be improved without actually improving the overall load time.  Despite the subtle difference between perceived and actual load time, the amount of time required to download the entire page and all of its components often dwarfs the time required for the underlying software to actually generate the response.  Improving the overall page load time involves identifying and optimizing all of the page components.

I recently assisted one of our customers to analyze and improve the performance of a 5+ year old publishing site.  External monitoring showed an average load time of approximately 22 seconds for some of the most visited site pages.  The first step was to understand how the browser processes and downloads the page.  Firebug with YSlow is a fast way to gain some instant insight into the page load time.

What are the important factors to consider?

800K spread over almost 80 different HTTP Requests each with its own associated communication latency and overhead is an immediate red flag.  WebsiteOptimization.com estimates this will take over 20 seconds simply to transfer the page components from the over 15 different servers.  The NET tab in Firebug provides a graphical representation of each individual page component sequence and load time.  Suddenly the stored procedure that takes 500ms to execute doesn’t seem quite so bad.

What can be done easily?

The best way to improve the load time of an individual component is to remove it.  Audit and remove extra analytics, tracking, and images.  This particular site was a CMS based site that had been live for more than five years.  Over the course of that time, many things had been added and were no longer relevant.  This site had 2 different analytics implementations and several more specialized ad targeting/user tracking implementations that were no longer relevant.  We worked with the site stakeholders to reduce and consolidate these external javascript includes as well as remove six images responsible for 200K of page weight.  Organic Javascript and CSS was combined and minified where appropriate.

If the component must be delivered, then ensure it is delivered compressed to the browser and that the browser caches it for as long as possible.  This particular site was hosted on IIS 6 and almost none of the organic components were compressed nor delivered with the appropriate headers the browser needs to effectively cache.  Configuring GZip Compression required obtaining the IIS 6.0 Resource Kit from Microsoft.  Use the Metabase Explorer to find and set the appropriate flags under W3SVC/Filters/Compression.  In general we want to confirm that static compression is turned on globally and GZip configured as well as CSS and Javascript files added to the list of static file types.  There is a great article on MSDN that covers the gory details.

Setting the Content Expires headers through IIS is a fairly straightforward process.  This can be set on a per directory basis under the HTTP Headers tab.  .NET does override the IIS setting but for static images, Javascript, and CSS this can be set quickly and confirmed in YSlow.

Content Delivery Networks (CDN), if available, can help reduce latency and load time.  Google provides a free CDN service for JQuery and other popular Javascript libraries.  If a CDN is used for organic page components then the Cache Control header will often need to be set to Public.  This can be done using the Metabase Explorer or adsutil.vbs as outlined in this Knowledge Base Article.

We were able to reduce the number of components by 15%, reduce page weight by 50%, and overall page load time by 25% using a simple browser based tool and making mostly configuration changes to the web server.  Setting the Content Expires header ensures the browser cache is used effectively and has resulted in subsequent pages loading 50% faster.

Improving page load performance often requires the interaction and assistance of the site stakeholder, IT, and development.  There are often many things that can be done to improve page load time without redesigning and rewriting the entire application or purchasing additional hardware.  The following three step process can often be done very quickly and result in an immediate and measurable improvement:

1. Audit, consolidate, and remove extra page components
2. Deliver static content using GZip
3. Set Content Expires Headers

Written by Mike Minton