Aptimize

Microsoft

What they needed

SharePoint is the fastest growing server product in Microsoft’s history and as a result, there is a huge volume of traffic going to its website everyday with requests from all over the world.

The SharePoint website was build to showcase the best of what SharePoint and Silverlight can achieve on the web and so like other rich, dynamic sites, its pushed the boundaries of design, resulting in a higher page payload.

Microsoft have done a lot of work to optimize server processing, but rather than accept that some visitors with lower bandwidth and higher latency would have a sub optimal experience they went in search of technology to improve the experience for these users. Aptimize provided that technology.

 

The Aptimize Solution

While SharePoint developers can take advantage of SharePoint’s scalable server processing, utilization of web browsers built-in object caching, and integration with caching offered by content delivery networks these optimizations don’t work to reduce the number of round trips made between the browser and the web server and they don’t take steps to dynamically optimize the HTML, JavaScript, CSS or image output from the server - typically, these factors contribute 80 percent to 90 percent of the page load time. This is where the Aptimize Website Accelerator (WAX) was able to help.

We applied a three step solution:

Step 1: Understand the current performance

A realistic client performance goal for every website is: pages that load in under five seconds. Five seconds for the server to process the page and deliver every piece of content to a browser anywhere in the world over a normal broadband connection.

So how did the original SharePoint.Microsoft.com stack up?

The first thing the team did was analyze and understand the current performance. Aptimize used the free WebPageTest tool to record the current load times from around the world: USA, United Kingdom and New Zealand. WebPageTest records the load time, and also produces a waterfall diagram showing how each element of the page loads.

When measuring page load times, three metrics are important:

First view is the time to load a page for the first time

Repeat view is the time to load a page once it has already been visited and the browser has it cached

Start Render is the length of time a user sees a blank page before it starts to render. This is important since it gives

The first view page load times ranged from about 10.6 to 15.3 seconds from around the world, and 6.1 – 9.4 seconds for repeat view.To see where the time is spent, WebPageTest also generates a waterfall diagram for the First View and Repeat View

This waterfall shows three stages

a) Server processing. When a browser requests a page, the webserver processes the request, and produces an HTML page. This is delivered in the first HTTP request is completed. After this, the server’s work is done. We look for a server processing time of less than 1.5 seconds – any longer than this indicates a server processing issue. For SharePoint.Microsot.com, the HTML page was returned in 473 milliseconds. This is fast, and indicates no server tuning is required.

b) Browser processing. After the browser loads the HTML file, it begins to render the HTML by starting at the top of the HTML file and processing each line of the HTML, drawing the page and loading the external JavaScript, StyleSheet and image files. The browser processing is 10.1 seconds, representing about 95% of the total page load time.

c) Post-load actions. After the page has loaded, the Silverlight controls begin to render the navigation and content for the main page, and the LivePerson service is activated. Although Silverlight can be optimized, this is outside the scope of this article.

Once the page has been loaded by the browser for the first time, some elements are cached on the local machine and a repeat view is typically faster since the browser doesn’t have to load the resources it has cached. Notice how the waterfall is shorter for the repeat view.

After recording the current performance, ruling out server problems, the website is ready for browser processing optimization.

Step 2: Optimize the website for speed

There is an established method for optimizing a website for speed using performance best practices.

Sever optimization

The load profile for SharePoint.Microsoft.com showed that the server, database and application itself were running well within expectations – SharePoint was able to produce the HTML page in under half a second which is better than most websites. No optimization was needed on the server.

Reduce HTTP requests

Browser processing, the time it takes to load every JavaScript, StyleSheet and image resource on the page contributed 95% to the load time. With 96 resources, this was a page that could benefit from optimization. Reducing the number of resources would result in server output that requires less round trips for a browser to load the page.

For a first view, the browser loads 96 files and resources

File type	Count
JavaScript files	18
StyleSheet files	17
Image files	37
HTML, other files and duplicates	24
Total	96

There are some simple, well established techniques for reducing the number of JavaScript, CSS and image resources:

· Merge JavaScript files into fewer files

· Merge the StyleSheet files into fewer files

· Reduce the number of images using CSS Sprites and CSS inlining

CSS sprites are a useful technique for reducing the number of images. Multiple individual images can be copied side by side into an image tile, and then referred to individually within the page, using an offset into the image tile.

Even though all the PNG images appear as individual images in the webpage, they are stored and loaded as one tile, which actually looks like this:

CSS inlining is another technique to reduce image counts – with CSS inlining small background image files are converted into a Base64 encoded stream and copied into the CSS StyleSheet itself.

After merging JavaScript files, Stylesheets and image files the number of resource files in the page was reduced by 64%

	Original	Optimized	Reduction
JavaScript files	18	11	39%
CSS StyleSheet files	17	5	71%
Images	38	13	66%
Other files and duplicates	23	6	74%
Total	96	35	64%

Increase caching

Configuring resources with far-future-expires further reduces the load time for repeat views. With far-future-expires, static resources (images, JavaScript, StyleSheets) are set with an “expires” cache header that instructs the browser to cache the resource for a year, without checking for updates. This greatly reduces the HTTP requests, since the browser doesn’t need to confirm it has the latest version of each resource.

Out-of-the-box, SharePoint sets the best caching for the resources shipped with the product, but can’t anticipate what people add to their own sites. Configuring every resource with far-future-expires creates problems if the resources change – the browser doesn’t check for a newer version, so the changed resource will never be downloaded.

With Aptimize Website Accelerator, we were able use far-future-expires to their fullest potential, setting far-future-expires for the static resources, and excluding dynamic resources (such as search results) that change with each search. If static resources change, Aptimize Website Accelerator automatically detects the change and alters the URL of the resource to force the browser to download an update.

This process reduces the HTTP requests, load time and page size for repeat views of the same page.

Reduce size

The final technique is to reduce file sizes. The JavaScript files and CSS StyleSheets contained whitespace and comments. While this represents sound coding practice and is critical to ensure that developers can understand and interact with these files, whitespace and comments aren’t necessary for browser render. As a result, whitespace and comments were removed.Gzip compression was already turned on in the original site which helps to reduce file sizes more. Images should not be Gzip compressed since JPEG, GIF and PNG images are already compressed as part of their file format.

Remove duplicates

Any duplicate JavaScript and Stylesheet files that were downloaded more than once were changed to a single reference during the merge process.

Manual or Automatic

While all the steps described above can be applied by manually altering the resource files, these techniques were applied automatically using the Aptimize Website Accelerator, a software product that can dynamically optimizes SharePoint pages for speed.

Step 3: Results

After making these changes, the team measured the load times again using WebPageTest from locations around the world.

The waterfall graph for first load shows a reduction in HTTP requests from 96 to 35

The repeat view waterfall also shows a reduction in HTTP requests from 50 to 9.

Benefits

First view page load times were reduced 46% to 64% with great improvements for people on high latency connections. Repeat view load times were reduced 15% - 53%, and start render time was reduced more than 50%. These benefits are primarily due to the reduction in the number of HTTP requests.

By reducing HTTP requests, increasing caching, and reducing file sizes, the SharePoint pages are now optimized for speed using best practices for website performance. Future optimizations are possible for the post-load actions by optimizing the Silverlight controls but the SharePoint pages themselves are now high performance. The installation and configuration process took only a few hours effort, and the results were immediate.