Sunday 21 June 2009

My checklist for optimizing SharePoint sites

Optimization is probably one of my favorite SharePoint topics – it seems there’s always a new trick to learn, and I love the fact that a minor tweak can have a dramatic impact on how well your site works. There are some great resources out there now for information on how to boost performance, but it strikes me that there isn’t one single paper or article which contains all the aspects I personally consider or have been relevant to me on past projects. Hence this article is essentially an aggregation of some of these sources. The aim isn’t for it to be “complete” (if there is such a thing) or authoritative in any way, and I know I wouldn’t be the first person to blog on this subject – it really is just a reminder list for me to refer to, but if it helps you also that’s great.

Key resources:

Before I break into the list, remember that different optimization measures will have different effects depending on your circumstances - having the best checklist in the world is really no substitute for the SharePoint architect’s ability to identify what is likely to be the bottleneck for a given implementation. Additionally my list is quite “developer-focused”, but if the infrastructure aspects of the implementation is the limiting factor (e.g. latency between web servers and SQL, amount of usable RAM etc.) you can probably optimize code until you’re blue in the face without solving your performance problem.

My list is broken down into sections, and some of the items have links to some useful resource or other which you might find helpful if the topic is new to you.

Configuration

Items in this section typically have  a big impact – in particular output caching, which is the first thing to consider on WCM sites for example.

Code/development

  • Test with SPDisposeCheck to ensure no memory leaks
  • Measure page payload weight (again, YSlow useful here) – aim to reduce as far as possible
  • Eliminate unnecessary ViewState! A good dev technique may be to turn off ViewState in web.config and then override it in controls/pages which really do need it (haven’t tried this, but keep meaning to).
  • Ensure not downloading core.js etc for anonymous users/delay-loading for authenticated.
  • Ensure image sizes are small/images are optimized for web (still comes up!)
  • Always ensure height/width attributes specified on images
  • Ensure custom CSS is factored correctly
  • Don’t forget client-side code efficiency e.g. CSS, jQuery selectors
  • Consider using a code-profiling tool such as ANTS profiler or dotTrace to identify sub-optimal code
  • Ensure general good coding practice e.g. your optimization work may well be undone if your code is badly-written. Accidentally doing unnecessary processing in a loop (in server-side OR client-side code is one example I’ve seen many times)
  • Be wary of performance impact of custom HTTP modules – I frequently see huge perf gains when running load tests with such modules enabled/disabled. Removing core.js as a post-processing step within a HTTP module is NOT the right approach kids! (No really, I’ve seen it done..)

Code/development – advanced

These tips might only really be necessary if you’re implementing a high-traffic site, but are worth considering:

  • Consider factoring custom JS/CSS into fewer files – fewer HTTP requests is better
  • Consider “minifying” JS
  • Consider using CSS to cluster background images (all images stitched into one for fewer HTTP requests) – AC might have mentioned somewhere an online service to automate this..

Architecture

You should consider this section absolutely incomplete – hopefully there’s enough here to dissuade anybody of the notion that it’s only about code though! The first two in particular are key.

  • 64-bit/sufficient available RAM etc.
  • Latency between web and SQL – MS suggest a ping response of less than 1 millisecond
  • Consider a CDN solution (e.g. Akamai, Limelight etc.) if users are geographically far away from servers (and y0ur client can afford it!)
  • Ensure not using web garden with BLOB cache (known BLOB cache issue)
  • Are app pool settings correct – check for excessive app pool recycling by enabling logging to the Windows event log using - cscript adsutil.vbs Set w3svc/AppPools/ <YourAppPoolName> /LogEventOnRecycle 255. Once or twice per day is probably the maximum you’re hoping for.
  • Is storage correctly architected e.g. are OS, data, logs on different disk spindles?
  • Is storage correctly configured (e.g. SAN configuration) – are your LUNS giving you sufficient IOPS?!


Using YSlow to help optimize websites


One particular tool worthy of discussion when we’re talking about optimizing websites is YSlow – if you haven’t come across it yet, this is a Firefox plugin which extends Firebug) developed by Yahoo! developers which uses their optimization ruleset (customizable) to report on and help further streamline your site. The tool focuses on communication between the server and browser – clearly a browser tool like this can’t identify any back-end issues, but it’s always interesting to run a site through the checks.

The first tab gives a ‘grade’ for your site based on the ruleset, helping you identify areas for improvement (I’ve highlighted where the page stops and the YSlow console starts with a red box):

YSlow_Grading 
The next tab provides a breakdown of files downloaded by the request, and allows me to see their size and headers etc. In particular I can see the expiry date and Etag and so on which the files are being tagged with so they can be cached locally:

YSlow_Components

The statistics tab provides some good analysis on the page weight and also illustrates the difference between a first visit and subsequent visits where appropriately tagged files will be served from the browser cache:

