How to Fix a Slow Magento 2 Admin Panel

The admin panel has no full-page cache, so every click executes the complete Magento stack. That is why a store can feel fast for customers and painfully slow for the team. The usual culprits, in order of frequency: indexers running in realtime mode, synchronous order-grid updates, heavy dashboard and report queries, session locking that serializes parallel admin tabs, and third-party modules doing slow work in admin events. Each has a specific fix below.

This is the admin-side companion to our pillar guide, Why Is Magento 2 So Slow? How to Fix Performance Issues. If the storefront is slow too, start there, because infrastructure problems drag both sides down.

Why the Admin Is Different

Storefront tuning leans on caching layers that the admin never touches. There is no Varnish and no full-page cache for adminhtml routes. Raw PHP execution speed, database load, and synchronous work decide how the admin feels. The practical consequence: configuration changes that barely register on the storefront can transform the admin.

Fix 1: Put Every Indexer on “Update by Schedule”

The single most common cause of slow product saves and slow imports. In realtime mode, saving a product waits for price, stock, and catalog rule reindexing before the page returns.

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

With schedule mode, saves return immediately and cron applies the changes within minutes. Make sure cron actually runs every minute, because schedule mode without a working cron means changes never reach the storefront.

Fix 2: Asynchronous Grid Indexing

On stores with steady order flow, every checkout synchronously updates the sales_order_grid table inside the order transaction, and admin order pages compete with that write load. Move grid updates to cron:

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

The same switch covers invoice, shipment, and credit memo grids. Grids then lag reality by up to a minute, which is a good trade on busy stores.

Fix 3: Tame the Dashboard and Reports

The admin dashboard runs aggregate sales queries on every load, and the Reports module logs storefront events (product views, wishlist adds, compares) into report_event* tables that grow without bound.

• Disable dashboard charts if nobody reads them: bin/magento config:set admin/dashboard/enable_charts 0
• Turn off report event tracking you do not use under Stores → Configuration → General → Reports.
• Keep report statistics on cron refresh instead of computing them on demand.

While you are in cleanup mode, disable admin usage logging too:

bin/magento config:set admin/usage/enabled 0

Fix 4: Session Locking Serializes Admin Tabs

With Redis or Valkey sessions, Magento locks the session per request. Two admin tabs sharing one session queue behind each other, and AJAX-heavy pages (the page builder, grids with many components) feel like molasses even though the server is idle.

Tune the session section of app/etc/env.php:

'session' => [
    'save' => 'redis',
    'redis' => [
        // ...
        'disable_locking' => '1'
    ]
],

If you prefer to keep locking, raise max_concurrency (default 6) instead of disabling it. Locking exists to prevent lost session writes, so disable it consciously and watch for side effects on flows that write session data in parallel.

Fix 5: Send Sales Emails Asynchronously

Order, invoice, and shipment emails are sent synchronously by default, inside the request that triggers them. A slow SMTP connection then shows up as a slow “Submit Order” or invoice save in the admin:

bin/magento config:set sales_email/general/async_sending 1

Cron picks the emails up within minutes of the event.

Fix 6: Audit Third-Party Modules in Admin Events

Extensions hook admin saves, grid rendering, and login events. The expensive pattern to hunt for: synchronous HTTP calls in observers, such as an ERP sync firing on every order view or a license check calling home on admin login. Disable suspects one at a time on staging and re-measure the slow action. Profiling with New Relic or a PHP profiler shortens the hunt when the module list is long. Watch the logs while testing, because half-removed modules leave errors behind. Our Magento 2 issues FAQ covers several of them.

Fix 7: PHP Settings That the Admin Feels Most

Without a page cache in front, the admin benefits disproportionately from a well-configured PHP:

• OPcache sized generously: opcache.memory_consumption=512 or more, with opcache.validate_timestamps=0 in production (redeploys must then restart PHP-FPM).
• Realpath cache: realpath_cache_size=10M and realpath_cache_ttl=7200, because Magento resolves thousands of file paths per request.
• Current PHP version: the JIT compiler in PHP 8.3/8.4 helps long admin operations like mass actions and imports. Version support per release is listed in the pillar guide.

Keep the Database Lean

Admin grids filter and sort large tables directly. Two habits keep them responsive:

• Archive or clean up old quotes and logs. Stale quote rows accumulate quickly on busy stores, and Magento’s cron cleanup settings (Stores → Configuration → Sales → Checkout → Shopping Cart) control their lifetime.
• On Adobe Commerce, enable order archiving to keep the working grid small. On Open Source, keep grid tables fast with async indexing (fix 2) and let admins filter by recent date ranges by default.

Still Slow? Measure It

If the checklist above does not move the numbers, the bottleneck is likely specific to your store: one module, one query, one oversized table. A structured Magento performance audit profiles the exact requests your team complains about and returns a ranked list of fixes with expected impact.