Speed up a Drupal web site by avoiding slow blocks in your page layout

Technologies: Drupal 5+

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.

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:

  1. Log in as your Drupal site's administrator.
  2. Go to the Administer » Site building » Blocks page.
  3. 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.
  4. 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.
  • The page load time is the time it takes for a visitor to load an entire page from your site, including getting the HTML and all of the style sheets, JavaScripts, and images that are part of the page. Much of this time is spent sending data from the web server to the visitor's browser, so the slower that visitor's network connection, and the more data you need to send them, the longer the page load 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).

Impact on page assembly time
(lower is better)
Module Block Change  
Blog Recent blog posts 2.1%
Comment Recent comments 24.9%
Countdown Countdown 6.2%
Donations Donations 7.1%
Event Calendar to browse events 12.9%
Feedbuttons Subscribe buttons 8.2%
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%
Image Latest image 2.5%
Image Random image 24.6%
Menu Navigation 0.1%
Node Syndicate 0.3%
Nodewords Meta tags 0.2%
Poll Most recent poll 5.3%
Recent blocks Recent block 0.9%
Search Search form 2.4%
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%
User Login 3.3%
User Who's new 0.6%
User Who's online 1.4%
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.

Effect on page size, including CSS, JavaScript, and images

The page load time your site visitors experience is primarily dependent upon the size of each page, including its HTML, style sheets, JavaScript, and images. The bigger these are, the longer it will take to send them to each visitor.

I measured the amount of data added to a page for a variety of blocks. For each one, I measured the total size of the page (HTML, style sheet, JavaScripts, images, etc.) with and without the block, then computed the impact as a percentage increase (see the appendix for details on how I ran the tests).

Impact on page size, including CSS, JavaScript, and images
(lower is better)
Module Block Change  
Blog Recent blog posts 1.5%
Comment Recent comments 2.7%
Countdown Countdown 0.6%
Donations Donations 5.7%
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% . . .
Image Latest image 3.1%
Image Random image 3.0%
Menu Navigation 2.1%
Node Syndicate 3.4%
Nodewords Meta tags 0.5%
Poll Most recent poll 1.3%
Recent blocks Recent block 1.5%
Search Search form 1.0%
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%
User Login 2.1%
User Who's new 1.4%
User Who's online 1.3%
Weather System wide 15.8%

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 Google AJAX search block increased the page size by an enormous 773%. The block adds four more JavaScript files, for about 40 Kbytes, about 150 Kbytes in HMTL from a default search automatically run by that JavaScript, and another 28 small icon files. The effect on the page load time is huge.
  • 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.

Conclusions

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.
  • Don't use blocks that add a lot of JavaScript to the page. Every JavaScript file has to be downloaded. For several of the blocks, the JavaScript was attached to every page, even when the block was disabled. The module could not (or chose not to) detect when it should or should not attach the JavaScript to a page. The module had to be disabled to stop it attaching unnecessary JavaScript.

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.

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 cacheing 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. Network accesses were throttled to 6 Mbps to simulate a home cable modem or DSL connection. Drupal's page caching was disabled so that anonymous accesses by Apache Bench would simulate logged-in Drupal visitor accesses (which are always uncached). Network throttling was done using the Charles proxy server and Firefox add-on on a Mac. Charles also provided the measured page sizes, including all files downloaded to build a page, such as images, style sheets, JavaScript, and any content automatically loaded via AJAX.

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.

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