Why Is Magento 2 So Slow? How to Fix Performance Issues

Most Magento 2 slowness traces back to a short list of causes: full-page cache misses, indexers left in realtime mode, undersized or badly split infrastructure, stale PHP, heavy third-party modules, and an unoptimized frontend. This article is a checklist of fixes for each, ordered roughly by impact, current as of Magento 2.4.8.

One scoping note: a slow admin panel has partly different causes (grids, reports, synchronous operations) and gets its own guide, How to Fix a Slow Magento 2 Admin Panel. This article focuses on the storefront and the infrastructure underneath it.

Measure Before You Tune

Optimizing without measurement wastes time on the wrong layer. Split the problem in two:

• Time to first byte (TTFB): the server side (caching, PHP, database, indexers).
• Everything after first byte: the frontend (JavaScript, CSS, images, fonts).

A store with 200 ms TTFB and a 6-second render has a frontend problem. 3 s TTFB on a product page is a caching or server problem. Application monitoring (New Relic, or the open-source stack of your choice) tells you which transactions and SQL queries burn the time. Browser DevTools and PageSpeed Insights cover the frontend half.

Measure, don’t guess. Re-measure after every single change, or you won’t know which one worked.

Quick Wins That Need No Code

Four settings fix a surprising share of “Magento is slow” complaints:

1. Production mode. Developer mode compiles code and regenerates static files on the fly. Check with bin/magento deploy:mode:show.
2. All caches enabled. bin/magento cache:status should show 1 in every row. Stores are regularly found running with a cache type disabled since some long-forgotten debugging session.
3. Indexers on “Update by Schedule”. Check with bin/magento indexer:show-mode. Realtime indexing makes admin saves and imports painfully slow and degrades the storefront while it runs. Switch with bin/magento indexer:set-mode schedule.
4. Admin action logging off (if you don’t need the audit trail): bin/magento config:set admin/usage/enabled 0.

Varnish: the Single Biggest Lever

The built-in full-page cache executes the whole Magento bootstrap on every request even on a cache hit. Varnish answers from memory before PHP starts, which is why Adobe recommends it for every production deployment and treats the built-in FPC as a development tool.

Two things determine how much Varnish gives you:

• Hit rate. A cache that is technically enabled but constantly missed helps nobody. Watch the hit rate in varnishstat.
• Cacheability. A single block marked cacheable="false" in a module’s layout XML makes every page containing that block bypass the cache entirely. Badly written third-party modules do this to whole categories of pages. Audit with a grep across vendor/ when the hit rate looks wrong.

Most managed Magento hosting offers Varnish as a checkbox. On self-managed servers it sits in front of nginx as a reverse proxy on the default configuration exported by bin/magento varnish:vcl:generate.

Right-Size the Server

Magento is a large system and resource starvation shows up as random, hard-to-reproduce slowness.

• PHP version. Magento 2.4.8 runs PHP 8.3/8.4, and 2.4.7 runs 8.2/8.3. Each PHP major is measurably faster, and the JIT compiler helps most on long-running work: cron, indexing, imports. If you are stuck on an old release, the upgrade guide covers the path.
• RAM. 2 GB is the documented minimum, 4 GB+ the practical baseline for the app node. Size for spikes: deployment, setup:di:compile, and indexers consume far more than steady-state traffic.
• CPU. A useful sizing rule: cores = (expected concurrent requests / 2) + expected cron processes. Two cores is the floor. Four is the reasonable start for a medium store.
• Separate the database. A database sharing the instance with PHP fights it for memory and I/O. A dedicated DB node with a properly sized InnoDB buffer pool is the first infrastructure split worth paying for. Varnish, Redis/Valkey, and OpenSearch follow as load grows.
• Fast NVMe storage. Magento reads thousands of small files (modules, generated code, configuration). Slow disks amplify every one of them.

Full version matrices live in Adobe’s system requirements.

Redis / Valkey Tuning

Magento keeps configuration cache, data cache, and sessions in Redis or in Valkey, the drop-in fork that Adobe now lists as the supported option on current patch releases (Valkey 8.1 on 2.4.7-p10+ and 2.4.8). Everything below applies to both. Even the Cm_Cache_Backend_Redis backend name stays the same.

Unix Sockets Instead of TCP

When the cache and the application share a machine, a unix socket skips the TCP three-way handshake and delivers up to ~50% more throughput:

// app/etc/env.php
'cache' => [
    'frontend' => [
        'default' => [
            'backend' => 'Cm_Cache_Backend_Redis',
            'backend_options' => [
                'server' => '/var/run/redis/redis-server.sock', // socket path instead of host
                'database' => '0'
            ]
        ],
    ]
],

Enable the socket in the server config and give the PHP-FPM user access:

# /etc/redis/redis.conf (or /etc/valkey/valkey.conf)
unixsocket /var/run/redis/redis-server.sock
unixsocketperm 770

Add the Redis/Valkey and PHP-FPM users to the same group, then restart the service.

