Courtesy of THE Liam Cleary, Solution Architect and Microsoft MVP
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:
- Set Page Load times to a realistic value
- Re-visit Usage Load requirements, get the actual number
- Validate Server performance
- Validate Server to Server communication performance
- Check SharePoint Configuration
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. Read more