Drupal blocks provide secondary content that often lines the left and right sides of Drupal web pages. Typical blocks are menus, lists of recent posts, and forms for logging in and searching. But every block on a page increases Drupal's work to assemble a page, slowing down your web site. Speed it up by disabling the blocks that have the biggest performance impact. This article benchmarks 32 common blocks and concludes with a few guidelines on what to watch out for when selecting blocks for your site.
Table of Contents
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 and enabling several different types of caching to speed up your web site.
How to reduce the number of blocks
Every block you add to your site slows it down a bit. Some blocks can have a big impact. You can test blocks yourself by enabling them one at a time and monitoring their affect on your site's performance:
- Log in as your Drupal site's administrator.
- Go to the Administer » Site building » Blocks page.
- For any block, select <none> from its pull-down menu to disable the block, or select a page region (such as left sidebar) to enable it.
- Click the Save configuration button.
Often, when you enable a block the performance impact is immediately obvious. For instance, when I added the Weather module's weather report block (which I discuss more below) to my test web site, the page load time more than tripled. But sometimes the impact is more subtle and it grows over time. A recent review of the busy Drupal.org site found that a block that listed recent forum posts was a performance problem: it was getting slower and slower as the number of forum posts increased. While the block may have been fast when it was first enabled, years later it had grown into a big problem.
How well does this work?
There are two main ways to look at the performance of a Drupal web site:
- The page assembly time is the time it takes Drupal to build an HTML web page. This includes the time to query the database for page content and run through all of the page's blocks to get their contributions to the page. The more blocks there are, the longer the page assembly time.
Effect on page assembly time
I benchmarked the page assembly time for a variety of blocks. For each one, I measured the time with and without the block, then computed the impact as a percentage increase in assembly time (see the appendix for details on how I ran the tests).
|Blog||Recent blog posts||2.1%|
|Event||Calendar to browse events||12.9%|
|Flickr||Flickr random photos||5.6%|
|Flickr||Flickr recent photos||5.4%|
|Forum||Active forum topics||1.7%|
|Forum||New forum topics||1.6%|
|Google AJAX search||Google AJAX search||6.0%|
|Poll||Most recent poll||5.3%|
|Recent blocks||Recent block||0.9%|
|Service links||Service links||2.8%|
|Similar entries||Similar entries||17.4%|
|Similar terms||Similar entries from ANY vocabulary||1.7%|
|Similar terms||Similar entries from vocabulary||2.1%|
|Switch theme||Switch theme form||1.1%|
|Tagadelic||Tags in vocabulary||2.1%|
|Taxonomy block||Taxonomy block||7.9%|
|Taxonomy context||Context for vocabulary||1.8%|
|Taxonomy ticker||A ticker block||7.9%|
|Weather||System wide||342.3%||. . .|
Impacts of 5% or less are not significant and result from normal variations in system and network load. But some blocks have a much more substantial impact:
- The Weather module's impact was an enormous 342%. To report the current weather, this block queries a weather service on every page load. This stalls Drupal while the block waits for the (very slow) service to return an answer. In contrast, the Flickr modules are much faster because they query the Flickr service only every 15 minutes or more (depending upon your settings), then re-use the same results for ever page in the interim.
- The Recent comments block slowed down the web site by 25%. The block must scan through all comments in the database to find the most recent. This is very slow and the more comments your site has, the slower the block will go.
- The Random image block added 25% to the page assembly time. While it only adds a single image to the page, to randomly select that image the block must find and count all of the image nodes at the site. This requires a full scan through all of the nodes in the database, which is slow. The more nodes your site has, the slower this will go.
- The Similar entires block slowed page times by 17%. The block looks for nodes similar to a current node. To do this, it scans through all nodes in the database, which is slow. Once again, the more nodes your site has, the slower this block will go.
- The Calendar to browse events block added 13% to the site’s page time. The block scans through all nodes in the database looking for events to show on a calendar. This is slow and the more nodes your site has, the slower this will get.
- The Taxonomy block and Taxonomy Ticker blocks each added 8% to the site's page assembly time. Both blocks query the database for a list of recent nodes based upon taxonomy terms. This will get slower as your site adds nodes and uses more taxonomy terms.
In these tests, the Forum module blocks were quick, but for a large site with a lot of forum entires, these blocks will be much slower. As I noted earlier, a recent analysis of the Drupal.org web site, which has a lot of forum entries, found that the forum blocks were a significant performance problem. Disabling the blocks sped up the site.
Fortunately, many of the most important blocks are fast, such as those for menus and the search and login forms.
|Blog||Recent blog posts||1.5%|
|Event||Calendar to browse events||11.4%|
|Feedbuttons||Subscribe buttons||107.0%||. . .|
|Flickr||Flickr random photos||6.7%|
|Flickr||Flickr recent photos||6.6%|
|Forum||Active forum topics||88.2%||. . .|
|Forum||New forum topics||1.4%|
|Google AJAX search||Google AJAX search||773.6%||. . .|
|Poll||Most recent poll||1.3%|
|Recent blocks||Recent block||1.5%|
|Service links||Service links||23.8%|
|Similar entries||Similar entries||1.3%|
|Similar terms||Similar entries from ANY vocabulary||1.2%|
|Similar terms||Similar entries from vocabulary||1.2%|
|Switch theme||Switch theme form||1.0%|
|Tagadelic||Tags in vocabulary||0.9%|
|Taxonomy block||Taxonomy block||1.7%|
|Taxonomy context||Context for vocabulary||1.4%|
|Taxonomy ticker||A ticker block||3.3%|
Some additional HTML per block is expected, of course, as are block-specific style sheets and images. Size impacts of 5-10% are not significant. But some blocks add much more:
- The Subscribe buttons block doubles the page size by adding 32 icons for various popular RSS feed sources. The Service links block does about the same thing but with only 19 icon images for community sites like Digg and Del.icio.us. Both blocks can be configured to limit the number of services (and icons) they list. That would help performance.
- The Active forum topics block nearly doubles the page size by adding HTML for a list of forum topics plus four decorative images defined by the theme.
- The Weather module's block adds 15% to the page size. This is almost entirely from adding one poorly-compressed icon for the current weather conditions.
The rest of the blocks have only a minor impact on the page size.
Most blocks do small jobs and do them well. But some blocks can have a big impact on your site's performance. To speed up a web site, reduce the number of costly blocks that you use.
- Don't use blocks that query an outside service on every page load. If that service is slow, your site will be slow too. Visitors will blame your site, not the outside service.
- Don't use blocks that require searching through every entry in big database tables. Every database query takes time, but the slowest queries are those that have to look through every entry in a table. If the table is big, this will take a long time.
- Don't use blocks that add a lot of images to the page. Every image takes time to download. For some of the blocks tested, the images overall were much larger than the page content they were decorating.
- Don't use blocks that use poorly-compressed images. Small icons, when poorly-compressed, can be larger in size than much more important elements on your page. If you must use a block with poorly-compressed images, re-compress them yourself.
When building a site, monitor the impact of each new addition to the site. Sometimes simple additions can have a big performance impact. Evaluate each addition's cost and its benefits to the visitor.
As with all benchmarking, your own results will vary due to differences in CPU power, memory size, network bandwidth, page size, theme choice, and page layout. Use this article's results only as a rough guideline.