Last updated May 6, 2016. Created on April 28, 2011.
Edited by neerajsingh, Les Lim, n00b_nuggit, manish_mics. Log in to edit this page.

It is always good to think it over before enabling a module; too many enabled modules can slow down your site and may be tricky when updating especially on shared servers as their maximum allowed hardware resource usage is much lower than VPS and dedicated servers. If a module's functionality is no more required by the site, it should be uninstalled; and preferably the related files should be removed from the server. Additionally, modules that are poorly maintained and contain bugs can be detrimental to the security and stability of your site.

Each website's needs and resources vary widely so the following numbers are offered as rough advice, not strict guidelines in any sense. These numbers are in addition to the core modules that come with your installation:

  • For a small website on a shared hosting service: 20 or less well chosen contributed modules should provide plenty of flexibility and functionality while keeping a lean well performing site.
  • For moderately complex sites: 20-50 modules may be more adequate, though a good site builder may be able to get more functionality out of less modules. You might start to feel the shortcomings of a shared host and might consider moving to a VPS.
  • If your website is very complex and must satisfy many, many different use cases: 50 - 100 modules may be necessary. A shared hosting service may serve the site, but performance could be inadequate.
  • If you have 100 - 150 modules enabled on your site, you either have a very complex website or there are more efficient ways to build your site - consider removing modules and finding simpler solutions for your use cases.
  • If you have over 150 modules enabled on your site - either your drupal site powers NASA or you have a serious module addiction, get help.

It is important to investigate the most well-maintained contributed modules, such as Views, Rules, Panels, and others before installing a large number of different modules on your site. The functionality of these modules can often mitigate the need to install slews of other modules on your Drupal site.

Looking for support? Visit the forums, or join #drupal-support in IRC.


fadrupal’s picture

This is a good, common-sense advice, I believe. However, how many modules are too many, i.e. are we talking tens, hundreds...?

I appreciate there isn't a standard for this as each website will be different, but what is an average, or expected number of modules?


P.S. I see this applies to Drupal 6.x - I take it this is applicable to all versions, including 7.x and the upcoming 8.x .

stieglitz’s picture

The advice to use as few modules as possible is sound advice. Some modules/themes cause more of a degradation in performance than others. It does apply to all versions, however many of the contributed modules that were necessary to download in D6 were moved into core eliminating the need to download them separately (image, much of CCK etc.). Rest assured, if it is in core, performance has at least been considered. While it is impossible to specify an acceptable number (some shared hosting runs drupal core poorly...while others my run a site with many modules quite well), it seems you want an estimated number. In my opinion the number of contrib modules for most of the smaller sites I have built average in the 20's. I would say hundreds would be excessive.

fadrupal’s picture

Thanks stieglitz

jtherkel’s picture

I appreciate the info on module counts. These numbers help when negotiating with site builders who want to install unlimited modules. :)

What's a rough guideline to determine the number of modules on a site? As of May 2013, this doc recommends about 20 modules for small sites. However, installing Drupal 7.22 in the standard configuration downloads 48 core modules, 31 of which are installed by default.

Do you just subtract 31 from the outcome of drush pm-list? Do you include custom modules? Features?


ehtesabi’s picture

Actually I do not know where to post this idea (if this is not the right place please help me)
I suggest for module page to have anchor of module names. so whene you see dependency of one module, you can click on that module and going to the line of that module.
I mean for example:
module context is required by chaos tools (with link to the chaos tools module line).
it will help for fast navigation (as browsers search does not help)

trainingcity’s picture

For folks who are comfortable running drush:

There is a drush command that can count your enabled modules:

drush pml --type=module --status=enabled | wc -l

It should return a number, note that this will include every module from core as well as modules you have added, many of which contain multiple add on modules themselves.

For, a very complex site with all sorts of functionality, the count is 525, which corresponds to around "200" drupal projects. Of course this could be lowered, but many of these modules work well for specific tasks and are being maintained, and the site has the memory and other resources to run with this complexity.

judapriest’s picture

drush pml --type=module --status=enabled --no-core | wc -l

By adding option --no-core you should get only contrib' module, isn't it ?

jienckebd’s picture

When you total contributed modules, are you counting all submodules of a contributed module? So in your count, would the Media module and its Media Mediafield submodule count as 1 or 2 contributed modules?


Les Lim’s picture

Each checkbox on the Modules page is a module, regardless of whether it's part of a larger package or not.

That said, you're probably overthinking it at this point. This page is meant to describe a general principle, rather than an exact target.

newme154’s picture

Hey Guys,

I've been in the Drupal community for over 8 years now. And each company that I've worked with has had a different way of approaching the use or over use of Drupal modules. Mostly, I've been taught to use as few modules as possible in the event of critical updates, slow processing, etc. I'm now at a company that urges, no, expects the use of contributed modules to develop a site. And whats worst, is the use of modules are all over the place. I.e, beta, alpha, dev, all of them in one site. Is this an issue or am I missing something here?

deanflory’s picture

Back in the Drupal 6 days I'd say stick with the recommended stable releases for most modules, but through the evolution of Drupal 7 I've seen many useful modules linger in dev state without a stable release or one that is years old that are filled with bugs (yet still marked as "recommended"/stable).

In my opinion it's the wild west with D7 which requires each of us to test each module as well as we can since so many module maintainers have dropped the ball during this version. I do appreciate everyone's time and effort they've put into Drupal and all contributed modules but a few extra minutes by some module maintainers would save months if not years of anguish by site developers attempting to use the modules.

Short answer: I don't see how one could get around not using rc, alpha, beta and dev versions of some modules. I'd stick with the latest released since it likely has the most bug fixes but I'd test it out on a test server first before obliterating a live site somewhere.

DarrellDuane’s picture

I disagree that more than 150 modules is a problem. As more and more functionality has been developed and is need

I would like to see more modules consolidated into single modules, but I don't know how we would be able to encourage that. I like how every major release of Drupal there are more and more modules that get included into it, perhaps we need to have some sort of Module Czar who knows the landscape well and can work to find modules that would do well to be combined into one module and suggest or even fund initiatives to do so.

I have a number of sites which use more than 150 modules, and while I do have a beefy server to run them,
One of my biggest sites uses 258 modules and does just fine.

Darrell Duane

epop’s picture

Its important to remember some modules like Views can consume a huge amount of system ram. They may count as 20 modules compared to a small module on its own. Look for ways to lessen the load some of these popular modules create. Views for example, you don't have to enable the ui which can save some resources.