This is the complaint we hear from operations teams rather than from owners: the shop is quick enough for customers, but editing a product takes forever and the order grid crawls. It gets tolerated for months because it does not obviously cost money.
It does cost money, just quietly. An hour a day of waiting across a team is a salary. And more usefully for diagnosis: a slow admin with a healthy storefront tells you the cache is doing its job and the problem sits in the database or in background processing. That narrows things considerably.
Why the admin and the storefront fail differently
Storefront pages are cached. A category page is rendered once and then served from full page cache to everyone after that, so the expensive work happens rarely. The admin has no such luxury: every grid, every filter and every save hits the database live, because the data has to be current by definition.
So the storefront hides database problems and the admin exposes them. If your storefront is fast and your admin is not, you have almost certainly found a database or indexing issue rather than a frontend one.
The order and product grids
Grids are the usual suspect. They filter, sort and count across large tables, and they get slower in a way that is easy to miss because it happens gradually as the catalogue and order history grow.
- Grids that were fast at 5,000 orders can be painful at 100,000, without anything having changed.
- Custom columns added by extensions often bring a join or a subquery that runs on every page of the grid.
- A category with many products can be slow to open in the admin because of how the product count is calculated.
The fix depends on which of these applies, which is why measuring beats guessing. Sometimes it is an index on a column. Sometimes it is an extension that should not be doing what it does. Occasionally it is archiving old orders, which Magento supports and few stores use.
Indexers running at the wrong moment
If your indexers are set to update on save, every product change triggers reindexing while you wait. On a small catalogue nobody notices. On a large one, saving a product becomes a coffee break, and a bulk import becomes an afternoon.
Cron that is not running
Cron is the background worker: it processes indexing, sends emails, cleans up caches and handles queued work. When it stops, nothing errors loudly. Work quietly piles up, tables grow, and everything that touches those tables gets slower.
We find dead cron more often than any other single operational problem, and almost never because someone noticed. It shows up as a store that has been getting slower for months with no obvious cause.
Logging that nobody turned off
Magento can log customer visits and product views to the database. It is off by default in recent versions, but stores that have been upgraded over the years often still have it on from an older configuration.
Those tables grow without limit and are joined into reports. If your admin got slow around the time your traffic grew, this is worth ruling out before anything more complicated.
The order to work through it
- Check cron. If it is not running, fix that first, because it changes everything downstream.
- Check indexer modes. Move to update by schedule where appropriate.
- Check whether visitor and product view logging is enabled, and how large those tables are.
- Profile the specific grid that is slow, because the cause is often one column added by one extension.
- Only then consider hardware or configuration, since throwing memory at a query problem rarely helps.
A slow admin is one of the more satisfying things to fix, because the improvement is immediate and the people affected notice within an hour.