Store speed is usually discussed from the customer's side. But there is another side that costs money every day: when a manager waits a minute for the product list to open.
Why the admin slows down differently from the storefront
The storefront is saved by caching: a page is assembled once and served to everyone. The admin cannot work that way — every request is unique and the data has to be current. So none of the solutions that help the storefront apply here, and different ones are needed: indexes, rewritten queries, correct limits.
Typical symptoms and causes
The product list takes tens of seconds
The list query normally counts the total number of items across the whole catalogue with filters applied. Without the right indexes, on tens of thousands of products this becomes the slowest operation in the system.
Order search locks up the whole site
Searching on fields that have no index forces the database to scan the entire table. While that runs, other queries queue behind it — and the storefront starts slowing down too.
A product with many options will not save
The product form submits hundreds of fields. Once their number exceeds the server limit on input variables, some are simply discarded — the product saves, but without its options. No error is shown, and the cause takes a long time to find.
Price imports bring the server down
Processing a large file in one pass runs into memory and time limits. The correct approach is processing in chunks with progress saved between them.
What delivers the biggest effect
- Indexes matched to the actual queries your lists and filters run — not a "standard set", but what genuinely executes.
- The heaviest selections rewritten.
- Correct server limits on input field count and execution time.
- A module review: the classic find is an extension that issues a separate database query for every row in a list.
When the bottleneck is not the code
If the database and queries are already in order and the admin is still slow, the question moves to the server: memory allocated to the database, disk speed. That is server performance optimization, and there is a separate article on the diagnostic order.
Hands-on work specifically on the admin is the admin panel optimization for large catalogues service. If the storefront is slow as well, it pairs with store performance optimization, and for the database itself, MariaDB tuning.
