SharePoint 2013 - Introduction to the Minimal Download Strategy (MDS)

Tags: SharePoint 2013, Web Parts


SharePoint is based on a very rich web interface containing lots of moving parts and lots of customizable areas. As you know the Interwebz is based on a request-response approach where you request a page and get a response back. The approach is the same whether you update the whole page or portions of it. The last decade we've seen smart approaches working around this "problem" using DHTML, JavaScript, AJAX, UpdatePanels, you name it. Facebook, which also contains a very rich and dynamic interface, has been excellent in making a dynamic web interface minimizing the amount of data downloaded for each user interaction and in this way also increasing the perceived performance.

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. In this post I will walk you through some details of MDS, how to leverage it in your own customizations and how to successfully adapt your current and future customizations to MDS.

Note: this article applies to SharePoint 2013 Preview

Note: article has been updated per 2012-08-16 with some more nice details..

The Minimal Download Strategy (MDS) - an overview

The Minimal Download Strategy is by default enabled on Team sites, Community sites and a few others in SharePoint 2013. Once this feature (and it's also a Feature, notice the capital F, we'll get back to that later) all pages for that site is 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.

How does it really work?

Let's dig one step further down and see what really happens and detail out some of the moving parts.

Enabling or disabling MDS on a site

[Edited 2012-08-16] 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 (as I understand it) not compatible with publishing sites, there are a couple of reasons for this, continue to read for more information

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.

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 hopefully your custom application pages as well. This page class is quite smart it can handle when MDS is not enabled (ie 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.


[Added 2012-08-16] This header is important since it contains the master page, the version of the master page etc and SharePoint uses this to determine weather to do a full reload (if the master page have 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

[Added 2012-08-16] 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.

<SharePoint:PageRenderMode runat="server" RenderModeType="MinimalDownload" />

A word of caution here, 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 PublishingRibbon in your master page, SharePoint will automagically inject, during runtime, the PageRenderMode control with the property set to Standard.

How does the delta response look like?

The response returned to the asyncDeltaManager has a specific format which very much resembles how ASP.NET UpdatePanels work. Each control that should be re-rendered on a page has it's HTML rendition and all these renditions are separated by a specific token which has the format:


The Guid is unique (which is the purpose of guids :-) and the asyncDeltaManager retrieves the current token from the response header called deltaBoundary.

This image shows a snippet from the IE Network monitor.


After all deltas, at the end of the response, is another encoded set of data.

More delta stuff

This data tells what each delta boundary block is intended for and has the following format:

content length|type|id|data|

Type identifies what kind of delta data it is; controlDelta is a standard control, pageTitle the title of the page, pageRedirect a page redirection etc. There are about ten more different types. Id identifies the control identifier and data, is the data...

The asyncDeltaManager takes all this information and assembles the page, so it all looks fast and neat for the end users.

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

public class MDSTest : WebPart
    protected override void CreateChildControls()
        this.Controls.Add(new LiteralControl("MDS is enabled on the site:" + 

Or, you could add the MdsCompliant to the assembly instead of to each class.

[Added 2012-08-16] The MdsCompliant attribute is set on the whole Microsoft.SharePoint.dll assembly, but not on the Microsoft.SharePoint.Publishing.dll assembly. This is a bummer. This means that all the Field Controls, used in page layouts, are not MDS compliant – which means no MDS on publishing sites.

An important thing here to remember is that the MdsCompliant attribute does not work in the Sandbox!!! So adding a Sandboxed Web Part to a page disables MDS for that page, period.


Whew, quite a long introduction to the Minimal Download Strategy. I hope that you have a better understanding of it by now and that you better know how to possibly troubleshoot any issues with it (or rather your customizations on MDS sites). There are more to discuss on this topic though, but we'll save that for another day. Cheers!


  • Stephane Eyskens said

    That's a great new mechanism and we can indeed see how the overall performance is increased with the OOTB pages. The initial load (full) is not impressive but any subsequent operation (view all site content, navigating to a doc lib etc...) is wayyyyyyy faster than before.

    Wasn't aware of the details regarding the plumbing so thanks for this explanation :).

  • Wictor said

    @Stephane - the interesting thing is that it's only performance improvements due to the reduced amount of data transferred between the server and the client. All controls are executed on the server just as usual. But hey, in the Cloud the can just throw in more metal...

  • Wictor said

    @Ali. I do think that they don't want you to build Sandboxed Web Parts. You should buy into this whole new App model instead.

  • Jaap Vossers said

    Very informative post Wictor. Thank you :)

    I am curious what it means for a control to be "MdsCompliant" i.e. are there certain things that such a control is not allowed to do, or is supposed to do in a certain way? For example, can a MdsCompliant control register js includes using ClientScriptManager? How would any such js include land on the page? Is this all managed by SharePoint?



  • Wictor said

    Jaap, I've searched for answers for that question but not found anything. Using the ClientScriptManager works just fine, that is all handled by the server side engine and the asyncDeltaManager. AFAIK the only thing that this attribute is used for is to check if to fallback to non MDS mode or not.

    You can think in another way as well, it might be just a way from MSFT to annoy the heck out of us when using Sandboxed solutions, since you cannot use this attribute on Sandboxed Web Parts, which means we fall back to non MDS mode :)


  • ekin said

    Hi, I have installed/configured the SharePoint2013 use powershell, but seems something wrong.
    from the event log, I saw "The site /sites/Help could not be create. The following exception occurred:Feature with Id ''87294C72-F260-42f3-A41B-981A2FFCE37A" is not installed in this farm, and cannot be added to this scope.."
    but I use 'Get-SPFeature | findstr MDSFeature', I can see it installed?

    do you know what's wrong here?

  • Mats Levinsson said

    ekin: I did have almost the exact same problem except that in my case the feature was not installed, so for me the solution was easy - just install the feature (Install-SPFeature -path "MDSFeature").

    Have you solved it?

  • FeemurK said

    That Install-SPFeature -path "MDSFeature" tip works.

    I was looking through the ULS Logs and I couldn't find reference to this feature being attempted to be added.

    When i installed the feature, as above, the logs contain the following:
    Feature 'MDSFeature' (ID: '87294c72-f260-42f3-a41b-981a2ffce37a') was already activated at scope 'http://myworklaptop'. No further action necessary for this feature.

    Is this just a bug in the ULS logging for sharepoint 2013 or did i miss something?

    When it failed it would get to the GettingStarted Feature being added successfully and then fail.

    Also, where did you find out that the correlation-id in question maps to the mds feature?

  • Ali said

    How does the asyncDeltaManager knows what was changed? i mean does it uses string compare for the delta sections? is all the rendered HTML sent back to the asyncDeltaManager and it compares the delta boundaries that have the same GUID(string compare) to know if it is changed and then updates the page accordingly?

  • Slava said

    Hi Wictor, thanks for the explanation of MDS.

    In your comment you mentioned that "adding a Sandboxed Web Part to a page disables MDS for that page". This did not work for me.

    I have SharePoint web part at The only way I was able to make in work in SharePoint 2013 is by disabling "Minimal Download Strategy" feature on the site. Otherwise the web part shows nothing in view mode but works ok in edit mode.

    I tried SPContext.Current.Web.EnableMinimalDownload = false; in the code but it does not do anything.

    Is there a way in the code to force MDS to be off?

  • Stuart Pegg said

    It seems MDS isn't currently compatible with Client Template Overrides (at least not those registered for a Custom Field Type).

    They get registered and used at first load, but not for any subsequent navigation calls. This can be reproduced by using MS's own example FavoriteColor CFT found here:

    We currently have an open ticket for this with MS Support. Here's my original forum post:

  • Moutasem Al-awa said

    First of all thanks for this lovely introduction and explanation.

    I did not have a clue of the weird behavior for /layouts/15/start.aspx before this article and now this explains a lot.

    It's worth mentioning that we did something similar to this in SharePoint 2010, as we worked on a stock exchange site which needed to reload data with minimal time, thus the server used to render delta's only.

    A gotcha for this approach is loading java script included in your web part / page, as having MDS enable does not load / execute scripts properly.

    Thanks again for sharing.

  • Arindam said

    In a MDS enabled site, suppose I am accessing "/_layouts/15/ManageFeatures.aspx". So the full url will be like:- "http://siteurl/_layouts/15/start.aspx#/_layouts/15/ManageFeatures.aspx".

    If we want to get the current page url, we use "window.location.href" in javascript.

    But in this case if we use "window.location.href", it will return only "http://siteurl/_layouts/15/start.aspx" instead of "http://siteurl/_layouts/15/start.aspx#/_layouts/15/ManageFeatures.aspx".

    Can you explain how to get the whole url using javascript?

  • Suresh Pydi said

    Very very nice post. Impressed with your post. I wrote my understandings on MDS

    here is the post

  • Lita Elander said

    Terrific article and well written as well.
    Thanks for taking the time to put this down for all to see, it is appreciated.

  • Ashish Mishra said

    Excellent post!! I wonder that this article was written in initial phase of SP 2013 launch and yet it contains so detailed and relevant information. :-)

Add a Comment

AWS Tracker

About Wictor...

Wictor Wilén is a Director and SharePoint Architect working at Connecta AB. Wictor has achieved the Microsoft Certified Architect (MCA) - SharePoint 2010, Microsoft Certified Solutions Master (MCSM) - SharePoint  and Microsoft Certified Master (MCM) - SharePoint 2010 certifications. He has also been awarded Microsoft Most Valuable Professional (MVP) for four consecutive years.

And a word from our sponsors...

SharePoint 2010 Web Parts in Action