Today, let's look at caching a page fragment. Here's the code:

<cfcache action="cache" timespan="#CreateTimeSpan(0,0,0,5)#">
    <cfoutput>This date/time IS cached: #Now()#<br /></cfoutput>

<cfoutput>This date/time is not cached: #Now()#</cfoutput>

Result in a browser:

This example shows how to cache a page fragment on both the client and the server using action="cache." Notice how the <cfcache> tag is wrapped around a simple <cfoutput> tag. The use of the opening and closing <cfcache> tag is in contrast to the example I blogged about yesterday. The date/time string within the <cfcache> block will be cached for 5 seconds while the date/time string in the <cfoutput> below that will not be cached. If you run this example on your ColdFusion 9 server the second date/time string will change every page request while the first date/time string will only change every 5 seconds.

How is this different from what was possible before ColdFusion 9? In ColdFusion 8 you could use the <cfcache> tag to cache full Web pages on the server or client. Server caching (action = serverCache) stored copies of pages on disk while client caching (clientCache) stored pages in the browsers default cache. Or you could've simply used action="cache" to store the page on both the server and the client. The example here would not work on ColdFusion 8 because page fragment caching wasn't available. You could accomplish fragment caching using a combination of <cfsavecontent> and shared scopes (Application, Server, Session, or Client) or third party utilities such as CacheBox and ScopeCache.

ColdFusion 9 adds several new features to the <cfcache> tag including memory caching (default) and page fragment caching such as the example in this post. These aren't the only additions to <cfcache>, but I'll save some of the others for later posts.

So why is page fragment caching a good thing? It allows you to isolate heavy code such as complicated queries, disk operations, ETL (extract, transform, load) tasks, etc., and cache them over time. The first user that hits the page experiences the long running task while each additional user benefits from the cached version of the operation and subsequent output (if any). It's best to limit page fragment caching to code that is universal for all users. Headers and footers of Web sites might be good things to cache while session-specific data like shopping carts would not.

One final thing to keep in mind, <cfcache> and the later function-based caching I'll post about in the future are not your only options. You can still use shared scopes such as Application and Session to strategically store, read, and output virtually any data including strings, arrays, structures, and even ColdFusion components.

Click here to download the code mentioned in this post.

Aaron West's Gravatar
About this post:

This entry was posted by Aaron West on November 18, 2009 at 8:00 AM. It was filed in the following categories: ColdFusion. It has been viewed 18461 times and has 1 comments.

13 related blog entries

1 Responses to 14 Days of ColdFusion 9 Caching: Day 2 - Caching a Page Fragment

  1. Ike

    Hey Aaron! Thanks for the mention. :)

    Even after seeing all the new features in CF9, I still think CacheBox is a superior tool, even despite the fact that the auto-configuration features were never finished and I still don't know if it works on Railo or BlueDragon. ;) And it's kind of gratifying to see that even though I haven't done any work on it recently, there've been 1,280 downloads since I published it a few years ago. I'm guessing that means people are still enjoying it. :)