10 ways to improve Drupal performance

Drupal performs on some of the worlds most important Web sites. Like all other top sites, the top Drupal based sites have some features tuned for extra performance. You can tune your own site the same way.

An untuned site will require bigger, more expensive, hosting accounts before a tuned site. You definitely save money by tuning your Web site.

Some Web site tuning techniques have nothing to do with Drupal and apply to most Web sites. Others are specific to the type of Web hosting account you use. Some are related to the selection of modules. Some are simple Drupal administration settings. Lets start with the simple Drupal administration settings.

Drupal administration settings

Log in to your Web site as the administrator. Select Administer then Site configuration then Performance. You now control several of the top performance improvements.

1. Caching mode

Look under Page cache. Find the Caching mode option. You have the following three options.

• Disabled
• Normal
• Aggressive

Disabled is the setting you use on a test site when developing modules that generate pages. This setting is the slowest and has no use other than testing modules.

Normal is the setting you want switched on for best performance on most sites. Bad performance problems are sometimes caused by a developer switching this setting to disabled for a test then forgetting to switch back to normal use.

Aggressive is rarely used because it is not compatible with commonly used modules. When you use the aggressive setting, some modules switch the setting off for specific pages. Some modules issue a warning about compatibility. When you do not get warnings, you can still have problems with users seeing out of date information on their Web pages. You need a lot of experience and really good testing to use this option.

2. Minimum cache lifetime

While you are on the performance page, look at Minimum cache lifetime. Caching is a messy business. You want to deliver old pages to save the work of generating new pages but you do not want to deliver obsolete information. You make a trade off. Assume your Web site provides fishing forecasts updated a couple of times per day. You could set Minimum cache lifetime to an hour to improve performance. If the same site presents storm warnings, you might shrink the cache lifetime to one minute to make sure pages are never more than a minute out of date.

The default setting of zero is fine for sites where most users log in because logged in users always get fresh pages. Well designed modules remove their content from the cache when the content is out of date and the next visitor automatically gets updated information.

The cache lifetime applies mainly to background updates to content through cron jobs and similar processes. Look at the modules you have installed. If they update using cron and they reset data that is in a cache, read the module documentation for suggestions on cache lifetime settings. If there is nothing mentioned in the documentation, open an issue against the module ask ask.

3. Page compression

If you are not using page compression, you are wasting your visitors time while they wait for Web page downloads. Page compression uses a little bit of processor time to shrink the Web pages and downloads become noticeably faster on everything except the fastest broadband.

Now for the big decision. Drupal can compress your Web pages and your Web server can compress your Web pages. You waste processor time when both programs compress your Web pages. I set all my Web servers to compress all pages so that non Drupal pages are compressed. I then switch off compression in Drupal.

You might not have control of your Web server. cPanel and similar administration options should tell you what your Web server does and give you the option to switch compression on. If you do not have access to the Web server settings, ask your Web hosting supplier to switch on compression in the Web server then switch compression off in Drupal.

As a last resort, leave compression on in Drupal. A good Web server will recognise the compression and not recompress.

4. Block cache

Switch on Block cache to save the overhead of recreating the block content for every page. Some modules frequently update blocks and they will delete individual blocks from the cache as required.

Some block access control modules will disable block caching. If you want to control access to some blocks and not others, you want a result where the uncontrolled blocks are cached and only the controlled blocks are cached. When selecting block access control modules, ask about their effect on the block cache and on uncontrolled blocks.

5. Optimise CSS files

Optimising CSS files creates a big decrease in download times and a small decrease in the load on your server. Switch this option on except when developing and testing a new theme. You rarely create problems by optimising CSS files.

6. Optimise Javascript files

Optimising Javascript files creates a decrease in download times and a small decrease in the load on your server. Switch this option on except when developing and testing a new theme or a new module. Some themes fail when you optimise their Javascript!

Javascript is painful at the best of times. Some people use special techniques to make their Javascript files smaller and those techniques turn Javascript from bad to really bad. Optimising those really bad files can make the result really, like really really bad.

Optimising Javascript files is a random result because you might not find a problem until someone uses a specific feature on a specific page. On other occasions, all Javascript is destroyed. Test all the Javascript based features of your site before and after optimising the Javascript files.

7. Module administration settings

Some add-on modules have their own caches and cache settings. Check all your add on modules. Views is optional in Drupal 6, is built into Drupal 7, and has a cache option in Drupal 6. Other modules with cache options include Feeds and Panels.

8. Uninstall unused modules

When you add a module to your site directory, the only processing overhead is in the administration section. The instant you select the Enable option for a module, Drupal added the module to a the load in memory and passes the module to every function using Drupal's hook system. If you do not use the module, you can decease the load by disabling the module. If the module creates database tables, you can reduce the database size by uninstalling the module.

9. Choose smaller simpler modules

Some modules provide a lot of functions while others provide just one function or they split a lot of functions into many smaller optional modules. Look for the smallest module to perform the work. When you install a package containing lots of optional modules, switch the optional modules on one at a time until you have only what you need and nothing more.

10. Test one module at a time, one option change at a time

Adding a module and changing a setting for a module can have a big impact on performance. Suddenly changing lots of settings can destroy your Web site performance and create real problems diagnosing the cause. If you change one option then watch the system for a day, you should see any performance problems.

The add-on Devel module can help you see the workload created by a module. You can look at execution times and database overheads before then after the addition of a module or the change of a setting. Do not use the Devel module outside of initial testing because the Devel module adds a big overhead.

See also 10 ways to improve your Web server for better Drupal performance.