The key to using the Cache Block plugin to speed up publishing is to cache items that may require a lot of resources or database queries to build, that don't strictly need to be updated on every single page build. One thing to keep in mind when planning your caching strategy, is that the posting of new entries and the posting of comments will trigger a automatic rebuild/re-publish of multiple pages of your site. For example, when someone posts a comment, the entry page for that comment gets rebuilt, as does the category pages for all categories of that entry, any date-based archives containing the entry, author archives for the entry author, and all index templates that are set to "rebuild with indexes". As such, the frequency of comments can play a major role in how much publishing activity happens on your site.

Some ideas for Cache Blocks:

  • cache your entire sidebar for 60 minutes
  • cache your entire "Archive Index" for 1440 minutes (a full day)
  • cache your feeds for 60 minutes (so they won't get built on every comment)
  • cache entry summaries and comment detail modules to speed page builds with many entries or comments
  • cache individual sidebar widgets that don't need to be updated frequently
Example: Cache Your Sidebar

If you are using MT4 default templates, you can cache your sidebar as shown below. In this example, the sidebar is cached for 60 minutes.

<MTCacheBlock key="blog1_footer" expiry="60">
<$MTInclude module="Footer"$>
</MTCacheBlock>

Let's assume the above code is on your "Main Index" template. The existing MTInclude is simply wrapped inside an MTCacheBlock container. Note that doing it thos way will only check the cache when the Main Index template is built. But most sites have the same sidebar displayed on multiple pages of the site. If this is true for your site, you can gain even more benefit from wrapping each of those MTInclude blocks, using the same cache key. But be careful -- many sites have unique sidebars for each archive page (entry, category, etc.) -- in such cases you won't want to pull the same "Main Index" sidebar.

Looking at the above example, you may be wondering whether it would be easier to simply place the MTCacheBlock tags inside the "Footer" template module. That way, you wouldn't have to repeat the process for each template that shares the same sidebar. There are two reasons why this is not a good idea:

  1. As a general rule when caching the contents of template modules, you will get more speed gains by placing the MTCacheBlock tags around the MTInclude statement, rather than inside the module itself. The reason is that if MT finds the block in the cache, it won't even bother trying to load and evaluate the included Template Module, which requires a database lookup by itself. In short, you can save at least one database lookup by wrapping the MTInclude tag instead.
  2. The second reason -- at least in this specific example -- is that the default "Footer" module is included for all pages for the site, and it contains some conditional code that creates different sidebars for different pages. As noted above, the sidebar for the Main Index may be different from the sidebar that appears on an Entry archive page. In such case, you need to be very careful. If you placed the MTCacheBlock tags inside the Footer module, then every page would have the exact same sidebar, and that would be the first sidebar that was built and saved in the cache. For example, suppose the first page to publish was one of you Entry Archives. MT would built the special sidebar for that entry ("This page contains a single entry from....", etc.) and save that in the cache with the key "blog1_footer". And then MT would publish your Main Index and MT will check the cache for "blog1_footer" and it will grab that Cache Block and place it in your Main Index. You should always be careful when caching block that include condition logic. For similar reasons, you should also be careful when caching block that are inside looping container tags (see below).

Example: Caching the 'Comment Detail' Module for each Comment

Suppose you have a site that gets a lot of comments. Some of your entries get over 100 comments. Every time a new comment gets added, MT will re-publish your entry page and build the HTML for every one of those 100+ comments. Consider that once a comment has been posted, it rarely changes (unless you edit the comment for some reason). As such it is safe to cache the HTML for each individual comment, so MT won't have to evaluate those template tags for each comment. You can do so as follow, in your "Comments" template module:

<MTSetVarBlock name="comment_cache_key">comment_detail_<mt:CommentID></MTSetVarBlock>
<MTCacheBlock key="$comment_cache_key" expiry="120">
<$MTInclude module="Comment Detail"$>
</MTCacheBlock>

Notice that this example is a little different. Because the MTInclude tag is inside the MTComments container, which is repeated for every comment, we can't use the same cache key for every comment. We need to make sure that we use a unique cache key for each comment. We do this by using MTSetVarBlock to create a variable that represent a unique key. In this case, I chose comment_detail_<mt:CommentID> which will be unique because it includes the commentID number. Once we have saved this unique key in the "comment_cache_key" variable, we can then use that as the key by specifying key="$comment_cache_key" (note the dollar sign to indicate that we are using a variable).

The examples above are just two of the many ways that you can use Cache Block to speed up your MT publishing. Since each site is different in terms of templates, posting activity, traffic, etc., different techniques may work better for different sites.