We are updating and changing our site, so we do a lot of config in the backend

But the backend is so incredibly slow (we have APC for both OPCODE and CACHE)

Is there a way to speed up the backend significantly?

  • Describe your current catalog size, orders, customers and so on, traffic + your infrastructure and hardware (all in one server, etc). What did you try to do so far? Mar 9, 2013 at 18:00
  • Does it happen on specific actions (eg saving a product) or all pages? Mar 9, 2013 at 18:37
  • I think it is as Paul describes below. Between 1-4 seconds and when you are working hard and have a specs list you want to move fast. (100o orders, 50 catalogue, APC installed)
    – snh_nl
    Mar 10, 2013 at 13:32

4 Answers 4


Admin is slower than frontend for a few reasons:

  • does not make use of too much caching (e.g. no block caching)
  • it will not use the "flat" tables to get product and category data
  • it has a lot of operations with the potential of being slow

Now, it depends what you mean by slow. If you think 1s-5s response time is too slow, there is not much you can do. But if your response time gets into the tens of seconds range, something is wrong.

As others commented, the catalog size is an important factor. The bigger it is, the longer a product save operation will take. This is not because of the product save itself but because of the fact that the indexes need to be updated. A quick way to speed the site is to set the indexers on manual. This will make the save operations reasonably fast, but it has the downside of not showing the changes in the front-end real time (this is the whole point of "on save" indexes). We have setups where we have part of the indexers set on manual (the first suspect being always catalog url rewrite) and a "reindex all" cron scheduled daily. While the site admins would be happier not having to wait ~1 day for some changes to appear on the site, it is a compromise that usually works.

Another, less common reason I have seen to slow down save operations is Enterprise Full Page Cache. Magento will try to smartly remove the cached parts related to the item you change/delete so that changes are visible instantly. This is never an issue with block caching as there cannot be too many cached entries anyway, but the full page cache, caching on url, can try to delete millions of entries at once which will be slow no matter the cache backend. We changed the code to queue the cache delete operation and execute it at cron time.

As a last reason for slow admins, maybe this is just a byproduct of the server being overloaded? While a few cached pages may appear fast, maybe all the others are slow. How is the checkout page? Faster or as slow as admin pages? You should be looking at the server load, it is cheaper and faster to increase hardware capacity than doing code changes if it makes sense.

  • Thanks Paul - I will look into some of this. Although the 1s - 5s response time you mention as being "normal" is maybe what I am refering to and was hoping there was something to make it more responsive on editing and making changes and creating new products
    – snh_nl
    Mar 10, 2013 at 13:34
  • Thanks Paul, as this is very helpful information, I have the same problem with the admin login, it takes 1 minute to login to the admin dashboard. I have 8926 products in catalogue. My server configulration is OS : Ubuntu 12.04, RAM : 4GB .. and database variables are tuned as per magentocommerce.com/boards/viewthread/4168 .. Please provide me some solution where i can work on.. Jan 21, 2014 at 11:05
  • I have APC installed there already Jan 21, 2014 at 11:13
  • I'm waiting over 2 minutes now just to save a change to the Email Template under System/Configuration/Contacts -> Email Options. This is a simple change to 1 field in 1 small database table. It should take less than 300 milliseconds. Meanwhile, frontend is fast even with 400k products. Jul 10, 2017 at 0:17
  • For me it even takes >10 seconds if I just click on "System -> Configuration" on a fresh installed Magento 1.8. I think it is just programmed poorly.
    – Black
    May 21, 2018 at 0:49

Remember it's not enough to just use APC as an object of opcode cache. It needs to be configured properly as well to handle what you throw at it. We do performance reviews of environments for clients and many times APC is basically setup with default settings. The defaults simply do not cut it for Magento. With the defaults there is not enough memory allocated to store the codebase let along used as an object cache. You end up with really high miss rates vs a near 0 miss rate. In most cases we have found you need at least 256M allocated to APC.

Here is a sample of what we generally use as a baseline:





Also you maybe running into scalability problems with the default File cache backend. When using the APC backend it really uses APC+File since APC doesn't support tags which is needed when flushing the cache by type.

Redis may fix the problem for you as it is much better at scaling. But Magento 1.8 also includes an improved File backend that doesn't have the same issues scaling, it's basically a renamed version of Colin Mollenhour's work, https://github.com/colinmollenhour/Cm_Cache_Backend_File. It maybe a better option than Redis if you are on a single server or can not install redis for whatever reason.


We have tried several things and Redis Magento is boss. Signifanct faster backend. Also, we are using TigerMin http://www.emvee-solutions.com/tigermin-tour/ to add products in bulk. They don`t support common backend operations like settings etc. but it works very fast for adding products.



The best thing we did to speed up the backend significantly is to install REDIS as a cache handler. It is now also supported in core from Magento 1.8 and up.

Nothing compares ... now it is click click clickerdy click


In addition you could consider adding Redis Session extension to also add sessions to the redis memory server ...

The best way to date to speed up backend operations is to use one and or preferably all of the following

  • enable cache in Magento
  • minify css and js
  • enable some kind of php opcode caching
  • enable cache and gzip at server level through htaccess or ngunx
  • enable Redis for cache in Magento (best!)
  • enable redis session management
  • check Out mirasvit asynchronous indexing (products now save in ms)

Good luck!

  • Merging css and js is bad because it can lead to errors according to my agency.
    – Black
    May 21, 2018 at 0:50
  • I've found the enormous number of script and xhr requests to be the biggest slow down in the Magento 2 admin. I just watched about 200 requests flow through over 25 seconds. It's unbearable...
    – Corgalore
    Nov 15, 2018 at 20:57
  • I should have known this, but closing Inspector will greatly increase the speed of loading admin pages. Since I have the Disable Cache option turned on all the time, it really handicaps the Magento 2 architecture.
    – Corgalore
    Nov 15, 2018 at 21:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.