Speed up a Drupal web site by enabling block caching

Technologies: Drupal 5+, Block cache module

Most Drupal web sites have a set of blocks that line the left or right sides of its web pages. Typical blocks are menus, lists of recent posts, and forms for logging in and searching. Every block adds to the work Drupal must do to assemble a page, but some blocks are particularly slow. To speed up your site, install the Block Cache module to create cached versions of your slowest blocks. This article benchmarks the impact of block caching for 29 common blocks.

This article is part of a series on Essential steps to speed up a Drupal web site. Other articles in the series discuss simplifying your site’s theme, avoiding slow blocks, and enabling several different types of caching to speed up your web site.

How to enable block caching

Drupal does not have block caching built-in. Instead, download the free Block Cache module, drag it in to your site's modules folder, and enable the module:

  1. Log in as your Drupal site's administrator.
  2. Go to the Administer » Site building » Modules page.
  3. Click the checkbox beside the Block Cache module.
  4. Click the Save configuration button.

Once enabled, the module automatically creates a duplicate cached version of each of your site's blocks. For example, if you have a menu block named "Navigation", the Block Cache module will create a new cached block named "Navigation [[-CACHED-]]".

By default, none of the cached versions of your blocks are enabled. Enable them the same way you enable any other type of block:

  1. Log in as your Drupal site's administrator.
  2. Go to the Administer » Site building » Blocks page.
  3. For any cached block, such as "Navigation [[-CACHED-]]", select a page region, such as "left sidebar", from the pull-down menu beside the block name.
  4. Click the Save configuration button.

During debugging, it is common to include both the non-cached and cached version on the page at the same time. Once everything is working, disable the non-cached block.

When Drupal uses a normal non-cached block, Drupal asks the block to build its part of the web page every time Drupal assembles a page for a site visitor. If the block is slow, your site will feel slow. But with the cached version of a block, the block's part of the page is built just once then re-used over and over each time Drupal sends the page. This saves time.

It is important to configure a cached block to tell it when it should update its portion of the page. Some blocks should update every time a user logs in or whenever site content changes. To configure a cached block, change its settings as the administrator:

  1. Log in as your Drupal site's administrator.
  2. Go to the Administer » Site building » Blocks page.
  3. Click configure to the right of a cached block's name.
  4. Change the cache settings at the top of the page.
  5. Click the Save block button.

In the Cache type section of the block configuration, check one, both, or neither of these:

  • Page specific indicates the block should change on every page, such as a block that shows taxonomy terms for the node on the page.
  • User specific indicates the block should be different for different users, such as a menu block with special menu items only for administrators.

For the Cache lifetime, select the longest time (in seconds) before the block will be automatically rebuilt. By default this is blank, and cached blocks are only rebuilt when site content changes (see below). For a 1-day lifetime, set this to 86,400 seconds.

For the Refresh when section, check none, some, or all of these:

  • A node is added/updated/deleted indicates the block should update each time any nodes change at the site, such as for a block that lists recent blog or forum posts.
  • A comment is added/updated/deleted indicates the block should update whenever someone adds or changes a comment, such as for a block that lists recent comments.
  • A user is added/updated/deleted indicates the block should update whenever user accounts are changed, such as for a block that lists new users.
  • A user logs in or out indicates the block should update when users come or go, such as for a block that lists the people currently logged in.

A common error is to forget to change these settings. For example, if you create a cached version of the standard Navigation menu, everyone will see the same version of the menu. But administrators should see the Administer menu item on the menu, and anonymous visitors should not. To create a different cached menu for different users, be sure to make the cached block User specific.

How well does this work?

I benchmarked the effect on page assembly time for a variety of blocks. For each block, I measured the time for the non-cached block and the cached version, then computed the impact as a percentage decrease in assembly time (see the appendix for details on how I ran the tests).

Impact on page assembly time
(higher is better)
Module Block Change  
Blog Recent blog posts 1.9%
Comment Recent comments 19.5%
Countdown Countdown 0.0%  
Donations Donations 0.0%  
Event Calendar to browse events 11.3%
Feedbuttons Subscribe buttons 1.5%
Flickr Flickr random photos 0.9%
Flickr Flickr recent photos 0.0%  
Forum Active forum topics 1.0%
Forum New forum topics 1.5%
Image Latest image 2.3%
Image Random image 19.7%
Menu Navigation 0.0%  
Node Syndicate 0.0%  
Nodewords Meta tags 0.4%
Poll Most recent poll 4.8%
Recent blocks Recent block 0.0%  
Search Search form 1.8%
Service links Service links 1.2%
Similar entries Similar entries 9.9%
Similar terms Similar entries from ANY vocabulary 0.8%
Similar terms Similar entries from vocabulary 1.4%
Tagadelic Tags in vocabulary 1.8%
Taxonomy block Taxonomy block 1.4%
Taxonomy context Context for vocabulary 1.6%
User Login 2.0%
User Who's new 0.7%
User Who's online 1.6%
Weather System wide 77.4%

Impacts of 5% or less are not significant and can result from normal variations in the system and network load. These small percentages are always for blocks that are already very efficient, such as menu blocks, the login form block, and the search form block. That is fortunate since these are important blocks for nearly any web site.

The blocks that most benefit from being cached are those that normally take a long time to assemble their contribution to a web page:

  • The Weather module's current-weather block improves by 77%. The non-cached block accesses a slow weather service to get the current weather on every page load. By caching the block, the weather service is only queried whenever the cached block needs to be refreshed (such as once an hour). This changes an unusably slow block into a reasonably fast one.
  • The Recent comments and Random image blocks each improved by 19%, while the Calendar to browse events and Similar entries blocks improved by 10-11%. All of these non-cached blocks have to scan through the site's contents to look for relevant information to present. The bigger the site, the slower these will go. The cached form of these blocks re-does the scan only when site content changes, such as when a new comment is posted, an image is added, or a calendar event is scheduled. In between changes, the cached block re-uses the previous results on every page, speeding up the site.

Conclusions

Every block on a page can take time to generate its contribution to the page. Slow blocks can make the whole site feel slow. To speed up a site, replace slow blocks with cached versions that are updated less frequently.

  • Replace slow blocks with cached blocks, but be sure to configure the cached block to update periodically (based upon the cache lifetime) or update when changes occur on the site (such as new nodes, comments, or users).
  • Don't bother replacing every block with a cached block since some blocks are already fast. Adding unnecessary cached blocks increases site complexity without a performance benefit.

Test cached blocks carefully. Some types of block don't work right as cached blocks. Other cached blocks work fine, but only if you configure them properly. During testing, include both the non-cached and cached block on your pages. Once everything is working, disable the non-cached block.

Further reading

Appendix: How I tested

All testing used a Drupal 5.1 web site loaded with sample content generated by the Devel module’s generator scripts. The site used the Garland theme, Drupal’s CSS file aggregation was enabled, MySQL’s query caching was enabled, Apache was configured to compress all CSS, JavaScript, and HTML, and eAccelerator was used to cache all compiled PHP scripts.

Page assembly times were measured using Apache Bench (ab) to repeatedly request the site’s home page or a blog page. Drupal’s page caching was disabled so that Apache Bench would measure the time to build a web page, not the time to re-send a cached previously built page.

As with all benchmarking, your own results will vary due to differences in CPU power, memory size, page size, and theme choice. Use this article’s results only as a rough guideline.

Comments

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.

More information about formatting options

Nadeau software consulting
Nadeau software consulting