Microsoft Enterprise Content Management (ECM) Team Blog : Source Code

Building a new page layout which does not reference core.js (but downloads it while the page is being viewed thereby optimizing response time)

LLiu — Thu, 22 Feb 2007 07:06:00 GMT

[The optimization technique described below is an updated version of a previous blog entry. The primary change is that a new page layout rather than a detached page should be used.]

If you have an internet-facing website, you are probably exploring all avenues to make it more responsive to clients. For some users – particularly those with low-bandwidth or high-latency connections – the very first page load of a site can take a long time because of all the resources which need to be downloaded along with the page markup itself. Although these resources are often shared between pages and cached on the client, the first page load can be painfully slow.

In MOSS 2007, it is possible to defer the downloading of some of this content until the user is actually able to read the homepage. In this way, the page is rendered much more quickly, while the user’s experience of interacting with the site is not negatively impacted.

In this blog we will describe how you can create a specific page within your site (for example, it could be the root homepage) using a special layout, and remove core.js from the list of resources that must be downloaded before the page can render for an anonymous user. Because this core.js is about 54KB in its compressed form, this can enable the page to render as much as 10 seconds earlier for clients on a 56kb modem connection. Once the user is reading the page, core.js will download in the background.

By default, all pages in MOSS 2007 contain a reference to core.js. In many places, this file is critical, such as where the Site Actions Menu is shown. There are also some instances, however, when core.js is unnecessary. This workaround makes it possible to delay downloading core.js by certain users on a pages created with a specific layout. It does not matter whether the user is anonymous or authenticated; core.js will still be downloaded to the client. The distinction is that for authenticated users, it will be downloaded before the page is readable, while for anonymous users it will be downloaded after the page is readable.

First, let’s set some expectations. This is not an officially supported optimization, but it puts the ability to fine tune in the hands of the site administrators, while assuming the burden of ensuring that the site works as expected afterwards. This does not remove core.js from the entire site, just from pages created with a specific layout, and these pages will have the requirement that nothing on them requires core.js (otherwise they would obviously break). For example, the SharePoint Menu control, if required for anonymous users, would not function on such a page.

We welcome feedback on any elements of this process.

Before beginning, we need to do three things:

· Ensure that the Site Master Page is different from the System Master Page. This information can be found by browsing to the URL http://<yourservername>/_Layouts/ChangeSiteMasterPage.aspx . If you observe that the Site Master Page and the System Master Page are referencing the same file, this optimization will not work for you; it is required to change the Site Master Page to use a different file. Example pages that use the System Master Page are /_layouts/Settings.aspx, and in general any pages in the _layouts directory.

· Ensure that there are no controls in the Site Master Page which will be visible by anonymous users and which require core.js but do not register it. The optimization we use will suppress core.js only for anonymous users, and only on a single page, which means that authenticated users will still get core.js by default. If you modify the code referenced in step 5 to suppress core.js for more than just anonymous users, you will need to take this into account at the Site Master Page level, as well.

· Ensure that the Site Master Page does not have any ScriptLink controls which register core.js. The goal of this exercise is to create a single page which suppresses core.js, even though it would have been registered by the SPWebPartManager under typical circumstances.

Having satisfied these criteria, we can now be confident that the site is ready for our optimization.

1. Create the page layout which is not to reference core.js. One way of doing this is to use SharePoint Designer, make a copy of an existing layout and paste the copy in the same directory. For this example, we’ll copy ArticleLeft.aspx and call the new layout ArticleLeftNoCore.aspx. Note that you’ll probably want to edit the description of this new file so that when you create a new page, you’ll be able to distinguish the two layouts.

2. In SharePoint Designer, Edit ArticleLeftNoCore.aspx.

3. Inside the tag with ID PlaceHolderAdditionalPageHead, Add the following markup: <SharePointWebControls:ScriptLink runat="server"/>

