Performance Optimising SharePoint Sites – Part 3

In Performance Optimising SharePoint Sites – Part 1 of this series I focussed on some of the first steps you should undertake or consider when embarking on performance optimising your SharePoint site. Performance Optimising SharePoint Sites – Part 2 explored some of the platform-independent techniques available at your disposal while this part of the series will identify some of the SharePoint-specific techniques able to be leveraged.

This is another topic where the information available is quite extensive. In a lot of cases however the information is either spread around or quite targetted so I think there is some value consolidating a lot of these ideas as part of this series.

One aspect of performance optimisation for SharePoint sites I won’t delve heavily into is on the infrastructure and administration side. This isn’t particularly my area of expertise so instead i’ll invite you to read some articles with more appropriate authors including Arpan Shah’s Things to Consider for SharePoint Performance, David Lozzi’s Improving SharePoint’s Performance and Eric Shupps’ 10 steps to optimize SharePoint performance.

Make sure your Objects are Disposed Correctly

It could be considered that this has been done to death and surely no one out there would fall into the trap of incorrectly, or failing to completely, dispose their SharePoint objects – but no performance optimisation article would be complete without at least mentioning it. It’s one of the most serious pitfalls a developer can fall into when developing a SharePoint site. Two main resources exist to steer you clear of this evil; the MSDN articles Disposing Objects for SharePoint 2010 and Best Practices: Using Disposable Windows SharePoint Services Objects for SharePoint 2007 and the SPDisposeCheck tool which can be run over your code to check for potential errors. There really is no excuse to letting these issues slip through the cracks and should definitely form part of your optimisation process.

Perform a Code Review and Ensure Your SharePoint Code is Optimal

Aside from object disposal mentioned above, a number of other code factors exist which can leave your pages rendering in a less than optimal time. A number of blog posts run through a bunch of these including Andreas Grabner’s How to avoid the Top 5 SharePoint Performance Mistakes, Eric Shupps’ SharePoint.Performance: Optimizing Web Parts and Waldek Mastykarz’s Performance of various methods to retrieve one list item. However the best resource i’ve found in regards to writing optimal code is on the MSDN site Developer Best Practices Resource Center – definitely worth your time in parsing through all the information on that site to ensure your code is as optimal as it can be.

Use Caching within your Code

No matter how optimal you eventually make your code, it will still be slower than not having to query the information in the first place. Caching is a great mechanism to allow you to run the query once then retrieve the data from memory on subsequent loads. There’s always a trade off between caching the data for performance and the currency of data – the trick is to find the balance between improving the performance of your site and ensuring the data being displayed is relatively up to date – this could differ on a case by case basis. You can either harness the built-in SharePoint objects which handle the caching for you or cache the objects yourself. Claudio Brotto has a good article on all things caching at SharePoint Internet Sites – Performance Optimization for Data Access which is worth a read.

Make Use of SharePoint’s Built-In Caching Functionality

SharePoint also has other built-in forms of caching that can be harnessed for your site both identified in Claudio’s article above; the Output Cache and the BLOB Cache. There are pitfalls associated with caching and these need to be considered, however caching is one of the most powerful methods of improving the load time of your SharePoint site. For more information on BLOB caching i’d recommend reading Sean McDonough’s Do You Know What’s Going to Happen When You Enable the SharePoint BLOB Cache? – it’s a long but quality post. For Output Caching (and caching in general) have a read of Tobias Zimmergren’s Caching in SharePoint 2010. As a side note particularly for SharePoint 2007 you may need to consider the issues Chris O’Brien identifies in his article Optimization, BLOB caching and HTTP 304s.

Get Rid of those Unnecessary SharePoint JavaScript Files

If your site has been extended to solely be an anonymous internet site then chances are a bunch of JavaScript is being downloaded to the page that will never be used by the end user and you should strongly consider changing that. Microsoft covered this off in SharePoint 2007 in a section (within a larger article) titled Managing Page Payload (Small Is Good). Chris O’Brien covered this off again in SharePoint 2010 in his post Eliminating large JS files to optimize SharePoint 2010 internet sites and Mahmood Hamed extended on that in his article Eliminate large JS files to optimize SharePoint 2010 internet sites: the complete reference.

Consider Warming up your SharePoint Site

Warming up the pages across your SharePoint site is a good idea for two reasons. Firstly, ASP.NET’s Just-In-Time compiler will often cause the first access of a site to be extremely slow compared to usual. Secondly, the caching techniques discussed previously only kick in once a page has been visited for the first time. By running a script or job to warm up the site you can avoid the ‘first hit’ performance lag associated with these issues. There are a number of sources of information regarding this topic but one such article that seems to collate a lot of them is Wahid Saleemi’s Roundup: SharePoint Warm-Up Scripts.

So that about sums it up – my take on a start to finish process on performance optimising a SharePoint site. When approaching this task with limited time and budget it’s important to target the factors you believe will offer the greatest gain for the time required to implement. With any luck the tasks completed will be identifiably successful enough that future projects will be undertaken with performance in mind right from the start.