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
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 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.
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.
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
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.
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.