The Effect of SharePoint 2013’s Minimal Download Strategy (MDS)

More and more captivating web-based user interfaces require additional logic and processing to be passed along to the browser. Fortunately, Chrome, Firefox, Safari, and more recently IE have met the task head on – creating more robust and efficient runtimes for these needy wares which are primarily written in JavaScript. Vizit fits that bill. SharePoint 2013 introduces a new feature, the Minimal Download Strategy (MDS), in an attempt to more efficiently manage these browser resources. MDS has both pros and cons and this blog explores them in the context of how they impact what we do at Vizit.


Since its inception, Vizit has been proud of its zero footprint mentality. Even when it was cool to develop in Flash, we understood that it wasn’t the right tool for the task. Well maybe it was, but it was clearly a dead end. Considering the uprising of mobile and its cold shoulder to those plugin-based technologies, the decision couldn’t have been a more correct one. Even though we don’t use Flash, we still managed to have dynamic user interfaces that work as well as a desktop app while shedding the deployment headaches that typically come along for the ride. As with any design decision, though, this one came with a trade-off: bandwidth required by application resources.

When dealing with web-based interfaces, transferring resources (JavaScript files, CSS, etc) utilize precious bandwidth. Every new feature requires more code to be sent to the browser — increasing our footprint. Bear in mind, Vizit’s footprint has been small and our caching techniques have allowed us to utilize the browser to its fullest and only re-download resources when they’ve been updated due to a software upgrade. This isn’t always the case for third party solutions that use JavaScript. And that is why Microsoft’s Minimal Download Strategy is so important. And even more important than Microsoft adding this into SharePoint is you – the SharePoint community – knowing about it.

At its heart, the MDS does what its name suggests: it reduces the amount of resources your browser needs to download to the bare minimum at a particular moment in time. Instead of loading full pages of data every time you navigate from one Document Library to another, it only loads the parts of the page that need updating – foregoing any resources (JavaScript, CSS, etc) that might be common between the two. While this sounds like a win, it is not a hands-off change. Third party tools must update their software to handle this new world. Without reacting to it, the experience seems to break down as you browse and the inconsistency leads to frustrated end users.


The way it works can be broken down into two basic steps. While I’m not familiar with the exact underpinnings of the entire process, this is based on our experience in adding support for MDS in Vizit. First, when a user clicks on a link in the SharePoint interface, instead of downloading that full page and all of its required resources, it queries SharePoint for what amounts to just the difference. That delta is then sent to the browser where it is processed and all the swapping occurs. Any areas that are no longer relevant are removed and their content is replaced. Second, and probably the more critical of the two for JavaScript solutions, is any and all global variables are deleted as part of the garbage collection process. To avoid this fate, each global variable must be registered when it is first loaded by making a call to Type.registerNamespace(ns) – where ns is the string name of the global variable you don’t want cleaned up. In most cases, if you simply register all of your global variables (and those used by third party, JavaScript toolkits you may be using), you should be fine.

For more complicated solutions, there are some other pieces that you should investigate: window event handlers, and most painfully, the window’s unload event. First, we’ll go over window event handlers in general. Just like all of your global variables being destroyed by the garbage collector, any event handlers you’ve attached to the window object (for example, the window resize event), you’ll need to reattach after the partial page is loaded. It took some digging, but I managed to find an event deep inside the internals of the SharePoint MDS stack that fires whenever a partial page is loaded and cleanup needs to occur. Here’s a code sample for attaching to that event:

asyncDeltaManager.add_endRequest(function() {}
// your code here

SharePoint Thumbnail Previews

I suggest you wrap that in a check for whether the asyncDeltaManager is available, but it might not be necessary for some deployments. In our case, we allow our code to be loaded on non-SharePoint pages where this is neither available nor needed so a simple check to see if (typeof asyncDeltaManager) is “undefined” is enough. Whenever this event fires, you can take the opportunity to re-register any events that may have been destroyed. Vizit also uses this as an opportunity to attach mouseover event listeners to any document format icons that are on the page. One great feature of our product is to display a preview of a document when the user hovers their mouse over the icon next to a given document. Without knowing the page had updated, we would stop working if MDS was enabled.

I’ll get into it more deeply in an upcoming post, but what I consider to be the most controversial of side effects that MDS has on your JavaScript deployment is how it handles window unload events. In the typical life cycle of a page, the window load even fires, the page lives on, the user either closes their browser window or clicks a link to navigate to another page and the window unload event fires. This is a fairly complimentary process. At the beginning, it allows for any setup and configuration, and at the end, it gives the script an opportunity to clean up its memory space to avoid leaks due to closures and be a good citizen, overall. In the world of MDS, unload is fired for every partial page load. This can wreak havoc if the unload handlers are completely destructive (which in many cases they are, intentionally).  Depending on the situation, you may need to remove any unload listeners you’ve got or add complimentary code to the asyncDeltaManager’s endRequest event to pick up the pieces.

In the end, it may take some work to get your solution to operate properly in an MDS environment, but the trade-off is worth it.

Note: Some of the graphics in this post came from the MSDN article on Minimal Download Strategy which can be found here: