Thursday, 9 May 2019

SharePoint Online: Measuring SharePoint Modern Experience Performance


In this post I'll try to share my experience on how to measure performance of SharePoint Online modern experience and most importantly what you should expect and communicate to your client. Specially, a client that is moving form a fully branded customised on-premises intranet to SharePoint Online Modern Experience.

First, you need to identify what is the metrics you will use to assess the intranet performance and for this post I'll try not to get sidetracked and talk about accessibility and other non-functional aspects of your intranet platform.

There are many metrics that could be used but as we are putting a SaaS platform to the test I will ignore any server related performance metrics as we can't optimise server performance by any means,.
Of course you can always check the x-sharepointhealthscore custom header value and contact Microsoft support if you are not happy with your tenant performance, but for this post I'll focus on client things that is mostly affected by your client machine and browser.


There are many tools that you can use to measure the performance of a website, however if you are using Chrome browser (please don't tell me that you are using edge or worse internet explorer , even Microsoft has given up on them). by launching the developer tool you can easily launch an audit tool which allows you to perform a full audit for the current website. The tool is called lighthouse, that why I decided to stick with the metric which google use to score a website performance:

  • Time to first Contentful Paint
  • Time to first Meaningful Paint
  • Time to interactive 
  • Time to CPU Idle
  • Speed Index
  • Estimated Input Latency


That's good , we can easily execute the audit but how can we automate this? the answer is very simple. the good lads at google has built us a CLI for lighthouse than can be installed using npm , please check the GoogleChrome lighthouse repo for more information on how to install and run it.

In short you will be able to run the following command line which only execute a performance audit

As you can see the script is very simple , I start with getting the URLs of the SharePoint Online pages I want to test from a CSV file which also have the required numbers of runs.

Then I use the lighthouse command flags to ensure that there is not throttling or emulation (--disable-device-emulation --throttling-method=provided) also I'm exporting the audit run output as JSON file in a specific output folder

I also passes the --disable-storage-reset switch to ensure that I can use the browser cache , another flag to mention is --only-categories=performance which only execute the performance related audits


When I started running the report I get an amazing results, however when I looked at the trace using the lighthouse reoprt viewer  I found out that I'm redirected to login page which doesn't have much hence the amazing 100/100 score.


I looked over ways how to pass my login credentials but I found an easy way which is running chrome in debug mode


this will launch a new chrome window , I'll navigate to the SharePoint Online URL and login using my user credentials so this browser session will have my user logged in already. Afterwards, I need to pass the resulted port number when to the lighthouse cli.

It's kinda lazy solution but it worked OK for me but it is definitely better to run chrome headless.

The results

After running the PowerShell script I have a number of JSON files and I want to get the average value for the above metrics, do I need to write another PowerShell script. hmm  I don't think so, I'm a very lazy person. and I have a mongo db instance installed on my laptop. I imported the files to a collection then run the following script to get the average results


To be honest the results for an empty OOTB team Google gave the OOTB team site a performance score of 86/100 which is a cool score but as you might see, it's all about JS execution time and main thread work.


If your client is after an intranet solution with speed index is less than 3 seconds, You might need to consider building your intranet as a loosely-coupled intranet which is a concept that we have discussed here more than 3 years ago, you can check more details in the following post:
http://www.sharepointtweaks.com/2016/01/officedev-the-new-intranet-loosely-coupled-approach.html

If you are happy with the current performance and want to customise SharePoint Online and start building SPFx extensions and webparts. You need to be very careful and very cautious of what you use as every bit of JavaScript will matter and at some point, you will have to tell your client yes I can do this put it will slow your site down.

In the next post I'll list some techniques that helped me from lifting up a 50/100 scored custom SharePoint Online intranet to be comparable as the OOTB  with a score of 86/100.

Till next time