Page Output Caching

To make a response eligible for output caching, it must have a valid expiration/validation policy and public cache visibility. This can be done using either the low-level OutputCache API or the high-level @ OutputCache directive. When output caching is enabled, an output cache entry is created on the first GET request to the page. Subsequent GET or HEAD requests are served from the output cache entry until the cached request expires.

The output cache also supports variations of cached GET or POST name/value pairs.

The output cache respects the expiration and validation policies for pages. If a page is in the output cache and has been marked with an expiration policy that indicates that the page expires 60 minutes from the time it is cached, the page is removed from the output cache after 60 minutes. If another request is received after that time, the page code is executed and the page can be cached again. This type of expiration policy is called absolute expiration - a page is valid until a certain time.

The following example demonstrates a simple way to output cache responses using the @ OutputCache directive. The example simply displays the time when the response was generated. To see output caching in action, invoke the page and note the time at which the response was generated. Then refresh the page and note that the time has not changed, indicating that the second response is being served from the output cache.

VB Outputcache1.aspx [Run Sample] | [View Source]

The following directive activates output caching on the response:

<%@ OutputCache Duration="60" VaryByParam="none"%>

Of course, in the previous example, very little work is saved by output caching. The following example shows the same technique for output caching, but queries a database and displays the results in a grid.

VB Outputcache2.aspx [Run Sample] | [View Source]

In the final example, the application is modified slightly to allow the user to selectively query for authors in various states. This example demonstrates caching requests varying by the name/value pairs in the query string using the VaryByParam attribute of the @ OutputCache directive.

<%@ OutputCache Duration="60" VaryByParam="state" %>

Note that the first time you click the link for a given state, it generates a new timestamp at the bottom of the page. Thereafter, whenever a request for that state is resubmitted within a minute, you get the original timestamp indicating that the request has been cached.

VB Outputcache3.aspx [Run Sample] | [View Source]

Applications that want more control over the HTTP headers related to caching can use the functionality provided by the System.Web.HttpCachePolicy class. The following example shows the code equivalent to the page directives used in the previous samples.

Response.Cache.SetExpires(DateTime.Now.AddSeconds(60))
Response.Cache.SetCacheability(HttpCacheability.Public)

To make this a sliding expiration policy, where the expiration time out resets each time the page is requested, set the SlidingExpiration property as shown in the following code.

Response.Cache.SetExpires(DateTime.Now.AddSeconds(60))
Response.Cache.SetCacheability(HttpCacheability.Public)
Response.Cache.SetSlidingExpiration(True)

Note: When sliding expiration is enabled (SetSlidingExpiration(true)), a request made to the origin server always generates a response. Sliding expiration is useful in scenarios where there are downstream caches that can satisfy client requests, if the content has not expired yet, without requesting the content from the origin server.

Applications being ported from ASP may already be setting cache policy using the ASP properties; for example:

Response.CacheControl = "Public"
Response.Expires = 60

These properties are supported by ASP.NET and have the same effect as the other examples that have been shown.

Section Summary

1. Output caching caches the content generated by ASP.NET pages.
2. Pages are not placed in the output cache unless they have a valid expiration or validation policy and public cache visibility.