This section discusses optimizing performance when you are coding CMS sites. In the previous main section, we already touched on the importance of writing efficient code for site navigation. Now we will cover other issues that CMS developers need to be mindful of when writing code for CMS templates.
Effective navigation is clearly essential to any Web site. However, making navigation effective and making it perform well may be conflicting goals. But this is the pessimist's view of the question; another way to think about it is that navigation is an excellent opportunity to improve the performance of your templates. A little time spent tweaking your navigation code can result in a large difference in your performance numbers.
Just like any other aspect of your site design, the major factor to consider when you think about navigation is how much work you are doing. For example, if you include many different types of navigation on every page, then you will be running more code than if you were to pick and choose between different navigation options. You may decide that the most popular pages in your working set should have less navigation code than other pages.
The WoodgroveNet sample site uses a number of different types of navigation. On most pages, there is a standard tree control on the left, a tab-style navigation across the top, and a breadcrumb control just below the tabs. But this is a small site. If some of the pages could not fit in the output cache, then it would be important to consider whether all these controls were necessary on all pages.
Once you have narrowed down which controls are required on each page, the next consideration is how much code is being run for each control. The most obvious example of this point is the tree control. If your channel structure is deep, it could take some time to render the control. This is true even if you are only displaying the current level of the tree. The key to using tree navigation is to use lazy enumeration. Lazy enumeration is the practice of only compiling the HTML that is necessary to display at any given time. When the WoodgroveNet left navigation control was originally built, it did not use lazy enumeration. This raised a flag during the CMS performance testing, and the control was quickly revised to only enumerate the channels that are expanded.
Once you have run the minimum amount of code required to render your navigation controls, make sure that you run this code as few times as possible. Unless your navigation changes based on factors such as personalization, you will probably find that caching your navigation results in a substantial performance benefit. Figures 34-10 and 34-11 show the importance of caching your navigation controls.
Figure 34-10. Navigation performance without caching
Figure 34-11. Navigation performance cached
CMS PAPI Searches
Not all CMS PAPI searches are created equal. For example, if you want to search your whole site for a particular posting, then a GUID search will be the fastest. The reason for this is quite simple: When searching for a GUID, CMS goes directly to the node table and retrieves the object. Other searches, such as searching by path, require processing before the object's GUID is found. Once the GUID is found, the GUID search is performed.
Not all searches require the same amount of processing; one search in particular must be handled with care. This is the custom property search. There are good and bad uses for this tool. Consider the case of meta information. Many sites use custom properties to store metadata. This information is then used for various purposes. Figure 34-12 illustrates what happens if you try to use this information to find postings across an entire site. This is a poor use of custom property searches.
Figure 34-12. Custom property search performance
Custom property searches are not inherently flawed. They can be used efficiently and very effectively. If you have already performed a different search, then you can use custom property searches on a smaller sample. For example, if you want to find all the postings that contain a certain custom property value, first narrow down the search by keeping all these postings within a certain channel. A GUID search can be used to retrieve the channel, and then a custom property search can be used to go through the postings in that channel. Based on the previous information, this would narrow down the postings searched to less than 300. This same principle should be applied to searching for channels.