A Simple Guide to Understand How Caching Works in Magento 2

Some of the things that make Magento a desirable e-commerce platform are its flexibility and scalability. Store owners are free to add any number of products they like to the website for selling. The downside to this obvious advantage is that the more products the website is going to have, the more the website will get overloaded, and the slower the website will load and run. Maintaining a huge range of products on the website can impede the website’s performance, thus affecting the browsing and shopping experience of buyers, and even reducing the conversion rates. Because, let’s face it, no shopper likes to wait for more than a couple of seconds, let alone minutes, for the website pages to load.

The 12 Default Cache Types in Magento 2

Magento 2 serves to provide a lot speedier stores than its predecessor. The Enterprise, as well as Community editions of the platform, already comes equipped with different performance features to improve website loading time and user experience. Here are the 12 default cache types that are available in Magento 2 and their respective functions:

Configuration (code name: config)

The Magento system collects configuration information from across all modules/config.xml files, merges them all together, and stocks the merged result into the configuration cache. Configuration cache also consists of specific store settings that are stored in the database and file system. It’s recommended to clean or flush the configuration cache type whenever any changes are made to the configuration files.

Layout (code name: layout)

The layout cache compiles the page layouts from all components. The layout.xml components are compiled from all the components. Because the cache contains compiled page layouts, or the layout building instructions, it would need flushing or cleaning in case of modifications to layout files.

Collections Data (code name: collections)

The complete chain of database queries, or rather the results of database queries, are contained into the collections data cache type. Magento offers automatic cleaning up of this cache, but data insertion into any segment of this cache is also feasible. Your custom modules may be built using logic that lead to entries that can’t be automatically cleaned up by Magento, in which case you’ll need to flush or clean collections cache manually.

Blocks HTML output (code name: block_html)

Featuring HTML page fragments per block, this cache type needs flushing or cleaning after any changes are done to the store view layer.

DDL (code name: db_ddl)

This cache pertains to the database schema of the Magento system containing all the custom changes made to the schema. Whenever any new custom changes are made to the database schema, this cache needs to be cleaned or flushed. Even though Magento does automatic clean up of the cache, it can’t do so for the schema updates that haven’t been made by itself, meaning the custom updates.

Entity Attribute Value (code name: eav)

All the metadata related to the entity attributes are collected into the EAV cache type. Examples include, site search settings, store labels, attribute rendering, etc. Usually, there’s no need to clean or flush EAV cache.

Reflection (code name: reflection)

This cache type contains all of the reflection data of the API interfaces with the purpose of removing any dependency between the customer module and the WebAPI module.

Translations (code name: translate)

As the name suggests, the translations cache type caches the merged translations from across all modules.

Integration Configuration (config_integration)

The compiled integrations are cached into this cache type so it follows naturally that if you add any new integrations or change the existing ones, you’ll need to flush or clean this cache type.

Integration API Configuration (code name: config_integration_api)

This cache type deals with the compiled integration APIs. All the API configurations of the store’s integrations are cached here.

Web Services Configuration (config_webservice)

This is the cache of the web API structure of the website.

Page Cache (code name: full_page)

One of the most important cache types, page cache, is the cache for the generated HTML code, or put simply, generated HTML pages. The full HTML page output is stored in this cache. As a result, any subsequent request for the cached page will be met much faster without putting excessive load on the server.

The page wouldn’t have to execute a bunch of code and access database to retrieve data every time it’s requested, it will be fetched from the cache, directly for display, with the help of full page cache by Magento 2. So whether it’s the products pages, categories pages, or CMS pages, they can all be made to load faster with full page cache.

This cache directly impacts the website browsing experience of the user. It’s crucial to always keep it enabled so that the response time of the pages remains optimal. Remember to keep cleaning or flushing this cache any time you make changes to the HTML structure of the website pages.

More About Full Page Cache in Magento 2

Given its major significance, let’s delve deeper into the page caching mechanism in Magento 2 platform.

Magento 2 has a default page caching method of its own on the server, a PHP reverse proxy in the page cache library that serves as a middleman of sorts between the website and the visitors. The in-built caching method of Magento 2 is better suited for use by developers in their development environment, or by small, low volume e-commerce websites. The use of external caches, like Varnish and/or Redis, is recommended in production environment to get significant noticeable improvements in website performance.  

Varnish cache is an open source HTTP accelerator, or web application accelerator, that caches files, or parts of files, in memory. Varnish caches the static contents to process the future, similar HTTP requests in a faster and more efficient way. Assets like images, CSS code, HTML code, and JavaScript code that are cached by Varnish either expire after a predefined time interval or get replaced by their updated versions.

Varnish cache offers the feature of Edge Side Includes (ESI) , which makes it possible to allocate a different caching policy for individual fragments. This includes assigning each of them separate lifespans and endpoints. A useful feature considering some parts of a web page can be cached for a long time (e.g. up to a week) whereas other parts of the web page need to be renewed by the hour.

Redis, on the other hand, is a back-end cache solution that can be used to replace Magento 2’s default Zend_Cache_Backend_File. Redis gives great results in performance for high traffic Magento websites and in multi-server environments.

Magento 2 supports Redis and Varnish out of the box, meaning there is no need to install any assisting dependencies to use these caching options. Some addition and adjustment in configuration is all that’s needed to get them working. Using Varnish for full page cache and Redis for back-end cache gives excellent overall website performance results.

Leave a reply

Your email address will not be published. Required fields are marked *