Why Is Magento Slow? A Diagnostic Checklist for Store and Admin

Full page cache off or bypassed

If the full page cache is off or bypassed, Magento builds every page from scratch, and in our experience this is the most common cause of a slow Magento store.

The full page cache stores finished public pages, such as category, product and CMS pages, so most visitors never wait for PHP. Check it is enabled with bin/magento cache:status; the full_page line should show 1. For a live store, Adobe says "We strongly recommend you use Varnish in production". The built-in cache works, but Adobe calls it much slower. The setting is under Stores > Settings > Configuration > Advanced > System > Full Page Cache.

A full page cache can be switched on and still do little. Two things to look for:

• Uncacheable blocks. Adobe's frontend guide says "If any block in a layout is designated as uncacheable, the entire page is uncacheable." One extension that adds cacheable="false" to a layout block on a product or category page sends every visit to that page back to PHP. Search your custom code and extensions for it, for example grep -rn 'cacheable="false"' app/code app/design vendor. Adobe's advice is never to make catalog, product or CMS pages uncacheable.
• A low hit rate. Varnish's own varnishstat tool shows cache hits against misses. A hit rate that stays low usually means pages are being marked uncacheable, the cache is being cleared too often, or URLs carry parameters that turn one page into many different cache entries.

Customer-specific parts of a page, such as the basket and the customer's name, are not in the full page cache. Adobe's private content model loads them in the browser after the page arrives, so a cached page can still show the right basket. Checkout and the basket themselves are not cached at all; by default, Adobe says, "all pages are cacheable except the checkout pages". More on how this works in Varnish cache for Magento.

Indexers on the wrong mode

Indexers on "Update on Save" make every admin save slower and can load the database at busy times; "Update by Schedule" moves the work into the background.

Magento's indexers turn your catalogue, prices and stock into fast lookup tables. On Update on Save (realtime), each change is indexed immediately as it is saved. On Update by Schedule (schedule), changes are logged and cron indexes them in the background. Adobe advises: "Set the indexers to Update on Schedule for large sites, and sites with frequent updates and heavy traffic." Since 2.4.8, Update by Schedule is the default.

bin/magento indexer:status
bin/magento indexer:show-mode
bin/magento indexer:set-mode schedule
bin/magento indexer:reindex

Adobe recommends putting the store into maintenance mode and pausing cron before you change indexer modes, so plan it for a quiet window. One version catch: before 2.4.8, the Customer Grid indexer could only use Update on Save. From 2.4.8 it supports both modes.

Update by Schedule depends entirely on cron. If cron stops, the index falls behind, and prices, stock or new products stop updating on the store front.

For every indexer command and how to fix stuck indexes, see Magento 2 reindex and indexers.

Asynchronous indexing in Magento 2

"Asynchronous indexing" in Magento usually means one of two things. The first is Update by Schedule, above. The second is a separate setting for the admin's order, invoice, shipment and credit memo grids: with asynchronous grid indexing on, placing an order no longer waits for those grids to update, and cron updates them shortly after. In production mode the Developer tab that holds this setting is hidden, so set it from the command line:

bin/magento config:set dev/grid/async_indexing 1

Cron must be running for the grids to update.

Developer mode in production

A live store should run in production mode; Adobe says production mode "has better performance because static view files are populated in the pub/static directory and because of code compilation."

bin/magento deploy:mode:show
bin/magento deploy:mode:set production

Switching to production mode compiles code and deploys static files, so the store goes into maintenance while it runs. Do it on staging first and expect errors that developer mode was hiding.

OpenSearch sizing and health

Catalogue search and layered navigation run through OpenSearch, so an unhealthy or memory-starved search service slows category pages and search results.

Check the cluster's health from the server with curl -s 'localhost:9200/_cluster/health?pretty' (adjust the host and port to your setup). OpenSearch defines red as at least one primary shard unassigned, so some data can't be reached. Yellow means some replica copies are unassigned, which on a single-server setup usually just means there is no second node to hold them. Beyond health, OpenSearch needs its own memory: on a small server it competes with PHP and the database, and it is often left on default settings that don't suit the catalogue.

OpenSearch vs Elasticsearch for Magento 2

OpenSearch is the open-source search engine that grew out of Elasticsearch, and it is now Adobe's direction for Magento. Adobe's on-premises requirements list only OpenSearch 3 for Magento 2.4.9. For 2.4.8 the requirements table still lists Elasticsearch 8, but Adobe's 2.4.8 release notes say its Elasticsearch modules are deprecated. A store planning to upgrade should move to OpenSearch. More in Redis and OpenSearch for Magento.

Bots and crawler floods

Aggressive crawlers and bots can take a large share of a server's capacity, and they tend to hit the pages the cache can't help with.

Search results are never cached, and filtered category URLs come in endless combinations, so most of them are not in the cache. A crawler working through them lands on PHP almost every time. Look at the busiest IP addresses and user agents in your web server's access log, for example:

awk '{print $1}' access.log | sort | uniq -c | sort -rn | head

Well-behaved crawlers follow robots.txt; abusive ones don't, and have to be blocked at the server or at a CDN. Our guide on how to block AI crawlers on Magento 2 covers the rules. On EveryHost servers, Sentinel reads the server's logs and blocks abusive sources at the server firewall; it is not a web application firewall or a CDN.

Why the Magento admin is slow

The Magento admin is never served from the full page cache, so it shows every database, indexer, session and extension problem directly.

When only the admin panel is very slow, check these first:

• Indexers on Update on Save, which make every product save wait for reindexing. Move them to Update by Schedule.
• Synchronous grid indexing, which makes orders and the sales grids slower. Turn on asynchronous grid indexing.
• Session locking, when several admin requests from the same user queue behind one another.
• Large grids. Grids showing hundreds of rows, or many columns from extensions, run heavy queries. Show fewer rows and remove columns you don't use.
• Cron and message queues. Bulk actions, such as mass attribute updates, run through message queue consumers that cron starts. If cron is down, they never finish.
• Admin extensions. Some extensions add dashboards, notifications or checks to every admin page. The profiler shows them.

How to clear Magento cache

Use bin/magento cache:clean for everyday cache clearing, and bin/magento cache:flush only when cleaning hasn't fixed the problem.

bin/magento cache:clean
bin/magento cache:flush

The difference, in Adobe's words: "Cleaning a cache type deletes all items from enabled Commerce cache types only", while "Flushing a cache type purges the cache storage, which might affect other processes" using the same storage. Adobe suggests you flush only if you have "already tried cleaning the cache" and still have problems. You can name cache types, for example bin/magento cache:clean full_page. In the admin, the same actions are under System > Cache Management.

When Varnish is set up with Magento's purge settings (bin/magento setup:config:set --http-cache-hosts=...), Adobe says that "when you clean, flush, or refresh the Commerce cache, Varnish purges as well". There is no need to restart Varnish. If the cache uses Redis or Valkey, use these commands rather than flushing the Redis or Valkey database by hand, for the session reason above.

Need a hand?

If you've worked through the checklist and your store is still slow, we can help. We tune the server layer on our servers in our London data centre, tell you honestly what is server and what is code, and pass code findings to your developer. See Magento performance optimisation and our plans and prices.