YSLow_Stats

Finally the Net tab in Firebug is also interesting, as this shows me how files were downloaded (sequential or in parallel) – the most recent browsers do a much better job of this, with IE8 and FF3 being able to open 6 channels per URL domain to download files in parallel, but note that IE7 could only open 2.

Firebug_NetAnalysis

From this, I also see the http://sharepoint.microsoft.com site (great site btw) I’ve been analyzing also displays the BLOB cache issue I discussed recently (now confirmed as a bug) where incorrect headers are added to files stored in the Style Library, causing lots of unnecessary HTTP 304s to go across the wire. So YSlow does give a great insight – however I do agree with Jeff Atwood’s reminder that some of the reported “issues” may not be the biggest concern for your site. As always, apply common sense.

Summary

Optimization is a deep topic, and this checklist is simply my reminder of some of the things to consider, though in reality a solid understanding of the nuts and bolts is required to really architect and develop high-performing sites. Tools like YSlow can also help with some aspects of optimization.

So which optimization nuggets did I miss which you consider? Feel free to leave a comment and add to this list..

13 comments:

Mehmet Aydın said...

thanks for the great article(s)!!!

nippe said...

Great article!

Adding on to the toolbox:

- I like Visual Round Trip Analyzer (VRTA) by Microsoft (depends on Netmon). It give a good overview of round trips and perf. (http://www.microsoft.com/downloads/details.aspx?FamilyID=119f3477-dced-41e3-a0e7-d8b5cae893a3&displaylang=en)

- neXpert plug-in for Fiddler (http://www.fiddler2.com/fiddler2/addons/neXpert.asp)

Your post was geared towards WCM sites, but it might be worth mentioning Kerberos as a configuration option for collaborations sites.

Chris O'Brien said...

@Niklas,

Great tips, thanks. I came across VRTA recently and it seemed very interesting - there's a lot of overlap with the 'Net' tab in Firebug (shown above) but it may well add further value, I didn't dig deep enough.

And agree on Kerberos - am no expert here but I understand the biggest performance gain is to be had when the user sessions are fairly long in length.

Thanks again,

C.

Kale said...

Great list Chris, gives me some things to think about with my current sites.

Although a bit long winded, Joel's writeup on AppPool Settings is a good read I think and expands on the Technet article.

Ian Morrish said...

Also take a look at http://www.wssdemo.com/Pages/Measure%20SharePoint%20Performance.aspx

Anonymous said...

There is a wonderfully detailed article on the inner workings of the BlobCache here:

http://sharepointinterface.com/2009/06/18/we-drift-deeper-into-the-sound-as-the-flush-comes/

Unknown said...

Hi Chris,

Do you know anything about what JavaScript and CSS files do NOT need to be sent across the wire when the site is public? For example, core.js is 265k.

I've profiled a bunch of Sharepoint sites and the frontend performance is pretty bad! It's not uncommon to find a site that's serving 11 separate JS files and near the same amount of CSS. Can those easily be concatenated/minified?

Chris O'Brien said...

@cancel,

If you're using a custom master page/layout, I *think* you can completely suppress core.js, core.css, init.js, and ie55up.js for anonymous users.

I'm pretty sure at least the first 3 are definite, but you'd need to test with your site to be sure - an automated crawler would be best to ensure you've tested all master pages/layouts used on your site.

HTH,

Chris.

Unknown said...

I agree with core.js, I took a look at it and it looks to be related to backend/admin interface/functionality. I think we'll have to keep core.css, though.

Do you know if there is any documentation anywhere that explains what each .js and .css file are for? Sharepoint serves up a lot of them and I dont' want to send anything across the wire that isn't really needed on the public site.

Chris O'Brien said...

@cancel,

Yes, it comes down to your site design at the end of the day - certainly when I've done it I've known that the front-end of the site absolutely will not use any of SharePoint's CSS classes for example.

But testing is the only way to be sure.

Afraid I'm not aware of any useful documentation on each file, and certainly the implementation of CSS in SharePoint 2007 is "sub-optimal".

HTH,

Chris.

Anonymous said...

Chris, was at SPC09 recently and saw a sharepoint web accelerator called WAX - any views on it as an option?

Chris O'Brien said...

@Anonymous,

Yep, I came across this recently - it's the Aptimize product. I haven't seen it in action, but I'm definitely impressed and Microsoft used it for http://sharepoint.microsoft.com. As far as I can see it automates some of the (non-SharePoint specific) tasks in my checklist. So it might come down to a financial decision on whether it's more cost-effective to do it manually or automate. Certainly promises to simplify the process though.

Chris.

renegade_cy said...

Hi Chris,

I have successfully managed to remove all unnessesary js files using your method. The problem is that both ribbon.js and core.js seems to be required for the top menu flyout. Can you tell me which js classes are needed so i can load them manually using the script tag