Best practices for publishing sites (SharePoint Server 2010)
Applies to: SharePoint Server 2010
This article is one of a series of Best Practices articles for Microsoft SharePoint Server 2010. This article describes best practices for publishing sites that are based on SharePoint Server 2010.
Publishing sites differ from collaboration or intranet SharePoint sites that must support various authentication and authorization models. In publishing sites, most user operations are reads, so these sites typically allow anonymous authentication for most users. For additional information and resources about Web content management Best Practices for SharePoint Server 2010, see the Best Practices for SharePoint Server 2010 (https://go.microsoft.com/fwlink/p/?LinkID=220280) resource center.
1. Start with a well-configured infrastructure
Your server farm should be well-configured and should use the recommended hardware for SharePoint Server 2010. You should also verify that your SharePoint license supports the kind of deployment that you want to use. For information about licensing requirements and how to determine the number of server farms that you need, see Planning for server farms (SharePoint Server 2010). Be sure to follow the recommendations in the Hardware requirements—Web servers, application servers, and single server installations section of Hardware and software requirements (SharePoint Server 2010).
Because Internet-facing sites have stricter expectations around performance and availability than team collaboration sites, make sure that you plan for the availability and capacity expectations of your publishing sites. For more information, see Plan for availability (SharePoint Server 2010) and Capacity planning for SharePoint Server 2010.
2. Make query-driven Web Parts efficient
Web Parts that query lists can be very resource-intensive. Understand the scope of each operation that a Web Part performs when it combines data from its queries.
When using query-driven Web Parts, such as the Content Query Web Part, do the following:
Select data from as few lists as possible.
Index the columns that are used to filter on in the Content Query Web Parts. For more information, see Index a column(https://go.microsoft.com/fwlink/p/?LinkId=221926) in Manage lists and libraries with many items(https://go.microsoft.com/fwlink/p/?LinkId=221934).
To query large amounts of data that is distributed across different sites or site collections, use SharePoint Search. It is much more efficient at these kinds of queries than the Microsoft.SharePoint.SPQuery object.
If you are building a custom Web Part, make sure that you use the CrossListQueryCache class for query caching. The SPQuery object does not provide any caching functionality and using it could lead to decreased performance.
Be sure that queries follow the guidance about large lists in the white paper Designing Large Lists and Maximizing List Performance (DesigningLargeListsMaximizingListPerformance.docx) (https://go.microsoft.com/fwlink/p/?LinkID=191156).
3. Organize content to optimize query performance
Follow the recommended limits for lists and databases to optimize query performance. Exceeding list and database limits directly affects the performance of SharePoint Server 2010 features and behavior. For information about specific limits, see SharePoint Server 2010 capacity management: Software boundaries and limits and Enterprise content storage planning (SharePoint Server 2010).
When planning your site, consider your user base and how they will interact with the site. Structure the site collection and sites in a way that separates authors based on which groups of people will create what content. Place the Content Organizer at the top level of the site collection, and use content types to sort and move the content to the appropriate sites. For more information about the Content Organizer, see Metadata-based routing and storage overview (SharePoint Server 2010).
4. Use author-in-place on a single server farm
You can use a single server farm for both authoring and publishing. This is known as an author-in-place model, because you author on the same server that is used for publishing. This differs from a two-stage model in which you have separate servers on which you author and publish content. In general, the author-in-place model is the preferred model to use for publishing because it means that you have fewer servers to manage and content can go live more quickly. When you use the author-in-place model, authors access the server from the intranet, so you can specify what users and groups have permission to author and approve content. You also use the publishing workflow to determine when content is approved for publishing and to specify the dates and times the content goes live. To prevent unauthorized users from creating content on the site, you extend the Web application to a new zone that uses a separate URL, such as for an Internet or extranet site. Although the site at the new URL uses the same content database as the intranet site, you can restrict access to the public site so that anonymous users have read-only permission. For information about how to extend Web applications, see Extend a Web application (SharePoint Server 2010).
If your security policies require that internal and external-facing sites must be on separate servers, you should use content deployment to push content from the authoring environment to the production environment. For more information, see Best practices for content deployment (SharePoint Server 2010).
5. Plan ahead for variations
If you think there is a possibility that you might have to set up variations sites, you should plan for them beforehand. It is very difficult to integrate variations sites into a site collection after the site structure is implemented. The following factors can affect your ability to easily move to using variations sites later in the life of your site:
Custom code Code that contains references to the location of the root variations site.
Site customizations Site navigation, Master Pages, and other customizations.
Search Search scopes must be created for each variation label, and the site properties of each variations site must be modified.
For more information about how to plan for variations, see Plan variations (SharePoint Server 2010).
6. Use caching
Caching can provide big benefits to a publishing site. Be sure to use the different kinds of caching appropriately. When caching is used correctly, it can significantly improve throughput and user response time.
SharePoint Server 2010 provides the following kinds of caches:
Output cache This cache stores requested page content in the memory of the Web server. For more information, see Output Caching and Cache Profiles (https://go.microsoft.com/fwlink/p/?LinkID=121543).
Object cache This cache stores SharePoint objects, such as Web and list item metadata, in the memory of the Web server.
The object cache makes its database queries as one of two user accounts: the Portal Super User and the Portal Super Reader. These user accounts must be configured correctly to ensure that the object cache works correctly. The Portal Super User account must be an account that has Full Control access to the Web application. The Portal Super Reader account must be an account that has Full Read access to the Web application. For information about how to configure these accounts, see Configure object cache user accounts. For more information about the object cache, see Object Caching (https://go.microsoft.com/fwlink/p/?LinkID=123948).
BLOB cache This cache can store image, sound, video files, and other large binary files on disk. You should always cache .js, .css, and any other file types that are related to the branding of your site. For more information about the BLOB cache, see Disk-Based Caching for Binary Large Objects (https://go.microsoft.com/fwlink/p/?LinkID=123947). If you will be using the BLOB cache with rich media such as video files, you should also enable Bit Rate Throttling in Internet Information Services (IIS). For more information, see Bit Rate Throttling in Plan for caching and performance (SharePoint Server 2010).
Note
If you are using file types that are not cached by default, you must configure the BLOB cache settings in the web.config file to include the file name extensions that you want to cache. For information about how to configure the BLOB cache settings, see Configure cache settings for a Web application (SharePoint Server 2010).
In geographically distributed environments, consider using third-party cache devices with SharePoint Server 2010 to move content closer to users and avoid round trips. For more information, see WAN accelerators and other third-party tools in Optimizing Office SharePoint Server for WAN environments. (Although this content was written for Microsoft Office SharePoint Server 2007, the guidance it contains is still valid for SharePoint Server 2010.) You might also consider using a CDN for jQuery libraries with your Web application. For more information about jQuery and CDN, see Microsoft Ajax Content Delivery Network (https://go.microsoft.com/fwlink/p/?LinkId=218875).
For more information, see Plan for caching and performance (SharePoint Server 2010), Estimate performance and capacity requirements for Web Content Management in SharePoint Server 2010, and SharePoint Server Caches Overview (SharePointServerCachesPerformance.docx) (https://go.microsoft.com/fwlink/p/?LinkID=191156).
7. Be careful of custom code that uses AllowUnsafeUpdates
When you set the AllowUnsafeUpdates property to true, your site becomes vulnerable to cross-site scripting attacks. This can be especially important with Internet-facing sites where anonymous users access the site. If you have custom code that uses AllowUnsafeUpdates with either the SPSite class or the SPWeb class, make sure that you use a try/catch block to handle any errors, and use a finally block to set AllowUnsafeUpdates back to false. For more information, see "Working with AllowUnsafeUpdates Property" in SharePoint Coding Practices - A Quick Overview (https://go.microsoft.com/fwlink/p/?LinkId=218876), and SharePoint Security Best Practices: Cross-Site Request Forgery(https://go.microsoft.com/fwlink/p/?LinkId=221924) in Security Best Practices for Developers in SharePoint 2010(https://go.microsoft.com/fwlink/p/?LinkId=221925).
8. Enable ViewFormPagesLockdown
By default, when a site collection uses the Publishing Portal template, anonymous users cannot access Forms pages on a site. This feature, which is known as ViewFormPagesLockdown, locks down a site from anonoymous users and prompts users for credentials before it allows them access to Forms pages on a site. If you activated the publishing features for a non-publishing site, you should make sure that you enable the ViewFormsPagesLockdown feature for the site. For more information, see Lockdown Mode in SharePoint 2010 (https://go.microsoft.com/fwlink/p/?LinkId=218877) and Anonymous Users, Forms Pages, and the Lockdown Feature (https://go.microsoft.com/fwlink/p/?LinkId=218878). (Although this content was written for Microsoft Office SharePoint Server 2007, the guidance it contains is still valid for SharePoint Server 2010.)
Acknowledgements
The SharePoint Server 2010 Content Publishing team thanks the following contributors to this article:
Aaron Saikovski, Microsoft Consulting Services
Bryan Porter, Microsoft Consulting Services
Ethan Gur-Esh, Microsoft Enterprise Content Management
Israel Vega, Jr., Microsoft Consulting Services
Josh Stickler, Microsoft Enterprise Content Management
Oleg Kofman, Microsoft Consulting Services
Steve Peschka, Microsoft Consulting Services
Steve Walker, Microsoft SharePoint Customer Advisory Team