This has the effect of telling the server that unless core.js is specifically registered by some control, it should not be referenced. Note that this example was created using BlueBand.master, but other master pages may have a different tag required to reference the ScriptLink control. For example, in default.master, the tag would be SharePoint:ScriptLink instead of SharePointWebControls:ScriptLink. The correct tag will be referencing the Microsoft.SharePoint.WebControls namespace, and looks something like this:

<%@ Register Tagprefix="SharePointWebControls" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

4. Create a new binary based on the code in Appendix A, and set the version to “1.0.0.0”. In my example, this new binary is called PerfTools.dll.

The purpose of this code is to tell the server that if the user is not anonymous, we do want to specifically register core.js. We do this because by default many authenticated users will have access to the Site Actions menu, which requires core.js, while anonymous users do not. Your scenario may require that you suppress core.js under different circumstances, and if so, this is the code to change. Please note that the OnInit method will be executed any time the page is loaded, so you will want to ensure that you do not add any code which would adversely impact the throughput on the server. Accessing the current SPListItem, for example, will most likely incur a round trip to the SQL database.

5. Add PerfTools.dll to the GAC on the server.

6. In the web.config file for the server, add this line to the set of SafeControls (but with the correct PublicKeyToken):

<SafeControl Assembly="PerfTools, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3ec1cbf2475be08c" Namespace="WebControls" TypeName="*" Safe="True" />

7. In ArticleLeftNoCore.aspx, add a tag to register the new binary. It will look something like this (but with a different PublicKeyToken):

<%@ Register TagPrefix="PerfTools" Namespace="WebControls" Assembly="PerfTools, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3ec1cbf2475be08c" %>

8. On the line following the markup from Step 4, add the following markup: <PerfTools:RegisterCoreWhenAuthenticatedControl runat="server"/>

9. Copy CorePreLoad.aspx (file content in Appendix B) to the _layouts directory on the server.

The markup in this file references a single function in core.js, and will download core.js before executing it.

10. In the master page used by the site, add a new placeholder in the markup after the </form> tag and before the </body> tag that looks like this:

<asp:ContentPlaceHolder id="PlaceHolderBottomIFrame" runat="server" />

This is necessary because the IFrame we are about to add can not be inside the Form tag, otherwise the page will break when a postback is executed.

11. In ArticleLeftNoCore.aspx, at the end of the file, add markup that looks like this:

<asp:Content ContentPlaceholderID="PlaceHolderBottomIFrame" runat="server">

<iframe src="http://blogs.msdn.com/_layouts/CorePreLoad.aspx" style="display:none"/>

</asp:Content>

This will reference CorePreLoad.aspx in such a way that everything else on the page is displayed before it gets loaded and serves its purpose (which is to download core.js).

12. The page layout should now be currently checked out to whoever is editing it in SPD. At this point it can be checked in, published, approved, or whatever you need to make it live.

13. Create a new page using ArticleLeftNoCore.aspx as the layout. It is ready for use. When anonymous users browse to it, core.js will not need to be downloaded before they can begin interacting with or reading the page. (If you create two identical pages, one with ArticleLeft.aspx as the layout, and the other with ArticleLeftNoCore.aspx as the layout, you should see that one references core.js while the other does not.)

14. Ensure that no controls on the page are broken for anonymous users due to missing scripts. Test the page well, and if there are any controls which fail to work for anonymous users because core.js is missing, they must be removed from the page itself or from ArticleLeftNoCore.aspx. The assumption of the optimization is that this special page has been created which does not require core.js because nothing on the page requires it.

15. Ensure that core.js does continue to appear on other pages in the site. If core.js is now missing from other pages aside from the one we have just created, you can be sure problems will follow. Browse various other pages and examine the markup to see that core.js is referenced on the page.

You will know that our optimization is working properly because when you browse to the new page with an empty browser cache as an anonymous user and view the page source, you will not find a reference to core.js. When you look in your cache, however, you will find that core.js has been downloaded from your server. Other pages in your site will continue to reference core.js as usual.

