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