Minimal Download Strategy in SharePoint 2013

A while back I tweeted briefly that I found something called Minimal Download Strategy framework in the SharePoint 2013 protocol documentation. Needless to say, I wanted to figure out what it is, so I researched a bit and wrote about it in the second issue of the SharePoint 2013 Beta series.

Here’s what I wrote:

I mentioned in the previous issue that interface and client developers will get far more tools in their shed in SharePoint 2013. One of these is the minimal download strategy framework (MDS).

This is a very interesting technology for developing web pages that are responsive and take far less bandwidth than full pages.

Consider this scenario: You have an application with perhaps 15 different pages where most of the pages (navigation, header, footer, and so on) are more or less similar.

Today, even though most of the content is the same for all of the pages, you still need to download the full pages every time you load a new page. For SharePoint, that’s a burden, because pages are quite heavy with tons of CSS, behind-the-scenes scripts, view states, and so on. In fact, a default home page in a SharePoint 2010 team site is 675 kb large

Note: Thanks to James Love for figuring the page size out for me. I didn’t have a lab at the time of this writing.

The image below shows a typical page and its components, with the grey areas being similar across multiple pages.

SharePoint 2013 Minimal Download Framework

Wouldn’t it be better to simply load only the changes from one page to the next? In many pages, the changes from one page to the next may be just a kilobyte or two of text, saving literally hundreds of Kb of bandwidth on every page hit. Loading only those changes would make your network guys very happy.

Well, that’s exactly what MDS tries to do. What the MDS does is that it allows users to load only what changes between pages. This drastically reduces page load time and speeds up responsiveness for the entire application.

The way this technically happens is that users navigate to a start page (start.aspx), which accepts as its parameters the URL of a base page (for example page1.aspx). When the user navigates to the next page (for example page2.aspx) only the changes between page1.aspx and page2.aspx are loaded and sent to the client. The start.aspx page is responsible for updating the sections of the pages that change.

Now, to seasoned web developers, this won’t come as a great new innovation. After all, we’ve had AJAX for many years, including in Microsoft’s own ASP.NET framework.

However, what may be innovative is that the partial loading seems to be largely automatic. Making partially loading pages possible in other frameworks and platforms may require lot of work. Perhaps the greatest benefit will be in an easier approach or possibly even a fully automatic partial page loading.

</end excerpt>

Disclaimer: Everything about SharePoint 2013 is speculation at this point. Don’t make important decisions based on preliminary speculation. If you do, you may find yourself in trouble, such as, but not limited to, your spouse finding lipstick on your shirt collar (applies to both men and women).

If you still want to get the insights into what’s likely coming in SharePoint 2013, there’s no better way than subscribing to the SharePoint 2013 Beta series for $14.95.


Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Pin It

Published by

Bjørn Furuknap

I previously did SharePoint. These days, I try new things to see where I can find the passion. If you have great ideas, cool projects, or is in general an awesome person, get in touch and we might find out together.

12 thoughts on “Minimal Download Strategy in SharePoint 2013”

  1. How heavy is this on the server?

    I assume the architect is:

    XMLHTTPRequest -> Server renders page/Compares page/Waxes on and off -> Obtains relevant portion of page by id or other means -> returns as text -> client side script updates viewstate/jazz

    Not terrible heavy all things considered, but what’s the real functional impact? I know for my part I do a similar thing with $.load(url,{ID: “value”, target: value},function(result){ $(“#”+target”).html(result);});

    Pretty exciting in lieu of MVC framework support.

  2. Why would anyone want to order anything from this guy when he hadn’t even been able to support his current publication. In the last year he hasn’t put out one publication.

    1. Interesting fact, anon…

      Of course, over the previous 12 months, I’ve written and published three books, including the 200+ page SharePoint 2013 Beta series. So, your statement is essentially infinitely wrong.


  3. Pingback: SharePoint Blog - René Hézser - What is the _layouts/15/start.aspx in SharePoint 2013

Leave a Reply

Your email address will not be published.