Admin Panel Optimization for Large Catalogs

Admin panel optimization for large catalogues

Store speed is usually discussed from the buyer’s side. But there is another side: when the product list takes a minute to load and an order search freezes the whole site, the managers’ work becomes painful — and that is time lost every day.

Typical symptoms

• the product or order list takes tens of seconds to open;
• a catalogue search freezes not only the admin but the storefront for buyers too;
• a product fails to save, or saves with an error, when it has many options;
• bulk actions stop halfway;
• a price list import brings the server down;
• the dashboard takes longer to open than any other page.

Why this is separate work

Optimizing the storefront and optimizing the admin are different tasks. The storefront is saved by caching: a page is built once and served to everyone. In the admin, caching barely works — every request is unique and the data has to be fresh. So the only things that help here are indexes, rewritten queries and the right limits.

What I do

• measure which admin pages are slow and how many queries they run;
• add indexes for the specific queries behind your lists and filters;
• rewrite the heaviest queries — including those that count across the whole catalogue;
• tune the settings that cut off saving products with a large number of options;
• move heavy operations to background processing so that imports do not block work;
• check third-party modules: a typical find is a module that runs a query in a loop for every row of a list.

About expectations

A realistic result is lists and search within seconds instead of tens of seconds. But if the catalogue keeps growing, the question will come back: at a certain scale a different server is needed, and it is better to know that in advance.

Related: storefront speed optimization — a different task that often goes hand in hand; database tuning; product import, if that is exactly what slows the admin down.