SharePoint customizations are built using client-side techniques. Theoretically, they should have no performance impact on your server because they run in the browser. But is that indeed the case?
Extending SharePoint today
In the past, when extending SharePoint, we would build solutions using managed code, and deploy it to the SharePoint farm. In the cloud, where the majority of organizations are today, this is hardly possible. To make better use of available resources, multiple organizations share the same infrastructure. Any failure in code deployed by one organization could have a negative impact on other organizations using the same infrastructure. So to guarantee the high quality level of their service, Microsoft doesn’t allow deploying managed code to Office 365. Instead, organizations can use client-side development models, to extend SharePoint beyond what’s possible out of the box.
Fact: SPCAF facilitates client-side development models when running a code analysis.
One of the things that are typical to client-side solutions, is that the scripts that make up the solutions load on runtime in the web browser. The page contains the URL where the scripts are hosted, and when it loads, the web browser downloads these scripts. And it’s exactly here when things can go wrong.
How fast your customizations load
The performance of your intranet depends on a number of factors. One of them, is how quickly the web browser can download and load scripts. As more and more elements on the page are built dynamically in the browser, until these scripts are loaded, your users will see nothing but a blank page. And while the speed of your internet connection plays certainly a role, it’s not the only thing that can make or break the great user experience of your intranet.
When users load your intranet the first time, they need to download all scripts on the page. Depending on how your network is configured, they would be downloading scripts directly from where they’re hosted or from a proxy server in your network. You’re absolutely right thinking, that downloading files from a local proxy is significantly faster than downloading them from the internet.
When downloading files, there are a few important details that make a big difference in how fast they load in the browser. Small files load faster than big files, so if the scripts are compressed, they will load faster than their raw versions. Also, if the server hosting scripts supports HTTP/2, the web browser will be able to download small files quicker than if it was using HTTP 1.1.
The next time your users come to the intranet, they could reuse scripts they have downloaded previously. But they can do this only if the caching headers have been configured correctly. If not, files will either expire too frequently or not be cached at all, forcing users to wait for the scripts to be downloaded each time they use the intranet.
Will the scripts used in customizations slow down your intranet
What we’ve just discussed might seem like a lot, especially if you would have to check it manually. If your organization is using solutions built on the SharePoint Framework, things might be even harder. The reason is that you would have to either deploy the packages on a test server and analyze how they work or break them open and analyze their code to get the full list of details for the loaded scripts.
Of course you don’t have to check the quality of the servers hosting the scripts used by your solutions. But the last thing you want, is your users to complain that your intranet is slow. The good news is that if you’re using SPCAF, you don’t have to do it manually.
Check performance of your scripts using SPCAF
When analyzing SharePoint Framework solutions using SPCAF, it will download all scripts used by the customization and analyze how they are served. If loading any of these files could have a negative impact on the performance of your intranet, SPCAF will warn you about it, telling you exactly which script and why could lead to a poorer user experience on your intranet.
_SPCAF warning about a JavaScript file not being cached_
So what about your customizations: will any of them slow down your intranet?
