Designing pages for quicker downloads (SharePoint Server 2010)

Applies to: SharePoint Server 2010

Microsoft SharePoint Server 2010 includes features that help to optimize page loading over a wide area network (WAN). Designing pages to make them as small and responsive as possible complements these performance improvements.

Different techniques are not specific to Microsoft SharePoint Server 2010. General methods that you can use on any Web site are not discussed in great detail in this article. Instead, this article focuses on the features in Microsoft SharePoint Server 2010, elements that are included in the page, and ways in which you can speed up an initial visit to a SharePoint site.

Page elements

A page on a SharePoint site consists of several unique elements, as shown in the following figure.

When the page is rendered, it brings together the master page, the layout page, and content for the page. The page content includes the values for each of the page fields, but also a number of other elements such as the theme, style sheets, images, and navigation. The following table shows an example of the files and streams that are present in a single page from a SharePoint site. This example is a capture of all the HTTP requests that were made on an initial visit to the default home page of a collaboration portal site.

Note the following:

• A total of 29 requests were required to download the page.

• The total page size was 235 kilobytes (KB).

• This represents the initial page load; almost all of the items in the request have a caching directive that instructs the browser not to load them again for one year. The second and subsequent page loads produce only three requests. Of those, two are part of the NTLM negotiation that occurs, so only one item is actually downloaded—the HTML for the page.

• The default IIS Compression level 0 was used, which is the least amount of compression possible. Additional compression would result in even smaller download sizes.

• Of the different file types loaded, there were:

  • 4 .axd resource requests

  • 4 .css resource requests

  • 12 image resource requests

  • 6 .js resource requests (several of which were duplicates)

  • 3 page resource requests for default.aspx (two of which are part of the NTLM negotiation)

Most of these file types are fairly obvious, with the possible exception being the .axd resource type. An .axd resource is part of a new feature in ASP.NET version 2.0. A developer can add a resource, such as script file or style sheet, to a control. In the control, the developer uses the ClientScript class to include a method called GetWebResourceUrl. When the control is rendered at runtime, it dynamically generates a URL for the resource. The resource itself is compiled into the control assembly, so this methodology provides a way to stream that resource out of the assembly and down to the client just as if it were a separate file located on the Web server.

