SharePoint Arrow (Bull's Eye): August 2011

In an environment with limited network capacity, streamline your pages and make them as small and responsive as possible. There are different techniques to do this, most of which are not specific to SharePoint Products and Technologies. The general methods can be used on any Web site are not be discussed in great detail in this section. Instead, the section focuses on understanding the features included in SharePoint Products and Technologies, what is included in the page, and ways in which you can speed up the 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.

URL	Size (bytes)
http://myServer/_layouts/images/topnavhover.gif	96
http://myServer/Pages/Default.aspx	1656
http://myServer/Pages/Default.aspx	1539
http://myServer/Pages/Default.aspx	66084
http://myServer/_layouts/1033/styles/controls.css?rev=EhwiQKSLiI%2F4dGDs6DyUdQ%3D%3D	1448
http://myServer/_layouts/1033/styles/HtmlEditorCustomStyles.css?rev=8SKxtNx33FmoDhbbfB27UA%3D%3D	642
http://myServer/_layouts/1033/styles/HtmlEditorTableFormats.css?rev=guYGdUBUxQit03E2jhSdvA%3D%3D	1317
http://myServer/_layouts/1033/styles/core.css?rev=5msmprmeONfN6lJ3wtbAlA%3D%3D	13596
http://myServer/_layouts/1033/init.js?rev=VhAxGc3rkK79RM90tibDzw%3D%3D	15732
http://myServer/_layouts/1033/core.js?rev=F8pbQQxa4zefcW%2BW9E5g8w%3D%3D	54367
http://myServer/_layouts/portal.js?rev=INhSs9mWTnUTqdwwIXYMaQ%3D%3D	954
http://myServer/_layouts/1033/ie55up.js?rev=Ni7%2Fj2ZV%2FzCvd09XYSSWvA%3D%3D	20508
http://myServer/_layouts/1033/search.js?rev=yqBjpvg%2Foi3KG5XVf%2FStmA%3D%3D	5092
http://myServer/_layouts/1033/EditingMenu.js?rev=eh0f0CwzvHQ7Ii0JvdsIjQ%3D%3D	2735
http://myServer/WebResource.axd?d=__WrA1TRLicJgwGEmYKqSA2&t=633214754549731034	5383
http://myServer/WebResource.axd?d=h_u9v0Coj_eDqsvEkDrdtw2&t=633214754549731034	8258
http://myServer/_layouts/images/blank.gif	43
http://myServer/_layouts/images/helpicon.gif	1025
http://myServer/_layouts/images/Menu1.gif	68
http://myServer/_layouts/images/titlegraphic.gif	1299
http://myServer/_layouts/images/gosearch.gif	19933
http://myServer/WebResource.axd?d=puevA5kEAx44yxozBd-hspPZ9eA51Rh9u95VwVGLFCc1&t=633214754549731034	224
http://myServer/WebResource.axd?d=wyTuS1folQ6wX2Tc_7NOOaeElHHqL6rtdeAeRRUR36s1&t=633214754549731034	218
http://myServer/_layouts/images/whitearrow.gif	68
http://myServer/_layouts/images/recycbin.gif	1004
http://myServer/PublishingImages/newsarticleimage.jpg	10710
http://myServer/_layouts/images/icongo01.gif	1171
http://myServer/_layouts/images/menudark.gif	68
http://myServer/_layouts/images/topnavhover.gif	96

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 (http://go.microsoft.com/fwlink/?LinkId=108593&clcid=0x409) 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 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. Delete all of your browser's temporary files.

2. Start Fiddler.

3. 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.

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 SharePoint Products and Technologies.

There is an important distinction to remember when reviewing these recommendations and when reviewing any other custom optimizations that you might develop. You categorize page optimization techniques into one of two categories: first page request and subsequent page request. Optimizations for the first page request are those kinds of optimizations that are implemented the first time the page is requested, but that don't necessarily affect subsequent page requests. Subsequent page request optimizations are those that can improve the user experience whether it is the first time a user requests the page or the fiftieth time. 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.

BLOB cache

The binary large object (BLOB) cache is discussed in more detail later in this article. In short, it can be used to apply cache directives to items on a page that are stored in SharePoint Products and Technologies. 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.

64-bit hardware

Hardware choices in the farm can affect the latency of requests as well. 32-bit systems have a memory limit of 2 gigabytes (GB) of RAM per application. Although you can extend application support to 3 GB of RAM, SharePoint Products and Technologies do not support using the /3GB switch. Low memory situations can negatively affect the request latency in the following ways:

· If the amount of memory becomes constrained, it can cause the SharePoint application pool to recycle. That forces the ASP.NET application domain to recycle as well, which can cause a long delay in responding to user requests.

· Out-of-memory errors can cause the BLOB cache to stop serving content.

By using 64-bit hardware, you can ensure that you can allocate and use enough RAM to prevent these errors.

Web garden settings

Web garden settings can also inadvertently cause the BLOB cache to work inconsistently. Because only one process can acquire the lock necessary to manage the cache, successful use the cache depends on which thread services a request. If a Web garden that does not have the BLOB cache lock services a request, the content it sends in response will not have caching directives associated with it. That increases both the number of requests and the amount of the data sent over the network. Therefore, if you intend to use the BLOB cache, you should not use Web gardens.

Minimize secured items on the page

When a user authenticates to SharePoint Products and Technologies, two things happen. First, the system validates credentials to determine who the user is. 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.

However, 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 that is stored in a SharePoint library and is on the page 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 developed for a limited bandwidth or high latency environment should be designed to minimize the number of images used 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 as few images as possible.

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 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:

<tr>

</tr>

<tr>

</tr>

</table>

Multiple Microsoft Web properties and products now use this technique, including the Microsoft Passport Network and Microsoft Office Outlook Web Access (OWA). 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 Office SharePoint Designer 2007. 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:

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

Delay downloading core.js

The main client script file included with Office SharePoint Server 2007 is called core.js. It is the largest script file at approximately 257 KB uncompressed, and approximately 54 KB compressed. In certain situations, you may be able to delay the downloading of core.js. When you do that, the page renders more quickly because the core.js file does not start downloading until the page has been opened in the browser. That enables the user to view the page and start reading the content sooner. This technique is most useful in an Internet scenario with anonymous users. Conversely, authenticated users need to have core.js downloaded at page load time for such functionality or UI elements as the Site Actions menu.

You can use the following steps to implement this technique.

1. Create a custom layout page that doesn't use core.js. This layout page will be used with the home page so initial visitors to the site will not have to wait for core.js to download immediately. It needs to be compatible with the existing home page, so the new layout page should be have the same associated content type as the layout page currently in use.

Note:

By default, in a Collaboration Portal site, the Welcome Page content type is specified.

2. Add the following tag to the page: <SharePointWebControls:ScriptLink runat="server"/>. This instructs the system to not use core.js unless it is referenced.

3. Create a custom control to check for authenticated users. The control will be very simple, and essentially contains the following code (shown in C#):

if (HttpContext.Current.Request.IsAuthenticated) Microsoft.SharePoint.WebControls.ScriptLink.RegisterCore(this.Page, true);

4. On each Web server, put the control in the Global Assembly Cache (GAC), and then add a SafeControl entry for it in the Web.config file for the Web application in which it will be used.

5. Add the custom control to the custom layout page created in step 1.

6. Add an IFRAME to the layout page. It should reference a page that has the following content:

<body> <SharePoint:ScriptLink name="core.js" runat="server" /> <script language="javascript"> DisableRefreshOnFocus(); </script> </body>

7. Check in the custom layout page and publish it.

8. Base the home page for the site on the new layout page.

After you perform the preceding steps, test the home page for the site to verify that it works. A first-time anonymous user should not see a reference to core.js in the page source, but it should end up in browser cache.

Additionally, consider the following before employing this technique:

· The site master page and the system master page must be different; otherwise, all pages in _layouts would not work right.

· Ensure that the master page doesn't contain any controls that require core.js at load time to work.

· Ensure that the master page doesn't have any ScriptLink controls that load or reference core.js.

For additional details and sample code, see the Microsoft Enterprise Content Management (ECM) Team Blog (http://go.microsoft.com/fwlink/?LinkId=106008&clcid=0x409).

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 how many columns are visible in the view and what format they are. For example, display 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's important to carefully consider how views are constructed in list view pages, especially over slow network links. When working with lists that contain a lot of data, it's important to carefully tailor all views, especially the default view. In general, you can speed up the rendering time of list view pages by:

· Showing fewer columns.

· Excluding any columns that include presences information.

· Using a link (but no edit menu) to view the item details.

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

Item	Description
View type	Create a view as a datasheet view instead of a standard view.
View: Item Limit	Anything over 1,000 will likely render slowly. Over a slow connection it's important to experiment to find the right balance between the quantity of data shown at a time and the number of round trips necessary to view all the data. The more rows that are shown at a time, the fewer round trips, but larger pages.
View: Filter	Use [Today] and [Me] to filter items by freshness or assignment. Use Status fields to show only active items in default views.
View: Columns	Use as few columns as necessary. Create a default view with few columns that allows high-level browsing after which people can drill down.

The following table describes customizations that will increase the time 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 cost more, as noted in the table.

Item	Description
Group By	Grouping adds HTML and JScript, slowing down rendering for large lists. Making all groups collapsed by default actually increases rendering time further because of additional operations on the browser object model.
Column – title linked to item with edit menu	The option "linked to item with edit menu" takes the longest; the similar option "linked to item" does not increase rendering time noticeably.
Column – Lookup User with Presence	Adding a user lookup field with presence adds HTML for each link to open the presence menu. In addition it also uses bandwidth to determine presence availability.

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

Item	Description
Sort, Totals	Applying multiple sorts and totals will increase the rendering time by a noticeable amount, but each one typically costs less than a second for a list of 1,000 items.