This blog is part of the blog series SharePoint JavaScript Context Development
- Part 1 – SP.Init.js and SP.ScriptUtility
- Part 2 – SP.ScriptHelpers
- Part 3 – Minimal Download Strategy (This post)
- Part 4 – Async Download Manager
- Part 5 – JavaScript Framework Governance
- Part 6 – jQuery vs SharePoint
Note: Parts 3 & 4 are linked. Please read in order.
Taking out the trash
MDS garbage collection. In SharePoint JavaScript, if you leave anything laying around with MDS turned on, you might find it binned. It is for this reason I turn your attention to what actually does this automated garbage collection, the king of the MDS hill the Async Delta Manager.
Welcome to the Async Delta Manager
We all know our acronyms by now, MDS (Minimal Download Strategy), SOD (Scripts on Demand), CSR (Client Side Rendering). However, here is a new one for most of you; ADM the Async Delta Manager. This is the most important component of MDS. While MDS is the idea behind it all, the ADM is the actual component that performs page transitions while minimising the amount of content downloaded.
The reason I introduced the classes in the first two parts of this blog series, was because ADM is also built in Script# (See part 2 of this series) but from what we can see by looking at the code, it has not been obfuscated meaning the only clue we have as proof is the $ symbol in the method name. This means it can be quite difficult to tell what is actually happening when we transition a page in MDS with our JavaScript variables. So, I will endeavour to make this blog post as complete but as simple as possible so that you can truly understand how you can benefit from working with MDS. This reasoning is why you shouldn’t be turning MDS off, but learning to develop with it. If you are in the SharePoint context it is your tool for performant pages, and this one simple key fact is why this and the following post can turn your intranet from being a failure into a success.
A birds eye view
You are on the home page, and you want to move to another content page. As I’m sure you are aware the MDS story starts with start.aspx. What you may not know is that it has a JavaScript file START.js which is the other half of the equation. The desired URL is sent into the MDS as an in page anchor, which is then picked up by the script, and the appropriate page is fetched from the server. The content comes back and at this point the browsing state of SharePoint is reset to default.
The components that are reset:
- The ribbon is minimised again and reset
- The notifier area is reset
- A fake window.unload event is created
- _spBodyOnLoadFunctionNames and _spBodyOnLoadFunctions are emptied
- SOD is reset
- Update panels are reset
- Form post backs are reset and will re-fire were necessary
- SPAnimations are reset
- Telemetry engine is reset
- All non-registered global variables are deleted (But not declared methods)
- Document body onclick is reset
- Additional styles are removed
- The page bootstrap is reinitialised (init.js is reloaded completely)
- All page commit/submit controls are reset
- Then everything new required is loaded
What makes this reload exciting though, is that all the components that are required to rebuild the page are loaded asynchronously and at a fraction of the download time to a full page refresh.
Let’s compare this using my 365 tenant:
| Requests | Payload size | Average time | |
| Initial page load (Or without MDS) | 56 | 3.2MB | 13.9s |
| MDS Page transition | 8 | 140.79KB | 261ms |
This is a bare minimum example for both pages. It is an empty team site, going to site settings in essences moving from one content page to another.
We can multiply this out to our user base and determine quite quickly that we could potentially putting a large strain on our network by turning it off, and more importantly perhaps turning off users from using SharePoint.
The second point for me is the most important. I am a registered Information Architect in the UK, and I have a Diploma in Systems Analysis, so listening to users and looking at how they work is important to me. It has to be apparent that we live in the age of mobile phones which are basically hand held computers. If something doesn’t happen in a couple of seconds then we tend to get fed up with what we are using. If you want to read through statistics that apply, I find the article from the guardian “Say it quick, and say it well” applies well to users in an intranet portal scenario. In here they describe how even a page speed increase of 30% of your original can dramatically reduce the number of users leaving the site and not wanting to go back. Reducing this to under Googles recommendations for page speed of under 400ms. MDS does this. It fixes this goldfish attention span issue of our users, and addresses our need to be a rush.
I have given you the background, and hopefully convinced you to read more about MDS. So in the next blog post I tell you how to tame the beast and work with ADM and create MDS compliant code.
