Step 8: Take advantage of caching
Much of the content requested by users can be cached in memory, including list items, documents, query results, and Web parts. Site administrators can configure their own cache profiles to meet different user needs. Anonymous users, for example, can be assigned one set of cache policies while authenticated users are assigned another, allowing content editors to get a more recent view of content changes than general readers. Cache profiles can also be configured by page type, so publishing pages and layout pages behave differently, and administrators have the option to specify caching on the server, the client, or both.
In addition, the SharePoint Object Cache can significantly improve the execution time for resource-intensive components, such as the Content Query Web Part. For example, large objects that are requested frequently, such as images and files, can also be cached on disk for each Web application to improve page delivery times.
Step 9: Manage page customizations
SharePoint Designer is a useful tool for administrators and power users but page customization can be harmful to overall performance. When customization occurs, the entire page content, including the markup and inline code, is stored in the database and must be retrieved each time the page is requested. This introduces relatively little additional overhead on a page-by-page basis, but in larger environments with hundreds or even thousands of pages, all that back-and-forth to the database can add up to significant performance degradation.
To prevent this problem, administrators should implement a policy that restricts page customizations to only those situations where it is absolutely necessary. Site collection and farm administrators also have the option to disable the use of Designer or, when necessary, use the Reset to Site Definition option to undo changes and revert back to the original content.
Step 10: Limit navigation depth
One of the most significant design elements on any portal site is the global, drop-down, fly-out menu at the top of each page. It seems like a handy way to navigate through all the various sites and pages -- until it becomes so deep and cluttered that all ability to navigate beyond the first few levels is lost completely. Even worse, fetching all the data to populate the navigation menus can be resource-intensive on sites with deep hierarchies.
SharePoint designers have the ability to customize the depth and level of each navigation menu by modifying the parameters for the various navigation controls within the master page. Administrators should limit that depth to a manageable level that does not affect performance.
Eric Shupps is a SharePoint MVP who specializes in SharePoint performance to help organizations better understand the different ways and places SharePoint performance can be improved. This article was written in partnership with Idera.
Read more about data center in Network World's Data Center section.