0

Tuning SharePoint Online Performance – Extended

There is a pretty good and straightforward list of do-s and don’t-s on the official Microsoft support page about tuning and optimizing SharePoint Online performance. I am writing this as an addition to that guideline. If you already went through the official guideline and you still are not satisfied with the performance of your solution and you think you can do more, you might want to take into account the things written bellow as well.

*Note – I assume you have an Intranet solution that uses publishing site template and is built for SharePoint Online

Custom master pages and page layouts

One thing that you should bear in mind when developing solutions for SharePoint Online is that the platform changes. A lot. This means that there will be times where you will have to distance yourself from the traditional SharePoint (on premise) development and think twice before using the same paradigms or features in SharePoint Online as well.

A good example of this are custom master pages and page layouts that we are very much accustomed to. Often, when we want to succeed a certain UI or reference static files throughout the whole portal, we use custom master page in combination with multiple page layouts. That might be the way to go with SharePoint on premise development, but in SharePoint Online where the UI changes rapidly, such implementation is not future proof and it can easily become incompatible with the new and modern UI.

So, I would definitely recommend using OOB master pages as well as OOB page layouts.

If you still need to stick to your custom page layouts and you need additional properties to tag your pages, make sure not to add them directly to your page layouts. Instead, use custom content types to associate them with your pages and set them through the “Edit page properties” dialog. This is especially important when using taxonomy and user fields which inherit the »SPFieldLookup« class. Since these types of fields are getting data from sources like the Term Store or Active Directory, they can take a lot of time to be populated with the appropriate data, therefore resulting in slower performance.

DOM manipulations

Not having a master page kind of forces you to use DOM manipulations in order to achieve the desired UI. However, changing the UI on the fly, every time a page loads, can be very dangerous and can result in slow page loads.

If you decide to use DOM manipulations and you need to change the state of the UI by appending or removing certain DOM elements in a loop, do that with document fragments. Create a document fragment, do the required appends to the document fragment then insert the document fragment to the DOM tree. Such implementation will not cause page re-flow each time you append an element and will result in better performance.

Another thing to keep in mind when doing DOM manipulations in SharePoint Online is the fact that certain DOM elements and classes can change with the newer versions of the platform. Your selectors should use the well know SharePoint DOM classes that haven’t changed for ages. Please do not rely your solution on too specific DOM selectors that can be easily replaced/changed in the newer versions.

Code that does not block the UI

If you want to develop solutions for SharePoint Online you have to use JavaScript. JavaScript has a synchronous execution model plus it is single threaded. In other words, your code will execute on the same thread (if not written otherwise e.g. web workers) line by line in the order the code appears. If you have a lot of poorly written custom code and a lot of DOM manipulations that needs to be executed on each page load, it will very much affect your performance. So, think about how you will architect your solution to avoid such situations.

If your solution is consisted of multiple web parts that have their own logic and use internal / external data sources (e.g. SharePoint APIs, etc.) it makes sense to develop them as components. Each component will have its own implementation, will use asynchronous calls to obtain data from SharePoint and will display the data independently from the other components.

If your components share certain features or functionalities, use a component library and make sure you implement common methods in order to achieve maximum code reusability.

Use client side frameworks built on top of JavaScript when building your components. I personally recommend React. It is easy to learn, lightweight and has everything you will ever need.

A simple portal structure

Make sure your portal uses a simple and as flat as possible portal structure. Before making a decision about adding a new site or sub-site make sure that you have enough reasons to do so. Too many site levels can have a huge impact on the performance.

Think about the Intranet portal as an entry point for co-workers to find important information and novelties about the company they are part of. Document sharing and document collaboration or permission trimming based on target groups, should be done through Team Sites or Project Sites not through the Intranet. Such architecture can enable you to decrease the number of sites significantly and make you use pages instead. In return it will improve performance as well.

Navigation

The navigation represents a huge problem in SharePoint Online. There are articles that say that you should avoid structural navigation and use managed metadata navigation, since it works best with SharePoint Online.

My experience with every SharePoint online navigation is sad. It is true, OOB structural navigation is very slow, but managed navigation is very slow as well. In addition managing managed navigation is so painful that I recommend writing your own custom navigation. You can write it as a component as described in the Code that does not block the UI section. In addition make sure to cache it. Truth is, it will not change very often and since it loads on every page, it makes sense to read it from cache. I am talking more about caching in the next section.

Caching data from API calls

One of the most important things when developing for SharePoint Online is to decrease the number of API calls. Therefore, it makes sense to cache the result from the API calls as often as possible. sessionStorage and localStorage are two types of caching mechanisms that you can use to cache your data.

Session storage holds the stored information for a single session (per window or in some browsers per tab).

Local storage does not have an expiration date. If you need to set an expiration date with local storage, you can define another key that will contain the expiration date for a certain item and then do a check every time you need to pull your item from the local storage.

The navigation, footer and any type of data that does not change too often must be cached. As said, you can use one of the mechanisms mentioned above but do not forget that localStorage as well as sessionStorage has limited amount of storage available.

Is it me or SharePoint Online?

In most cases it is probably you. I am not saying that SharePoint Online is especially fast and you are absolutely killing it with your custom code, but you must realize that every customization you are doing (even features like theming, navigation, etc.) will have an impact to the performance. In most cases, the problem will also be in your custom code, but you can use Google Development Tools to find out more about what exactly is going on (ref 1, ref 2). I would recommend Google Development Tools over every other tool for performance analysis.

Biserka Cvetkovska

Leave a Reply

Your email address will not be published. Required fields are marked *