Sterling Crockett, Software Design Engineer

SharePoint Web Content Management

Appendix A: RegisterCoreWhenAuthenticatedControl

using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.Text;

using System.Web;

using System.Web.UI;

using System.Web.UI.WebControls;

using Microsoft.SharePoint;

namespace WebControls

{

[DefaultProperty("Text")]

[ToolboxData("<{0}:RegisterCoreWhenAuthenticatedControl runat=server></{0}:RegisterCoreWhenAuthenticatedControl>")]

public class RegisterCoreWhenAuthenticatedControl : WebControl

{

protected override void OnInit(EventArgs e)

{

if (HttpContext.Current.Request.IsAuthenticated)

{

Microsoft.SharePoint.WebControls.ScriptLink.RegisterCore(this.Page, true);

}

base.OnInit(e);

}

Appendix B: CorePreLoad.aspx

<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

<html>

<head>

</head>

<body>

<SharePoint:ScriptLink name="core.js" runat="server" />

DisableRefreshOnFocus();

</script>

</body>

</html>

Building a detached page that does not reference core.js (but downloads it while the page is being viewed thereby optimizing response time)

ecmblog — Wed, 07 Feb 2007 09:21:00 GMT

[Update 02/21/2007: VERY IMPORTANT -- the optimization technique described below may introduce an undesirable caching side effect. An updated optimization technique using a new page layout has been posted here.]

If you’ve implemented or are planning to implement a Internet facing website, you are probably exploring all avenues to make it more responsive to users and visitors. For some users – particularly those with low-bandwidth or high-latency connections – the very first page load of a site can take a long time because of all the resources which need to be downloaded along with the page markup itself. Although these resources are often shared between pages and cached on the client, the first page load can be painfully slow.

In MOSS 2007, it is possible to defer the downloading of some of this content until *after* the user sees the page. In this way, the page is rendered much more quickly, while the user’s experience of interacting with the site is not negatively impacted.

In this blog entry, I will describe how you can modify a specific page within your site (in this example, the root homepage) and remove core.js from the list of resources that must be downloaded before the page can render for anonymous users. Because the core.js file is about 54 KB in its compressed form, doing this can enable the page to render as much as 10 seconds faster for users on a 56 Kbps modem connection. Once the user is reading the page, core.js will download in the background.

By default, all pages in MOSS 2007 contain a reference to core.js. In many places, this file is critical, such as where the Site Actions Menu is shown. There are also some instances, however, when core.js is unnecessary. My performance tuning tip makes it possible to delay downloading core.js by certain users on a specific page. It does not matter whether the user is anonymous or authenticated; core.js will still be downloaded to the browser. The distinction is that for authenticated users, it will be downloaded before the page is readable, while for anonymous users it will be downloaded after the page is readable.

Before I continue, let me set some expectations. This is *not* an officially supported optimization, but it puts the ability to fine tune in the hands of the site administrator, who must assume the burden of ensuring that the site works as expected afterwards. This does not remove core.js from the entire site -- just from a single page, and this page must not have anything that requires core.js (otherwise, it will obviously break). For example, the SharePoint Menu control, if required for anonymous users, would not function on this page.

For starters, you need to do three things:

· Ensure that the Site Master Page is different from the System Master Page. This information can be found by browsing to the URL http://<yourservername>/_Layouts/ChangeSiteMasterPage.aspx. If you observe that the Site Master Page and the System Master Page are referencing the same file, this optimization will not work for you; this optimization requires that the Site Master Page use a different file. Example pages that use the System Master Page are /_layouts/Settings.aspx, and in general, any pages in the _layouts directory.

· Ensure that there are no controls in the Site Master Page, which will be visible by anonymous users and which require core.js but do not register it. This optimization will suppress core.js only for anonymous users, and only on a single page, which means that authenticated users will still get core.js by default. If you modify the code referenced in Step 5 below to suppress core.js for more than just anonymous users, you will need to take this into account at the Site Master Page level as well.

· Ensure that the Site Master Page does not have any ScriptLink controls, which register core.js. The goal of this exercise is to create a single page, which suppresses core.js, even though it would have been registered by the SPWebPartManager under typical circumstances.

Having satisfied the above criteria, you can now be confident that the site is ready for this optimization.

1. Create the page, which is not to reference core.js. We’ll call it NoCore.aspx, but in your case, default.aspx might be more appropriate since that’s the default Home Page for your site.

2. In SharePoint Designer, navigate to NoCore.aspx in the tree hierarchy, right click, and select “Detach from Page Layout.” This will have the effect of converting NoCore.aspx to an “untemplatized page.” What this means is that while it is still subject to the site wide Master Page, its markup is no longer governed by the layout from which it was created, and you will be able to update the markup as you see fit.

3. In SharePoint Designer, Edit NoCore.aspx.

4. Inside the tag with ID PlaceHolderAdditionalPageHead, Add the following markup: <SharePointWebControls:ScriptLink runat="server"/>

<%@ Register Tagprefix="SharePointWebControls" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

5. Create a new binary based on the code in Appendix A, and set the version to “1.0.0.0”. In my example, this new binary is called PerfTools.dll.

The purpose of this code is to tell the server that if the user is not anonymous, we want the page to specifically register core.js. We do this because by default, many authenticated users will have access to the Site Actions menu, which requires core.js, while anonymous users do not. Your scenario may require that you suppress core.js under different circumstances, and if so, this is the code to change. Please note that the OnInit method will be executed any time the page is loaded, so you will want to ensure that you do not add any code which would adversely impact the throughput on the server. Accessing the current SPListItem, for example, will most likely incur a round trip to the SQL database.

6. Add PerfTools.dll to the GAC on the server.

7. In the web.config file for the server, add this line to the set of SafeControls (but with the correct PublicKeyToken):

<SafeControl Assembly="PerfTools, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3ec1cbf2475be08c" Namespace="WebControls" TypeName="*" Safe="True" />

8. In NoCore.aspx, add a tag to register the new binary. It will look something like this (but with a different PublicKeyToken):

<%@ Register TagPrefix="PerfTools" Namespace="WebControls" Assembly="PerfTools, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3ec1cbf2475be08c" %>

9. On the line following the markup from Step 4, add the following markup:

<PerfTools:RegisterCoreWhenAuthenticatedControl runat="server"/>

10. Copy CorePreLoad.aspx (file content in Appendix B) to the _layouts directory on the server.

The markup in this file references a single function in core.js, and will download core.js before executing it.

11. In the master page used by the site, add a new placeholder in the markup after the </form> tag and before the </body> tag that looks like this:

<asp:ContentPlaceHolder id="PlaceHolderBottomIFrame" runat="server" />

This is necessary because the IFrame we are about to add can not be inside the Form tag, otherwise the page will break when a postback is executed.

12. In NoCore.aspx, at the end of the file, add markup that looks like this:

<asp:Content ContentPlaceholderID="PlaceHolderBottomIFrame" runat="server">

<iframe src="http://blogs.msdn.com/_layouts/CorePreLoad.aspx" mce_src="http://blogs.msdn.com/_layouts/CorePreLoad.aspx" style="display:none"/>

</asp:Content>

This will reference CorePreLoad.aspx in such a way that everything else on the page is displayed before it gets loaded and serves its purpose (which is to download core.js).

13. The file should now be currently checked out to whoever is editing it in SPD. At this point it can be edited, checked in, published, approved, or whatever you need. It is ready for use. When anonymous users browse to it, core.js will not need to be downloaded before they can begin interacting with the page.

14. Ensure that no controls on the page are broken for anonymous users due to missing scripts. Test the page well, and if there are any controls which fail to work for anonymous users because core.js is missing, they must be removed from NoCore.aspx. The assumption of the optimization is that this special page has been created which does not require core.js because nothing on the page requires it.

You will know that the optimization is working properly because when you browse to it with an empty browser cache as an anonymous user and view the page source, you will not find a reference to core.js. When you look in your cache, however, you will find that core.js has been downloaded from your server. Other pages in your site will continue to reference core.js as usual.

I hope that you found this optimization tip useful. Leave a comment here if you have any questions or suggestions for other ways of improving page load performance.

Sterling Crockett, Software Design Engineer

SharePoint Web Content Management

Appendix A: RegisterCoreWhenAuthenticatedControl

using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.Text;

using System.Web;

using System.Web.UI;

using System.Web.UI.WebControls;

using Microsoft.SharePoint;

namespace WebControls

{

[DefaultProperty("Text")]

[ToolboxData("<{0}:RegisterCoreWhenAuthenticatedControl runat=server></{0}:RegisterCoreWhenAuthenticatedControl>")]

public class RegisterCoreWhenAuthenticatedControl : WebControl

{

protected override void OnInit(EventArgs e)

{

if (HttpContext.Current.Request.IsAuthenticated)

{

Microsoft.SharePoint.WebControls.ScriptLink.RegisterCore(this.Page, true);

}

base.OnInit(e);

}

Appendix B: CorePreLoad.aspx

<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

<html>

<head>

</head>

<body>

<SharePoint:ScriptLink name="core.js" runat="server" />

DisableRefreshOnFocus();

</script>

</body>

</html>

Customizing the WSS 3.0/MOSS 2007 Menu Control -- MossMenu source code released

LLiu — Sat, 02 Dec 2006 20:37:00 GMT

(Cross-posted from the SharePoint Team Blog.)

The AspMenu class that ships with WSS 3.0 (and by extension MOSS 2007) is nearly identical in behavior to ASP.NET 2.0’s Menu class (as the name implies). AspMenu derives from Menu and adds tweaks to work around a few reasonably well known annoyances and provides improved highlighting support.

Unfortunately, this class was marked sealed and is therefore not eligible to be used as the base class for derived types. Effectively, this means that customers cannot inherit the additional functionality of the AspMenu class when trying to provide further customization of the menu.

We realized this problem too late in the release process and were unable to remove the sealed marker from the AspMenu class that ships with WSS. However, we are instead providing the source code for that class here (as an attachment to this blog entry) under the name MossMenu.

Note: MossMenu is provided as is and will only work on sites built with WSS 3.0 or MOSS 2007. MossMenu relies on some JavaScript which has been included along with the C# source. This is really just for completeness’ sake [aside: some trival about the use of the apostrophe for the possessive forms of nouns] as this script is automatically included on most pages through the core.js script include reference.

Issues with the ASP.NET 2.0 menu, which have been worked around:

1) If the mouse pointer happens to be hovering over a menu item that exposes a fly-out as the page is loading, it is possible that an error dialog will appear stating: "Internet Explorer cannot open the Internet site, Operation aborted" and a blank page will be shown upon clicking OK. It seems that the problem arises from attempting to append to the DOM before it is properly initialized.

2) If SSL termination is employed on a site with a menu, users will be greeted with “This page contains both secure and nonsecure items. Do you want to display the nonsecure items?” when hovering over a menu item which exposes fly-outs. (http://support.microsoft.com/?id=910444)

3) In right-to-left locales, the fly-out indicator arrow still points from left-to-right.

Improvements to default highlighting behavior of ASP.NET 2.0 menu:

· When hooking the menu up to a SiteMapProvider through a SiteMapDataSource, the menu automatically highlights the node that matches that returned by the provider’s CurrentNode property. However, if the particular node returned by CurrentNode is not shown by the menu nothing will be highlighted at all. The improved behavior determines if there is an ancestor of the current node which is displayed in the menu and highlights this node instead.

Hope this helps.

Chris Richard, Software Design Engineer, WCM Features