After you have designed and built some of your site, it is important to start examining, testing, and tuning performance. Leaving it to the end of the build phase is often the cause of project delays. Starting early lets you build up a good set of performance goals and test cases that you can run repeatedly as function and content are added. You find and fix performance issues early and go into production with confidence that your site can handle the load you require.
Another aspect of performance tuning is setting up portlet caching. Portlets are in front of the entire data retrieval and rendering processes. Setting up caching at the portlet level reduces load throughout the entire system. Any requests that can be pulled directly out of this cache means avoiding calls to the Web Content Manager rendering engine, security checks, database access, and so on. By default, the portlets in the page templates and in the palette are not set to cache. As each site is different, we could not set up an appropriate cache set. After doing all of the back-end tuning and getting a baseline performance level, you can start enabling caching on portlets to examine the effect on load tests. Typically on an anonymous website you can set caching almost unilaterally; the difference may be in the timeout period for the cache, with portlets like 'latest items' lists typically having a faster timeout than more static content.
To apply caching across many pages at once, export the pages and add caching parameters to the exported XML, and re-import. You may end up repeating this process a few times as you fine-tune the caching to achieved desired performance levels.
Parent topic: Deploying sites built with Content Template Catalog