This blog is about SharePoint, Office365 and Office Development

Popular Posts

Modern Experience: optimizing the performance of your SPFx components


When building custom SharePoint online solution, there is not much you can do to optimise the server performance, your areas of improvement will be around the basic following items:

  1. Reduce content size (size of images, media you add to the SharePoint Pages)
  2. Reduce bundle size (SPFx solutions)
  3. Optimise calls to SharePoint APIs or any external APIs
  4. Network and Infrastructure optimisation
  5. Client device Optimisation
In this post I'll focus on #2, which  is the things you need to worry about when creating custom SPFx component whether it's an application customizer or single webparts.
  • Measure and monitor your bundle size
Before you try to introduce complexity to your work make sure that you have a problem you need to tackle first, over optimisation is a mistake we all have been guilty of. please revert to my previous post about measuring SharePoint online performance here

So, let's say that you have identified that you have a problem, and this problem is potentially due to a bigger bundle size, common symptom for that is a very high JavaScript Evaluation time  the first step is to try to locate which component is causing your bundle size to balloon up which is pretty straight forward process, one way of doing it is to use https://www.npmjs.com/package/webpack-bundle-analyzer which gives you a nice graphical representation and information for each component size (raw, minified and compressed)


  • Move common dependencies to be "externals"
If you're using a common component or library indifferent webparts, consider moving this into externals so it won't be packaged for every single webpart JS file

  • Don't just use libraries, simple solution might perform better
For instance , imagine you want to display a spinner, and because you are a good SharePoint Developer, you'd love to use the office-ui-fabric-react controls and import the spinner and use it while your webpart fetches whatever content you're after. sounds like a good idea, think again just importing the Spinner introduce almost 1.6M of Javascript code which can be substituted by a simple load of gif. Don't get me wrong if you want to use the react controls package use it but you need to make sure that you use it for more than just a spinner and I'd rather move them to externals and serve it as a compressed (Gziped) size ~ around 200KB
Add caption
  • Reduce font files to the bare minimum
this one is a very handy one, let's say that you're using font-awesome to display some nice looking icons, including the full font files in your bundle adds more than 900KB of payload to your application and to be honest it's not about hosting fonts as externals or not. it's about do you really need the whole font components or you just need like 4 or 5 icons.

there is a full post on this topic here https://blog.webjeda.com/optimize-fontawesome/ and it helped me reduce my font files to be in total ~ 19KB instead of 931KB


  • Use another CDN solution that allows compression 
Office 365 public CDN is good but it's not good enough as it doesn't provide compression, you could easily use Azure CDN endpoint and enable compression, you shouldn't pay much as you are not really delivering heavy weight static contents 


After all of these modifications which doesn't really contribute to a lot of refactoring , I've managed to get a 90/100 score for the SharePoint modern site, which was a huge performance boost