SharePoint Performance and Connectivity

SharePoint being such a large platform that it is, is now implemented in small all the way to large enterprises in some setup. Building out an environment whether for an intranet, public facing site or even a simple site for sharing can still suffer from some of the same issues.

If there is one thing I have learned over the years, it is to understand the performance and connectivity elements of the SharePoint solution. This allows for you to set the expectation for end users within the organization. Too many times I have heard the expectation that each page MUST load within X number of seconds like a regular web platform, when in reality though you can achieve this to some degree, the logic design of SharePoint makes it very hard. SharePoint is not a lightweight application and has never professed to be that. It does have great features and can do more things that most Content Management Solutions and Sharing Platforms combined. This can however be its downfall for user adoption and usage.

To help you in setting this expectation the following things can be done:

Each of these things though they look like simple and probably common sense items, often are the root cause of seemingly bad performance or connectivity within a SharePoint environment. So what things can we do within each to help us identify and resolve. Well let’s just talk about setting expectations first.

In a normal SharePoint environment, (using a single Virtual Machine as an Example), the default page of a SharePoint site for the very first load of the day can take quite some time. This is the standard “Just In-time Compiler” issues that we are all too familiar with. As you can see within my environment it took 35 seconds to load an out of the box page:

Of course the next request is then quicker:

Now we all know how to fix this one as it has been a long standing issue, this is done using some kind of warm up process to ensure that the pages are ready. Now let’s take this logic and apply it to a site that is already warmed up and should be fast but the pages are loading slower. I have seen many pages or sites like this, that just take more time to load than expected. Some of this is down to the components, design and often customizations, however the page and site construct does load quite a few components that can cause slowness.

Looking at the loading of my test site you can see the things that are loaded:

If we repeat the process and run it against a regular document library, you can see that even more components are rendered and required.

As you can see the list can be quite extensive and that does not include anything else that might be on the page, such as web parts or even custom components. It does not include any custom branding either. Learning what is normal traffic, expected traffic and then peak traffic is important when trying to work out the real page load times. Looking on the internet, I came across this note from “Hubspot” on page load times.

“HubSpot considers the ideal page load speed for your website's HTML to be less than 1.5 seconds.

If the HTML page load time is less than 1.5 seconds (top 20% of pages on the web), there will be a check-mark indicating no errors with loading the page.

If the HTML page load time is between 1.5 - 5 seconds, there will be a warning message indicating that the page is not loading at an ideal speed.

If the HTML page takes longer than 5 seconds, there will be an error message indicating that the page is taking a very long time to load.”

As you can see with other platforms and solutions, with setting the expectation for page loads to be these times, my vanilla SharePoint site would be displaying an error message about slowness. For me the distinguishing key is their language for “HTML page”. This is where we get to understand and realize that even though that’s what we are outputting, we are still injecting things at the page load time, in order to render that as HTML. SharePoint does work in a different way to most applications that are designed to just be a true Content Management Solution.

This however does not negate the need to worry about designing and implementing the best practices around for web development and styling. What does this mean though? it means we need to be more realistic when coming up with the numbers that we will give out to the organization for page load times. Saying the corporate intranet is going to load in under a second may actually be impossible once the page and site is deconstructed into what each area is doing, components on the page, brand applied along with customizations.

You also have to consider the following items in this calculation too:

There are typically five reasons that cause slow pages or sites in general.

These can cause slowdowns, errors or just make the usage of the site very hard for the end users. For some helpful guidance on page performance visit the TechNet article specifically for this: https://msdn.microsoft.com/en-us/library/office/dn449110.aspx

Using tools such as Fiddler, YSlow and others can help in diagnosing performance issues. A great way to visualize it, is to use the Microsoft Visual Round Trip Analyzer. This allows for a graphical representation of the traffic showing the performance.

The software also returns a score for each section, from JavaScript files to just page loads.

This allows you to see what changes can be made to increase the page and site performance. Outside of just checking the page load times, validating the network performance, a review of the core SharePoint Configuration can go a long way to making sure all things are configured as expected. 

With these reviews completed, you can then as an organization, define what is an acceptable range for load times, network access speeds and overall performance.`