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. 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 (like Magento\Framework\App\Http::launch) measurably slow bootstrap. DI compilation — more modules = larger generated DI configuration = slower di:compile and more memory during compilation. 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_Authorizenet modules for providers you don't use Unused shipping methods: Magento_Fedex, Magento_Ups, Magento_Usps, Magento_Dhl if you use a third-party shipping module Sample data (if installed): Magento_CatalogSampleData, Magento_CustomerSampleData, etc. Staging & Preview (if not on Commerce): All Magento_*Staging modules 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. 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.json to 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. 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. 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 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