DEV Community

Magevanta
Magevanta

Posted on • Originally published at magevanta.com

How to Reduce Magento 2 Bootstrap Time by 30%

#magento #php #performance #ecommerce

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 (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.

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_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

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"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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:

  1. Builds the complete dependency graph for your installation
  2. Identifies modules with no dependents that aren't actively used
  3. Shows you the safe removal candidates ranked by impact
  4. Lets you preview changes before applying them
  5. 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
Enter fullscreen mode Exit fullscreen mode

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

Top comments (0)