SharePoint for the Internet – Part 1, Performance

The last months I have been involved in a couple SharePoint internet facing projects and decided to create a list of things to consider, specific to these type of projects. But before I start, I’d like to make a few things clear:

1. There is no definite checklist for deploying SharePoint for the Internet. Every project is different and there are no silver bullets. In fact, it is not even a real checklist (just a list of items I’d like to consider on every internet project).

2. This is my checklist based on experiences with past projects, your mileage may (and will) vary Smile 

3. There are so many options and configurations possible, it is not just about enabling/disabling features and options to achieve your goal. Every option should be investigated thoroughly and remember: ‘Just because you can, doesn’t mean you should’. 

Since there many options to consider, I divided them in three main categories and three separate blog posts:

  • Part 1: Performance (this post)
  • Part 2: Security
  • Part 3: Customization and usability


Big topic for internet facing websites. While SharePoint 2010 performs a lot better compared to previous versions, performance will (and should) always be on your list.

#1: Reduce page load

  • Remove the “Name Active X Control”. This control is used by SharePoint to show presence information (the little icon next to author names, etc.) and has no meaning on public (anonymous) web sites. You can do this through Central Administration (Web Application General Settings:


  • Remove the reference to the SharePoint Workspace ActiveX from the master page (present if based on the OOTB master pages).
  • Limit the use of Content Query Web Parts on landing pages. While this is a beautiful Web Part, it adds significantly to the page load time especially initially with uncached data. As a workaround you could use custom developed web parts or user controls to achieve your data query goals. This way you have good control of the rendered HTML and avoid the XSLT query processing part. But make sure you have some kind of caching in place.
  • Remove the Ribbon for anonymous users. There are a couple of ways to do this, these are the most obvious ones:
Ok? Remove or hide it using CSS. Usually not the best way to do this, because the Ribbon and support files are still downloaded by the client. They are just hidden or removed from the DOM.
Better? Wrap the Ribbon in a SPSecurityTrimmedControl. A far better option IMO, but there is a penalty because SharePoint needs a database round-trip to fetch the rights.
Best? Use different Master Pages for anonymous users and editors. You can remove the Ribbon control and support files completely from the anonymous Master Page. Also a good option if you use Content Deployment and have separate authoring and publishing farms. On the downside, you will need to find a way to use Master Pages based on what type of user requests the page.
  • Minify jQuery and other 3rd party JavaScript libraries. Use a CDN if applicable for the libraries since this facilitates caching by browser, proxy server, etc. Remember to enable local fail-over copies.

#2: Monitor Page Requests

  • Use a network monitor or traffic inspector (like Fiddler2) to monitor the HTTP request and response associated with a page request. These type of tools make optimizing page loads a whole lot easier.
  • Use the SharePoint Developer Dashboard to monitor processing and render times of individual components.

#3: Adjust IIS Dynamic Compression

  • By default SharePoint Web Servers have static and dynamic file compression enabled, but the compression level for dynamic files is set to “0”. This means that dynamic files don’t get compressed at all. You can adjust the compression level and the CPU threshold settings, for more information see Technet. It is not just about enabling this, you will have to monitor performance and Web Server CPU for tuning adjustments.

#4: Caching

SharePoint 2010 and the underlying ASP.NET offer several different methods for caching. Again no silver bullets here, and my advice: develop a caching strategy! The way you configure the different caching options totally depends on the type of content served (static versus dynamic), the audience, intended web site usage and so on. Make a note on what type of cache you configure, how you configure it and what results you expect. Once you start monitoring your site’s performance you can easily check and adjust where needed.

More info on this topic, see Technet.

  • The BLOB cache. BLOB stands for Binary Large OBject and is a disk based storage. Files initially retrieved from the SharePoint Content Database are stored on disk and served to clients on subsequent requests. You need to think about what type of files to store, where to store them (on the web server) and what client cache life time to configure (max-age).
  • The Object cache. If you are using SharePoint’s publishing feature (and you probably are on internet facing sites), you can configure this cache. The cache stores SharePoint objects (lists, page layouts, etc.) in-memory to speed up queries on them. They require the correct configuration of what is called the “Object Cache User Accounts”, again see Technet for more information.
  • Output cache. Based on ASP.NET Output Caching, but with added features (which also require the SharePoint publishing feature). Usually the least popular of the three, probably because it is a little bit harder to configure correctly. There are a couple of considerations to make, so definitely take a look at the Technet article.

Please, feel free to comment on this topic, more coming soon.