From The official blog of the Microsoft SharePoint Product Group
SharePoint.Microsoft.com is a critical communications channel for SharePoint. We wanted to provide visitors with a rich and helpful experience and at the same time educate them on what SharePoint can do for their businesses. The site leverages our industry-leading web content management platform, and provides useful content and resources to the visitors. In addition, we also recognized that there were fundamental Internet challenges that needed to be overcome in order to improve page loading time, especially for our global visitors. We teamed up with Aptimize Software to optimize SharePoint.Microsoft.com for high performance.

Today's guest post is by Ed Robinson, Chief Executive Officer of Aptimize Software. This post will review how we did it and the underlying performance techniques that improved the page loading speed of the SharePoint marketing website. We hope you can leverage the same process to optimize performance for other websites.

Tony Tai - SharePoint Senior Product Manager

Introduction

The Performance challenge

As designers and UI specialists all over the world continue to push the boundaries of the web experience, page payloads continue to rise. 15 years ago, web designers challenged themselves to ensure pages were under 15KB. Fast forward to 2009 and it's not uncommon to find landing pages that run 500KB and up. Thankfully bandwidth availability has grown rapidly alongside this evolution... or has it? For many Internet users around the world, bandwidth is still a challenge and even if you address bandwidth limitations, there are physical limitations as data travels around the world or bounces off satellites. As a result, sites targeting a global audience, regardless of platform or technology, need to consider the impact of low bandwidth, high latency internet connections.

The Solution

There are many strategies to address website performance, most of which have focused on server side processing, client side caching, and edge caching. SharePoint developers can take advantage of each of these with SharePoint's scalable server processing, utilization of web browsers built-in object caching, and integration with caching offered by content delivery networks. Windows 2008 R2 and Windows 7 together offer even more capabilities - with caching of head office files locally to branch offices for faster access by Windows 7 PCs within the branch offices.

While all these practices are encouraged, they 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.

Of course, with a lot of manual processing and continuous updates, it is possible to take the work done by developers and designers to minimize and consolidate this content and thus reduce the overall number of round trips and the size of the page payload. Ideally, there should be a tool to dynamically optimize page payload, leaving developers and designers should be left to carry out high value work, producing easy to read, well commented HTML, CSS and JavaScript along with easy to manipulate images.

So why are we telling you this? - SharePoint is the fastest growing server product in Microsoft's history and as a result, there is a huge volume of traffic coming to our website everyday with requests from all over the world. We built our site to showcase the best of what SharePoint and Silverlight can achieve on the web and so like other rich, dynamic sites, we've pushed the boundaries of design, resulting in a higher page payload. We've certainly 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, we went in search of technology to improve the experience for these users. We found a great partner in Aptimize that have a solution specifically designed to address the bandwidth and latency issue and they have worked on their product to ensure that it integrates smoothly with SharePoint.

Now let's take a look at how Aptimize works, how easy it was to setup up and configure on SharePoint, and the results we experienced. Keep in mind though, Aptimize isn't restricted to SharePoint so whether you've joined the ranks of Ferrari, Kraft, AMD and others, or you have a custom .net or PHP site, you can see the same benefits

This article walks through the three-step-process for analyzing and improving performance using frontend optimization techniques with Aptimize's Website Accelerator.

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.

New page load times

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.

Ed Robinson - Chief Executive Officer, Aptimize Ltd

Conclusion

A faster website improves the visitor's experience, and with some smart use of technology, we can continue to design and build sites in line with industry best practices, while dynamically addressing issues of low bandwidth and high latency. As a result, we can ensure that site visitors all over the world experience the richness of our site, without compromise!

Tony Tai - SharePoint Senior Product Manager, Microsoft Corporation

< Prev		Next >