Use sockets only when app and cache are on the same host. Multi-node deployments must keep sessions on a network-reachable standalone service so all application nodes share them.

Transparent Huge Pages (THP)

If the cache is still a bottleneck, check THP. Redis and Valkey both recommend disabling it:

cat /sys/kernel/mm/transparent_hugepage/enabled

The output should be never or madvise. If it isn’t:

echo madvise > /sys/kernel/mm/transparent_hugepage/enabled

With THP fully enabled you may see latency spikes on writes and slower fork-based persistence.

Composer Autoloader Optimization

When monitoring shows the most expensive transaction inside Magento\Framework\Config\Dom::_mergeNode, Magento is burning time on XML configuration processing. First confirm the cache is on (bin/magento cache:status). If it persists, it is an I/O problem the autoloader cache helps with:

composer dump-autoload -o --apcu

In a deployment script, the order matters:

composer install --no-dev
bin/magento setup:di:compile
composer dump-autoload -o
bin/magento setup:static-content:deploy

Requires PHP with the APCu extension enabled.

Skip --classmap-authoritative, because it conflicts with Magento’s generated code (we have seen composer fail to resolve a third-party plugin class with it).

MariaDB Tweaks

Adobe’s performance documentation recommends these settings to speed up reindexing:

optimizer_switch = "rowid_filter=off"
optimizer_use_condition_selectivity = 1

Beyond that, the variable that matters most is innodb_buffer_pool_size. On a dedicated database node, set it to hold your working set (commonly 70-80% of the node’s RAM). Watch join_buffer_size as well, because Magento’s EAV joins are wide.

Indexer Batch Size

This log entry means indexers are flooding the database’s memory:

Memory size allocated for the temporary table is more than 20% of innodb_buffer_pool_size. Please update innodb_buffer_pool_size or decrease batch size value.

Indexers precompute values needed at browse time, for example final prices per currency with catalog rules applied, and fetch rows in batches. Bigger batches are faster but hungrier. Two ways out:

• increase innodb_buffer_pool_size, or
• decrease indexer batch sizes.

We maintain an example module that aggregates the batch-size configuration of all default Magento indexers as a starting point. The simplest tuning approach: halve the values, re-measure, repeat.

Do Not Enable Flat Catalog

Flat catalog was an old tuning trick that collapses Magento’s EAV attribute tables into one flat table to avoid joins. Adobe has discouraged it since Magento 2.1: it causes indexing problems and degrades overall performance, and search-engine-backed catalogs (OpenSearch) made it obsolete.

If a previous optimization round enabled it, turn it off under Stores → Settings → Configuration → Catalog → Catalog → Storefront (set both Use Flat Catalog Category and Use Flat Catalog Product to “No”), then reindex.

Frontend: Where the Other Half of the Time Goes

Server tuning cannot rescue a page that ships megabytes of JavaScript. In order of typical impact:

• Theme choice is the decisive factor. The default Luma frontend carries RequireJS, Knockout, and jQuery on every page and scores poorly on Core Web Vitals no matter how well the server behaves. Hyvä replaces that stack (Tailwind CSS + Alpine.js) and routinely takes stores from failing to passing CWV. For Luma-based stores it is the single largest frontend improvement available.

• Images. Serve WebP/AVIF, size images to their rendered dimensions, and lazy-load everything below the fold, but never the LCP image (typically the hero banner or main product photo). Preload that one instead, along with your critical fonts.

• Critical CSS (Magento 2.4.2+), enabled via CLI only:

  bin/magento config:set dev/css/use_css_critical_path 1

  Then provide app/design/frontend/<Vendor>/<theme>/web/css/critical.css containing only the styles needed for the first paint. Keep it lean.

• JavaScript bundling: leave Magento’s off. The built-in bundler produces one enormous bundle that hurts more than it helps, and the once-recommended Baler tool is abandoned. On HTTP/2 and HTTP/3, unbundled modules with proper preload hints perform well. If you need real bundling, that is another argument for a modern theme rather than fighting RequireJS.

• CDN + modern protocols. Serve static assets from a CDN with HTTP/2 or HTTP/3 enabled. Multiplexing removed the old six-connections-per-host constraint that asset bundling was invented to work around.

Audit Third-Party Modules

Every extension runs on every request whether you use it or not. The classic offenders: modules that disable page caching (see the Varnish section), analytics/feed modules doing synchronous HTTP calls in observers, and abandoned extensions incompatible with your PHP version. Disable candidates one at a time on staging and re-measure TTFB. It is common to find one module responsible for most of the regression. Our Magento 2 issues FAQ covers several errors that surface during this kind of cleanup.

When to Bring in Help

Everything above is a safe self-service checklist. When the numbers still refuse to move, or you’d rather have the bottleneck found for you, a structured Magento performance audit measures the store end to end and returns a ranked list of fixes with expected impact, which you can implement with us or hand to your own team.

External Resources

• Adobe Commerce performance best practices
• Adobe Commerce system requirements
• Composer autoloader optimization
• Redis benchmarks and tuning factors
• Magento indexer batch size configuration module