Evaluating Drupal Modules for Performance

Drupal was designed from the ground-up to be modular. Once you install Drupal core, you can add any number of modules to enhance Drupal's basic functions.

Unfortunately, contributed modules can also impede performance. For example, it's common to find contributed third-party modules that are incompatible with newer versions of Drupal, or other modules. Besides being a security hassle, this can often curb performance.

Evaluating Drupal modules for such issues is thus essential for a smooth Drupal experience. As part of this ongoing blog series on ways to improve Drupal website performance, let's review how you can evaluate modules.

General module evaluation

The first step in module evaluation is to consider general usage reports, statistics, and maintainer reputation. One by one, go through the following:

• Does the module officially support your version of Drupal?
• Good maintainers write good code. If you see the same maintainer's name crop up on a number of well-regarded modules, you know you will at least get quality code.
• A high maintainer activity level (i.e. commits to a module) indicates a proactive maintainer who takes care of issues quickly.
• Higher total module usage generally means it's a well-regarded module with fewer performance issues.
• A large number of stagnant, open issues can point to poor code quality and maintenance.
• Sudden changes in usage patterns over a short period of time can be indicative of performance issues. For example, if people suddenly stop using a popular module, it could mean that users encountered performance or security problems.

Once you've gone through these steps, you can undertake a performance evaluation.

Module performance evaluation

Now you need to analyze the module performance on your own site.

• Record site performance before installing any modules. This should include page load time, server load, and user scenario completion time.
• Record site performance immediately after installing the module.
• Monitor memory usage continuously to correlate the performance before and after module installation.
• Perform the same steps for every module individually over time.

These actions will give you quantifiable results on each module's performance as it relates to your site. You might find that highly rated, widely used modules sometimes don't play well with your version of Drupal, while less used modules work perfectly well.

Final questions

Besides evaluating performance, you also need to ask a few questions before using a module.

• Does the module scale? A module that works perfectly well for a small enterprise website might break when used on a large community-powered platform. Scale is difficult to measure but it is one of the biggest performance bottlenecks in any website.
• Is performance a top priority? While performance is important, it is by no means necessary for certain types of websites. For example, a small corporate website visited mostly by internal team members may not need top-notch performance.
• What happens if the module fails? This is an important question. If your module stops working, does it break the site completely, or can the users at least access parts of the site? For example, if the module that controls the login system fails, your users won't be able to use their accounts at all.
• Do I really need the module? Far too many websites use more modules than necessary. This leads to "module bloat." Ask yourself: Do I really need this module? Is there a simple manual workaround to enable this function? If "yes," try to avoid using a module. Keep in mind that the fewer modules you use, the smaller chance of failure.

Modules are crucial for running a Drupal website, but they are also one of the leading causes of website performance issues. Evaluating and understanding modules is essential for running a fast and secure Drupal website.