Introduction
to the Minimal Download Strategy (MDS) – SharePoint 2013
As we all aware that Inter web is
based on a request-response approach where you request a page and get a
response back. The approach is the same whether we update the whole page or portions
of it. The last decade we've seen smart approaches working around this
"problem" using DHTML, JavaScript, AJAX, and UpdatePanels. Up until
now SharePoint (out-of-the-box) has not been that efficient on this, even
though SharePoint 2010 did some improvements. Most often the whole page has
been reloaded for each and every action; this of course affects all end-users
and the perceived performance of SharePoint. But now, with SharePoint 2013, we
have a whole new paradigm thanks to the Minimal Download Strategy – MDS
Minimal Download Strategy in
SharePoint 2013 improves rendering performance when browsing content where
large parts of the page do not change providing a more fluid navigation
experience. For example when navigating between a site’s home page and Shared
Documents page only the content that has changed between the source and
destination page (controls and placeholders in the content area) is downloaded
and the URL subsequently updated where the chrome is persisted.
The Minimal Download Strategy is
by default enabled on Team sites, Community sites and a few others in
SharePoint 2013. All pages for that site are rendered "through" the /_layouts/15/start.aspx
page. This page is responsible for loading pages from the site using the MDS.
The start.aspx page has a specific JavaScript object asyncDeltaManager
(defined in start.js). Basically it parses the URL, looks for the # sign and
takes the path following that and dynamically loads that page.
Subsequent requests to pages are
dynamically loaded through the asyncDeltaManager object. Once a link is clicked
it will invoke a method in the JavaScript object which creates the MDS URL and
appends the query string parameter AjaxDelta=1. A request is created and
downloaded asynchronously and only the "delta" is returned to the
client and assembled and rendered using JavaScript.
Enabling or disabling MDS on a site
First of all what sites do have
the MDS enabled by default? MDS is actually a SharePoint feature (Name;
MDSFeature, Id: 87294C72-F260-42f3-A41B-981A2FFCE37A) which is Web scoped.
Some of SharePoint 2013 Site Templates has this feature stapled (for instance
Team, Community, Wiki, Projects, App and Blog sites). The feature is very
straightforward - it toggles the EnableMinimalDownload
property of the SPWeb
object. So you can quite easily yourself turn it off using code (server side or
CSOM!!) or PowerShell. Of course you also use the Site Settings > Site
Features to turn it on or off as well. The MDS is not enabled on publishing
sites and is not compatible with publishing sites.
Requirements for MDS
Except enabling MDS it is
required for the MDS to work there is one control that must be placed in the
master page - the AjaxDelta
control. It should be added to the head section of the master page. This
control is responsible for a couple of things. If the page is a start/home page
it will clear all controls and make sure that the page is loaded fully and
registers the correct scripts.
Ajax Delta
What this AjaxDelta
control does is to only download to the client (browser) what has been changed
since the previous download. If nothing has changed, nothing is downloaded Ajax
Style.
Following are the AjaxDelta controls that are available in the
Master page.
1.
DeltaPlaceHolderAdditionalPageHead
2.
DeltaSPWebPartManager
3.
DeltaSuiteLinks
4.
DeltaSuiteBarRight
5.
DeltaSPNavigation
6.
DeltaWebPartAdderUpdatePanelContainer
7.
DeltaWebPartAdderUpdatePanelContainer
8.
DeltaTopNavigation
9.
DeltaSearch
10.
DeltaPlaceHolderPageTitleInTitleArea
11.
DeltaPlaceHolderPageDescription
12.
DeltaPlaceHolderLeftNavBar
13.
DeltaPlaceHolderMain
14.
DeltaFormDigest
15.
DeltaPlaceHolderUtilityContent
How is the delta pages
generated?
One of the key things in the MDS implementation is that SharePoint
2013 contains a new Page class - the DeltaPage.
This page class is the key to generating the full pages or just the deltas.
Fortunately the common pages such as WebPartPage, WikiEditPage,
UnsecuredLayoutsPageBase, LayoutsPageBase etc. are inheriting from this page.
So most of the out-of-the box pages works and custom application pages as well.
This page class is quite smart it can handle when MDS is not enabled (i.e.
default rendering) and when MDS is enabled. When MDS is enabled for the site
this page is responsible for creating the delta response. The DeltaPage
is also responsible for handling exceptions such as when the master page is different
(another one or a new version). Every delta request sent using the asyncDeltaManager
has a specific request header - the X-SharePoint header. This header contains
information about the master page, the language and if the page is in
read-write or read-only mode.
This header is important since it
contains the master page, the version of the master page etc. and SharePoint uses
this to determine whether to do a full reload (if the master page has changed)
or not. So if you’re working on a master page, be prepared for full reloads of
the page, at least the first time you request a page using the modified master
page.
The PageRenderMode control
There is one control called PageRenderMode that can be used on a master
page, web part page or page layout. This control has one property called RenderModeType which can have one of two possible values; Standard
or MinimalDownload. If the control is placed on a page and have the
property set to Standard – it will prohibit the page from being rendered using
MDS. If the control is not present or if it’s property is set to
MinimalDownload it can participate in MDS rendering. So this control can be
used on specific (master) pages to prohibit MDS.
Note: if you’re using
the Design Manager to generate master pages, this control will automatically be
inserted into the generated artifacts .Another gotcha here is that even if you
have the PageRenderMode control set to MinimalDownload whenever the publishing
features are enabled and you have the ribbon on the page, specifically when
using the Publishing Ribbon in your master page, SharePoint will automatically
inject, during runtime, the PageRenderMode control with the property set to
Standard.
MDS compliant controls
If you upgrade a SharePoint 2010
site with custom Web Parts or controls, you will soon realize that the upgraded
Webs are not rendered using MDS - even if you update the EnableMinimalDownload
property on the SPWeb object. This is due to the reason that the DeltaPage
checks all controls present on the page for a specific attribute - the MdsCompliantAttribute.
This is an attribute that you can set on a class or on an assembly. If any of
the controls present on a page does not have this attribute nor has the IsCompliant
property set to false it will not render any delta for that page.
To make your own controls MDS
Compliant the classes should look like this:
[ToolboxItemAttribute(false)]
[MdsCompliant(true)]
public class MDSTest : WebPart
{
protected override void CreateChildControls()
{
this.Controls.Add(new LiteralControl("MDS is enabled on the site:" +
SPContext.Current.Web.EnableMinimalDownload));
}
}
Or, you could add the
MdsCompliant to the assembly instead of to each class.
The
MdsCompliant attribute is set on the whole Microsoft.SharePoint.dll assembly,
but not on the Microsoft.SharePoint.Publishing.dll assembly. This means that
all the Field Controls, used in page layouts, are not MDS compliant – which
means no MDS on publishing sites.
Note: MdsCompliant attribute
does not work in the Sandbox!!! So adding a Sandboxed Web Part to a page
disables MDS for that page, period