Knowing the resource requests used by the page can help you understand where and how optimizations can be applied. You can measure this kind of information by using a variety of different tools and techniques. For this article, a freeware tool called Fiddler (https://go.microsoft.com/fwlink/p/?LinkId=108593) was used. Fiddler can be run on a client workstation and tracks all of the HTTP requests being made for a page. It then displays the results in a grid, as shown in the following figure.

As you change your site to optimize it, test it with Fiddler. To get the most accurate idea of what items are being requested, what items are being cached, and the size of each item:

1. Start Fiddler.

2. Delete all of your browser's temporary files by using Fiddler’s Clear Cache toolbar button.

3. Close and reopen the browser.

4. Request your page.

   Note

   Be sure that you request the page by clicking a link. If you just click the Refresh button, the system automatically requests items again and won't accurately reflect any optimization changes that have been made.

The Developer Dashboard in Microsoft SharePoint Server 2010 reveals performance bottlenecks, such as performance of Web Parts and database calls, other than HTTP requests. While not specifically a WAN optimization tool, the dashboard can help identify performance issues with a page.

For more information see Using the Developer Dashboard (https://go.microsoft.com/fwlink/p/?LinkID=224025).

Optimizing Page Downloads

After you understand the composition of the page, you can use different methods to optimize the download experience for that page. In general, the goal is to minimize the number of round trips between client computers and server computers and to reduce the amount of data that goes over the network. The guidance in this article includes recommendations that can be applied broadly to a variety of different implementations of Microsoft SharePoint Server 2010.

You should categorize page optimization techniques into one of two categories: first page request and subsequent page requests.

Optimizations for the first page request (page load time 1 or PLT1) are those kinds of optimizations that are implemented the first time the page is requested, but that don't necessarily affect subsequent page requests:

• Optimize HTML markup.

• Use consolidated images and files; for example, combine multiple CSS files into one, and combine images into an image strip or cluster.

• Use compression (crunch) techniques.

• Verify the production versions of JavaScript files are used for those that have both debug and production versions; for example, JQuery.

Optimizations for subsequent page requests (page load time 2 or PLT2) are those that can improve the user experience for a subsequent page load. The key is that you need to balance loss in functionality against the gain achieved. If gain is only realized the first time a user hits a site, the optimization might not be worth the loss in functionality.

You can use caching directives. Tools that can be used include Aptimize and Microsoft Visual Round Trip Analyzer (https://go.microsoft.com/fwlink/p/?LinkId=227443).

Compress (Crunch) files

Files that contain JavaScript and styles can often be significantly reduced in size by removal of whitespace, style inheritance, and code reuse. Some libraries come with both regular (debug) and compressed (crunched) versions. A variety of tools that can automate crunching can be found by searching the Internet.

Verify the compressed versions are deployed to production servers. This example shows how a CSS file can be reduced in size by some relatively simple rewriting. Before compression, the CSS file is 655 characters:

.article-ByLine  { 
  font-family: Tahoma,sans-serif; font-size: 9.5pt; font-style: normal; line-height: normal; font-weight: normal; color: #000000}
.article-Caption { 
  font-family: Tahoma,sans-serif; font-size: 8pt; font-style: normal; line-height: normal; font-weight: normal; color: #000000}
.article-Headline { 
  font-family: Tahoma,sans-serif; font-size: 14pt; font-style: normal; line-height: normal; font-weight: bold; color: #000000}
.article-SubHead  { 
  font-family: Tahoma, sans-serif; font-size: 11pt; font-style: normal; line-height: normal; font-weight: normal; color: #000000}
.article-Text {
  font-family: Tahoma, sans-serif; font-size: 10pt; font-style: normal; line-height: normal; font-weight: normal; color: #000000}

If you see the same words repeated over and over, the CSS file is not written in an efficient way. After compression, the CSS file is 127 characters:

BODY {font:100% Tahoma,sans-serif}
.art-By  {font: 79%}
.art-Cap {font: 67%}
.art-Head {font: bold 117%}
.art-Sub  {font: 92%}
.art-Txt {font: 83%}

Be careful with entity tags

Entity tags (ETags) tend to cause performance problems. They are meant to uniquely identify files by using a number that the server generates. In clusters of servers, each server will create a different number. For example, let’s say a browser is sending a Get method with an If-Modified header field for a file that it found in its cache. If there is only one server, the file will most likely match and a 304 Not-Modified error will be sent. But, if the user is accessing a large server farm, it’s most likely to hit a different server with a different entity tag, causing that server to reload the entire file to the browser.

Verify that caching is working

Use Fiddler or a similar tool to verify that caching is working as expected. Here are common reasons for caching to not work:

• No Expiration date is being set.

• A query string that is changing.

• Max-age + last-modified date must be greater than today's date.

  Note

  Max-age, if used, supersedes the expiration date. Internet Explorer will ignore the expiration if max-age is used.

• Proxy servers may not support max-age. Expiration dates are preferred.

• Cache-control = no-cache will not cache. ‘Private’ also tends to not cache correctly

BLOB cache

The binary large object (BLOB) cache can be used to apply cache directives to items on a page that are stored in Microsoft SharePoint Server 2010. If those cache directives are included, the browser won't try to download those items again until the cached item expires. As was illustrated with the previous home page example, almost all of the items included in the default home page for the Collaboration Portal site template had a caching directive associated with them, which is why they were not requested on subsequent page hits. For more details about setting up and configuring the BLOB cache, see Optimizing BLOB caching for WAN environments (SharePoint Server 2010).

Minimize secured items on the page

When a user authenticates to Microsoft SharePoint Server 2010, two things happen. First, the system validates credentials to confirm the identity of the user. Second, the role provider enumerates the list of SharePoint groups to which the user belongs. Each time a page is requested, the role provider is called again to enumerate all of the groups to which the user belongs.

This call for group membership can happen multiple times on a single page. For example, the default Collaboration Portal site template page requires two calls to the role provider when you go to the home page—one for the page itself and one for the image on the page. Each image on the page that is stored in a SharePoint library will force an additional call to the role provider to verify permissions, even if all of the images are stored in the same image library. That verification occurs whether the images are added as fields on the page—that is, part of the page's content—or whether they are added to the master page for the site.

A site that is developed for a limited bandwidth or high latency environment should be designed to minimize the number of images on the page. Many sites use several images as part of the master page to create different visual effects. Because the latency will increase with the increased number of security checks, design sites for these environments by using the smallest number of possible images.

Minimizing the number and size of images

As described in the previous section, you should minimize the number of images in your site. To help with that effort, you can embed multiple images in a single file and then reference individual images in your page. Not only will file download size decrease, but fewer files result in less network traffic. It is more complicated to author pages by using this technique, but in situations where every round trip and file size counts, it can prove to be valuable way to help improve performance. The following figure shows an example of a single image file that contains multiple images.

The following figure shows how this image is subsequently changed to display as individual pictures in a table.

Manipulation of the images was done entirely through style sheet classes. There were two primary classes used in div and img elements in each table cell. Those classes are as follows:

.cluster {

   height:50px;

   position:relative;

   width:50px;

}

.cluster img {

   position:absolute;

}

Each image has a class associated with it based on the identifier (ID) for the image. That style clips the picture and defines an offset from the initial picture in the cluster. Those classes are as follows:

#person {

   border:none;

   clip:rect(0, 49, 49, 0);

}

#keys {

   clip:rect(0, 99, 49, 50);

   left:-50px;

}

#people {

   clip: rect(0, 149, 49, 100);

   left:-100px;

}

#lock {

   clip:rect(0, 199, 49, 150);

   left:-150px;

}

#phone {

   clip:rect(0,249, 49, 200);

   left:-200px;

}

#question {

   clip:rect(0, 299, 49, 250);

   left:-250px;

}

The HTML for the table includes the div and img tags with the appropriate ID values and class names, as follows:

<table border="1">

   <tr>

      <td><div class="cluster"><img id="person" src="Icons50x50.gif" width="300" height="50"/></div></td>

      <td><div class="cluster"><img id="keys" src="Icons50x50.gif" width="300" height="50"/></div></td>

      <td><div class="cluster"><img id="people" src="Icons50x50.gif" width="300" height="50"/></div></td>

   </tr>

   <tr>

      <td><div class="cluster"><img id="lock" src="Icons50x50.gif" width="300" height="50"/></div></td>

      <td><div class="cluster"><img id="phone" src="Icons50x50.gif" width="300" height="50"/></div></td>

      <td><div class="cluster"><img id="question" src="Icons50x50.gif" width="300" height="50"/></div></td>

   </tr>

</table>

Multiple Microsoft Web properties and products, such as Microsoft Office Outlook Web Access (OWA), now use this technique. The MSN team has conducted some performance tests to analyze the impact of the changes and has seen a load time improvement for the first page of 50 to 75 percent.

There is an important point to consider if you are authoring your pages in Microsoft SharePoint Designer 2010. When you create a new page in Office SharePoint Designer 2007, it automatically adds the following XHTML schema markup to the page:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

It then adds this namespace to the HTML element:

<html xmlns="http://www.w3.org/1999/xhtml">

If you use this schema, the images will not line up correctly. You must remove the xmlns attribute from the HTML tag to make the images appear as intended.

Optimizing list view pages

The Microsoft Services team has worked to quantify and improve the performance of list view page rendering times. A list view page is the AllItems.aspx page that is used by each list and library to enable browsing of content. The rendering time of that page can vary widely based on the number of columns that are visible in the view and the format of the columns. For example, displaying options and enabling presence icons can greatly affect rendering time. Group Collapsed took significantly longer than Group Expanded to render, and both of those were slower than no grouping at all.

These sorts of nuances are why it is important to carefully consider how views are constructed in list view pages, especially over slow network connections. When working with lists that contain a lot of data, it is important to carefully design all views, especially the default view. In general, you can speed up the rendering time of list view pages by using the following techniques:

• Show fewer columns.

• Exclude columns that include presence information.

• Use a link (but no edit menu) to view the item details.

The following table describes customizations that reduce the time that is required for a view to render.

The following table describes customizations that will increase the time that is required for a view to render. Each additional column increases rendering time by a slight amount: up to a half-second per column over a fast network connection for a list of 1,000 items. Some columns increase rendering time more than others, as noted in the table.

The following table describes customizations that have a relatively small impact on the time required for a view to render.