Magento 2 Cache: Why Developers Are Reporting Slow Magento 2 Stores

September 12, 2016 by Leah Na'aman


In the months following Magento 2’s initial release, there have been numerous reports that the platform is slower than expected. Before joining Shoppimon I had the chance to work as part of the team at Magento responsible for building Magento 2 cache features, and while many theories have been tossed around, I can almost guarantee that the cause of your eCommerce store’s speed trouble is how you’re utilizing the platform’s caching abilities.

Why Magento 2 stores are having performance issues

Your web server receives a large number of requests for assets on each web page, like CSS, JavaScript, images and HTML. That would be fine if just one page was being requested, but if you multiply these requests by potentially thousands of visitors at once, you’re looking at serious delays. And servers become overloaded, resulting in poor performance, a slow eCommerce store and irritated visitors.

Proxies cache relevant assets and store them in their own systems, which means all subsequent requests for those particular assets no longer need to be sent to your server. The result – quicker response times and improved site performance.

Magento 2 has plenty of great caching features, but a lack of familiarity with the new system is one of the major contributors to slow online stores.

To begin, the platform has two cache types, Public and Private:

Public: Allows you to cache parts of an app that are displayed in the same way for all users. (eg: images, product page). These don’t change very often, so they can be public and controlled by the store’s backend.

Private: Allows you to cache specific layout blocks of the application that are unique to individual users, like a cart or their name displayed at the top of a page. These personalized requests slow the page load speed if the system is required to fetch this information each and every time. Unlike public, private is controlled by both the back- and front-end of an application.

How to use caching with a Magento 2 eStore

Developers who have worked with Magento 1 know that on the old platform caching capabilities had to be added through extensions. These days, various cache types are built directly into Magento 2. So, it’s critical to use every type of cache available to the best of its abilities in order to achieve optimal site performance. The Magento 2 Cache Management module can be located under:

Admin Sidebar -> System -> Cache Management (Under Tools section).

As well as providing an easy way to clear cache, this page also allows developers to enable or disable specific ones. Here are the inbuilt Magento cache types you should have enabled:

Configuration (config)

Configuration details are collected from all modules, merged, and then saved to this cache. Store-specific settings kept in the file system and database are also saved to this cache.

Layout (layout)

Contains compiled page layouts for all components.

Block HTML output (block_html)

This cache contains HTML page fragments per block.

Collections data (collections)

Results of database queries.

Database DDL (db_ddl)

Tracks data organization and all relations in the database schema. If necessary, Magento cleans up this cache automatically, but third-party developers can put any data in any segment of the cache.

Entity attribute value (eav)

Contains metadata related to EAV attributes, like search settings and store labels.

Integration configuration (config_integration)

Cache for compiled integrations.

Integration API configuration (config_integration_api)

Cache for compiled integration APIs.

Page cache (full_page)

Appearance is triggered when HTML pages are generated.

Translations (translate)

Merged translations from all modules.

Web services configuration (config_webservice)

Related to web API structure.

Once Magento detects a change in the original and cached versions, an ‘invalidated’ notification appears beside the cache in question. These should be flushed to generate the newer cache

Magento 2’s out-of-the-box cache features

Magento 2 provides you with configuration files and settings that are ready to go with three different tools that can also be used for caching. When all three of these are used properly, you stand to drastically increase your Magento performance.

Full Page Cache

Magento 2 has a full page cache solution built-in for both Enterprise and Community editions, which is best suited for caching static content, such as:

  • Error Message pages
  • Constants, like About Us pages
  • Product pages
  • Category pages

It’s important to note that Magento 2 doesn’t use ESI (Edge Side Includes) for private, ‘uncachable’ content. Instead, the system fetches an almost complete page, using AJAX and JavaScript to provide the remaining personalized content (eg: Name) for the page.

Varnish 3.5/4.x

Magento 2 also supports Full Page Cache via Varnish natively. Varnish is an incredibly powerful open source HTTP accelerator, perfect for content-heavy websites like eCommerce stores. It also utilizes ESI, allowing you to assign different lifespans to individual blocks, as well as assign specific endpoints for each one. This means, for example, you can cache the majority of your homepage for a week, but have the bestsellers block cache expire every hour.

