Today i implemented Lesti_Fpc which was a huge huge huge speed bump for the entire site. but i still struggle with the Cart and Checkout pages. load times of around 6 to 9 sec. for the cart page.

What i've done

  • Redis cache as backup for FPC
  • mysql primer and added all improvements
  • emptied cache, locks, sessions
  • running daily clean scripts for log tables and such

What can be the issue?

  • 1
    A cache didn't make your site quicker, it made cached content quick. Ditch the cache and fix the underlying performance issue. Magento should load uncached content in <1s - if you are above that, something needs to be fixed, be it template, modules or hosting.
    – choco-loo
    Oct 15, 2014 at 21:51
  • Often, cart functions are not cached for obvious reasons (changing content throughout the process) and therefore an FPC does not make up for a very poor hosting plan, underpowered server or badly misconfigured server. Aug 3, 2015 at 15:50

5 Answers 5


You are going in the wrong direction completely. If your site is slow, don't "fix" it with a cache, fix it by fixing it.

Redis cache as backup for FPC

Redis is a cache store, it won't make a site any faster, it will just improve performance of content fetched from the cache. The process of fetching from the cache isn't slow to begin with, file based caching is fast enough to not be a bottleneck, Redis won't change that (NB. Don't use file based caching, it is broken, Redis is a solution to fix another issue with cache swelling, so keep it - but it won't help your speed).

mysql primer and added all improvements

Why? Its a great utility (along with mysqltuner), but it isn't a miracle worker. The best it can do is analyse data based on what it has seen - not make an accurate or intelligent human decision as to what the bottleneck might be. Following scripts blindly like this, without understanding the consequences of what you are changing will almost certainly lead to problems and by no means give you the performance boost you seek. It could very possibly reduce performance, not improve it.

emptied cache, locks, sessions

We've been over cache != speed - but what were you expecting to happen after clearing the cache? It would obviously be slower as a result of an empty cache.

Lock files are entirely unrelated to speed, they are empty files, created during a reindex to prevent it running twice (simultaneously) over itself. FYI. Not once in 6 years have I removed a lock file in any situation.

Deleting sessions. Well, worst case, it actually makes the site faster, and then you are faced with the dilema of a fast store that never has sessions (and thus no sales) - or a slow site that people can buy from. As a diagnostic step, its going to give no tangible/reliable results. Don't delete sessions in any circumstance, ever.

running daily clean scripts for log tables and such

Housekeeping won't improve performance, especially if the site has no traffic/logs to clear down. Its certainly good practice, but isn't your issue.

Fundamentally, the issue comes down to two things.

  1. Hosting
  2. Code

If your hosting is improperly configured (which from the sounds of things, it is, given the DIY tuning of MySQL), it will dictate the baseline for performance. Your store can only ever be as fast as the infrastructure underneath it. No amount of application level tuning will fix that. Easiest way to tell is to install a demo store with sample data - and see what the performance is like. If that's slow, there's your issue.

The second issue is less clear, but not impossible to fix. Its a case of profiling your code to find the bottleneck and fix it. Start by restoring the default theme, then disabling modules one by one until speed is normal again. That's a fairly high level approach, but it will certainly get you going.

  • sometime cache is required ... so example when you do call to external API you can't do much about optimization ( ex. shipping method rates )
    – Fra
    Mar 20, 2018 at 4:02

you need to profile your cart/checkout code - enable default magento profiler or install Aoe Profiler. it will show you on what magento spends most of the time.

possible solutions for slow magento checkout:

  • disable shipping methods you don't use. if magento has to query too many external shipping gateway URLs it obviously not good for performance. If all USPS, UPS, Fedex, DHL methods is enabled it adds 2s(!) (default magento 1.9 installation with sample data) to shipping costs calculation that might happen on cart and onepage checkout pages.enter image description here
  • configurable swatches observer - adds 50ms per 1 cart items, 10items = 0.5s - disable it for checkout pages by overwriting app/code/core/Mage/ConfigurableSwatches/Model/Observer.php loadChildProductImagesOnMediaLoad function:

    public function loadChildProductImagesOnMediaLoad(Varien_Event_Observer $observer) {
      +       if(Mage::app()->getRequest()->getRouteName() == 'checkout') return;                                                  
                if (!Mage::helper('configurableswatches')->isEnabled()) { //    functionality disabled
                  return; // exit without loading swatch functionality
  • magento gift message extension adds 140ms to checkout page load time. not too much but if you don't use it - disable it.

  • try to switch cache storage from file system to database - see if it helps.

what you are doing now - FPC, cache, log cleaning - is not really a solution, you need to pinpoint the exact problem. Profiler will help.

UPDATE: If you want more details on how to speed up Magento - check out my ultimate guide with 34 tips.

  • this is the only meaningful answer on this page ... weird nobody voted it
    – Fra
    Mar 20, 2018 at 4:04

interesting... Not an expert in anyway, just sharing our journey, hope this can help someone.

We were in exactly the same situation recently, running Lesti_FPC from about 2-3 months ago, and recently noticing the site running slower and slower on add to cart, view cart, checkout. (it's being happening for a while, it's just very obvious recently)

We tried all sorts of things, truncate DB log table, prune old records from sales quote table, debugging the code.

Finally newrelic found it was Zend_Cache_Backend_File::_clean Mage_Core_Model_Session_Abstract_Varien::start

Which according to 2-3 other posts it's i/o related. So I moved our magento var folder to the RAM drive (mounting the tmpfs dev/shm to a directory and added a symlink the magento/var folder to it ).

Straight after it was done, I found it making no difference. So I did a admin >> cache management refresh on all items except Translation, Web services, seem to have done the trick.

Then further on next day, I found it was slowing down after 12 hours, and another cache refresh done the magic. So dug around somemore came acorss an article about exactly this problem. Filesystem based caching magento store running slow because magento NEVER delete the old cache files.

So followed the article and put in a shell script to remove then via cron hourly

http://haydenjames.io/pruning-magento-cache-sessions-using-cron/ is the original article


The number of enabled, even if out of date, shopping cart rules has a huge performance impact on cart and checkout pages. Make sure only the ones that are actually used are enabled.


For us, (running Mage CE 1.9+), we found our Add to Cart & Checkout pages were taking about 8 seconds to load.

Following the tip from @Adi below, I looked at our Shopping Cart Rules - we had about 16 active rules, 6 of which were no longer being used.

Making these 6 inactive, flushing the Mage cache, has resulted in our our Add to Cart & Checkout pages loading in about 2 seconds.

  • Quick update - we found load times increasing again, so now flush the sessions & cache folders daily, deleting files over a certain age on a cron.
    – Freshwebs
    Sep 22, 2017 at 13:51

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.