Every time Magento handles a request, it loads hundreds of PHP classes, registers thousands of event observers, and wires up a plugin chain across the entire framework. Most of this work is for modules you never use.
The fix is straightforward in theory: remove unused modules. In practice, it requires care — Magento's dependency graph is complex, and removing the wrong module can break things silently.
Here's how to do it safely.
Why module count matters
A standard Magento 2.4.x installation ships with approximately 420 modules. A typical B2C store actively uses 80–120 of them.
The remaining 300 modules still have a cost:
Autoloader pressure — PHP's autoloader registers class paths for every enabled module. More modules = more paths to check on every class load.
Observer overhead — every enabled module can register event observers. Magento dispatches events on every request; each observer adds overhead.
Plugin chains — interceptors (plugins) wrap core methods. Each plugin adds a function call. Deep plugin chains on hot code paths (likeMagento\Framework\App\Http::launch) measurably slow bootstrap.
DI compilation — more modules = larger generated DI configuration = slowerdi:compileand more memory during compilation.
Which modules are safe to remove?
Generally safe to disable on a standard B2C store:
B2B modules (if you don't use B2B features):
Magento_Company,Magento_SharedCatalog,Magento_NegotiableQuote
Magento_PurchaseOrder,Magento_Requisition
Unused payment methods:
- Any
Magento_Paypal*,Magento_Braintree,Magento_Authorizenetmodules for providers you don't use
Unused shipping methods:
Magento_Fedex,Magento_Ups,Magento_Usps,Magento_Dhlif you use a third-party shipping module
Sample data (if installed):
Magento_CatalogSampleData,Magento_CustomerSampleData, etc.
Staging & Preview (if not on Commerce):
- All
Magento_*Stagingmodules
The dependency problem
You can't just disable a module — you need to check if anything depends on it first.
# Check what depends on a module before disabling
bin/magento module:status --show-list | grep -i "Magento_Braintree"
Disabling a module that something else depends on causes cryptic errors. Always check the full dependency tree.
Step-by-step: safe module removal
1. Create a full backup first. Always. No exceptions.
2. Analyze your current module set:
bin/magento module:status > modules-before.txt
3. Identify candidates:
- Look for modules in
vendor/magento/that your store doesn't use - Cross-reference with
composer.jsonto see which are explicitly required
4. Test in staging first:
bin/magento module:disable Magento_Braintree --clear-static-content
bin/magento setup:upgrade
bin/magento cache:flush
5. Run your test suite. If you don't have one, manually test checkout, catalog browsing, admin functions.
6. Measure the difference:
# Before
time curl -s https://your-store.com/ > /dev/null
# After disabling modules
time curl -s https://your-store.com/ > /dev/null
7. If all good, repeat in production.
Expected results
Results vary by store configuration, but typical outcomes:
| Metric | Before | After (30 modules removed) |
|---|---|---|
| Bootstrap time | 180ms | 130ms |
| PHP memory peak | 28MB | 22MB |
| DI compile time | 4m 20s | 3m 10s |
| Observer count | 1,840 | 1,320 |
A 20–40% bootstrap improvement is realistic on most stores.
Automating this safely
Manual module analysis is tedious and error-prone. The BetterMagento Turbo Core module provides an interactive CLI wizard that:
- Builds the complete dependency graph for your installation
- Identifies modules with no dependents that aren't actively used
- Shows you the safe removal candidates ranked by impact
- Lets you preview changes before applying them
- Generates a rollback script so you can undo any change
# Analyze your installation
bin/magento bm:turbo:analyze
# Preview what would be removed
bin/magento bm:turbo:optimize --dry-run
# Apply with automatic rollback script generation
bin/magento bm:turbo:optimize --generate-rollback
Important caveats
- Always test in staging before production
- Re-run analysis after major Magento upgrades
- Some modules appear unused but are required by custom code — the analyzer checks for this
- Magento updates may re-enable disabled modules; check after upgrades
The performance gains are real and compound with other optimizations. Combined with Redis caching, query optimization, and edge delivery, you can cut total request time by 60%+ on a well-tuned store.
Originally published on magevanta.com