In SharePoint Server only Publishing pages can be cached in the output cache.
When a Publishing page is rendered, the Publishing feature assembles the page dynamically.
To do this, Publishing must first fetch the page layout and then fetch the contents
of the page. Both of these operations incur SQL Server round trips that affect throughput and
latency. To increase throughput and scalability,
Publishing pages can use the output cache so that pages aren’t rendered on each
The cache is configured per site collection.
The cache profile is a collection of settings and parameters that are used to determine if and how a page will be cached.
There are two options for cache invalidation
1. Time to live
2. Check for changes
If a profile specifies a “time to live” (TTL) then a page is served until this length of time has passed.
If “Check for Changes” is specified in a profile, all pages using that profile are invalidated
if there is any site changeor until TTL expires (whichever comes first).
This is because it’s not possible to know which site changes could alter the rendering of every page.
1. A site that is serving pages from the output cache should expect a ninefold improvement in page throughput
compared to rendering each page.
2. When checking for site changes, each change causes the cache to flush the entries for that profile. There is a big performance penalty to flush and re-fill the cache. Therefore using TTL based cache invalidation is one way to ensure good performance on sites that experience frequent changes.
3. Each rendered copy of a page may use as much as 2x+32 KB of memory where x is the size of
the rendered page in KB.
4. The vary by custom feature of the output cache allows multiple versions of a page, rendered for different targets,
to be output cached.The number of vary byparameters will directly affect the amount of memory
required by the output cache
5. Using different cache profiles for difference page layouts allows more control over the output cache.