Another defining feature of Varnish is the flexibility it gives developers. It uses VCL, which allows developers to write specific policies for how incoming requests should be handled.

Nginx Web Server

One of Nginx’s key features is that it can be configured to deliver older content from its cache whenever new content can’t be accessed from the origin servers. This problem can occur if the server is busy or down and rather than display an error message or blank content to a visitor – which can potentially cause them to leave – it simply runs stale content.

Nginx is recommended for use with static files, such as JavaScript, CSS files and images.

Additional Magento 2 cache options

Redis 3.0 – Page Caching

Redis is the optional replacement for Magento 2’s default cache solution, Zend_Cache_Backend_File. Zend’s two-level backend has caused some trouble for Magento developers, while large core_cache_tag tables have created MySQL server issues, leading to decreased performance.

Since Redis can be used for PHP session storage, this allows developers to replace Memcached altogether. By using this replacement, metadata and cache records are no longer stored in separate files, reducing the number of operations that need to run.

Redis 3.0 – Tags

Redis also indexes tags in files, which means there’s no need for every cache file to undergo a full scan. This feature wasn’t available in Magento 1, but with Magento 2, developers can take any class of entities in your M2 system (eg: product class) and create a unique tag for them. This provides precise control over the way caching is used automatically by the system.


OPcache is a great tool that allows Magento developers to eliminate the PHP’s need for loading and analyzing scripts during every individual request. This code-caching module significantly improves store performance by utilizing a shared memory to store pre-gathered scripts.

Content Delivery Network

Magento 2 also has out-of-the-box support for Content Delivery Networks. CDNs support ‘edge caching,’ which aims to decrease load times further by placing the cache closer to your visitor’s web browser. With Magento’s Full Page Cache or Varnish, your eStore has one cached copy a page’s asset in its data center, but a CDN caches your content in multiple locations around the world to get your web page that bit closer to the end user. Varnish actually has edge side abilities, but CloudFlare is an alternative popular CDN solution.


As can be can be seen simply by the length of the above list, there are many capabilities available to you when setting up your Magento 2 cache on a new store. However, a lack of familiarity with this system is a huge contributing factor in slow store performance, as in order to see the boost that Magento promised, it’s critical to take full advantage of all caching options provided to you.

Magento promised us faster performance with its long-awaited 2.0 version and it does fulfill that. It provides numerous features to allow developers to create a quick-loading Magento store – it just takes some getting to know and getting used to. But once proper caching process are implemented, a store and its customers will enjoy a massive performance boost.



Wladyslaw Brodsky

Wladyslaw is an experienced e-commerce web-developer, with a certification and focus set on Magento development. He was a key developer within the Magento core team and participated in the releases of both Magento 1 and Magento 2. He has also developed for Smile and Ciklum, with a first-hand experience in all parts of e-commerce systems. He has since joined Shoppimon to help both merchants and programmers identify and fix common problems he has experienced within the industry.

  • Thank you for sharing Wladyslaw,
    A really great breakdown. But at the same time, there are plenty of other reasons, which cause slow performance and very often that little to do with optimization: bad/cheap hosting solutions, poorly optimized images, poorly optimized code. I see so many stores that fail the basic code minification tests. The worst is that these people go online and talk about how Magento is slow for them, without making a conscious effort to optimize.

    • Wladyslaw Brodsky

      Thank you for reading and commenting!

      are absolutely right in my opinion – if you’re using your toolset
      correctly, and if you have people who are very well versed in it –
      Magento 2 works much better than many are saying. The challenge is that
      it sets the bar for developers quite high, and not many people recognize
      that off the bat.

      One of the reasons I wrote
      this post is to battle this type of thinking and to show people that if
      used correctly, Magento 2 can be a system that is fast and also
      comfortable to use for both merchants and developers.

      • Thank you for sharing,
        Good stuff. It’s great to be on the same page with someone, who’s that experienced in Magento 🙂