All About Magento Caching - Magento 2 Backend Tutorial

Caching is a technology that can boost the performance of your website, exponentially. Many times the data doesn’t change frequently. So it is not feasible to load the data from the original source every time, increasing the system’s load.

Instead, temporary storage should be used where the data can be stored and accessed from there whenever needed if the data doesn’t change. A relatable example can be to say if a person asks you about your address, you will immediately respond because you have remembered the address. That’s how cache works.

Cache helps make the website faster and increases the SEO scores and decreases the system’s load that will directly impact its performance and customer’s shopping experience.

Each time a browser requests a page, the server has to go through many underlying processes to respond to the browser that might delay loading the web pages. Sometimes because of many requests, the system might go down.

To avoid all these issues and enhance the system’s performance, the concept of caching was introduced. The fascinating thing is that Magento 2 supports caching.

Multiple Cache Backend Solutions for Magento 2:

1. Database:

Whenever a customer visits a web page, the new records are created in cache and cache_tag tables. It is advisable to invest more effort while choosing the management system and database configuration.

Often the websites get replicated on several stores. To decrease the load, the database can be used for the caching purpose for all the nodes. Also, it does not require any additional efforts to enable it. There are two options available to do the database cache setup in Magento 2, i.e., default cache front-end and custom cache front-end.

If you have the database credentials, you can flush the cache by truncating cache and cache_tag tables without accessing the admin panel.

However, the cache data keeps on growing. Many DB requests will hit the database server, and also the data can cross 1 million in a few hours and might crash the system or increase the load impacting the performance directly.

2. File System:

By default, Magento 2 stores the cache data in the file system. Cached data is stored in files on a disk, and hence the speed depends on the disk’s reading/writing speed. Efficient storage can lead to better results. These are the folders where the cached data can be found on the server:

magento_installation_folder/var/cache
magento_installation_folder/var/page_cache

The cache can be flush directly by removing all the files from the above two folders without accessing the admin panel. Sometimes the disk reading/writing is relatively slower than the database operations.

When the device is out of inodes, new nodes can not be created or uploaded despite the free space on the disk.

3. Redis:

One of the most famous cache management systems that keep the data in the memory (RAM). It can also be used with the PHP session storage. Since RAM is used for memory storage, it is desirable to have a separate server with sufficient RAM size.

Cache tags help manage and handle the cached data efficiently, taking less time to find the requested data. Cached data can be replicated on the other servers. If the connection is lost with the primary server, the data will be taken from the replicated servers.

A separate server can host the cache storage, so Magento does not have to share its resources. However, as the central storage is a server memory, the cached data size is limited by the RAM size.

4. Varnish:

An efficient cache management system that stores the cached data in the memory. And the data here refers to web server responses. When data is loaded from the cache, the request does not even reach the server, and the cache data is loaded directly from the Varnish.

Since it stores the data in memory, it is desirable to have sufficient RAM. Magento 2 supports Varnish and hence no need for any third-party extension. And also, the requests are not handled by Magento 2 and the webserver.

However, it does not support the SSL protocol. Still, as a workaround, there is an option to configure a proxy to decrypt the traffic from customers before it reaches Varnish and encrypt the response back.

There are 5 Main Cache Blocks in Magento 2:

1. Cacheable Block:

Whenever the block’s cache_lifetime is set to a value greater than zero, it is cacheable. Websites in the eCommerce business have many similar kinds of blocks with the same content on the front-end.

This type of caching should be used when blocks are frequently reused. There are two different ways to enable this caching.

Setting cache_lifetime via a configuration

Setting cache_lifetime using XML Layout

2. Non-Cacheable block:

Contrasting to the Cacheable block, when the value of cache_lifetime is not greater than zero, the block is called non-cacheable. And by default, all the blocks are non-cacheable.

This caching type is often used when a block is used only as a child of the cacheable block’s layout hierarchy. Also, when the content is dynamic, and the same content is not used on different pages of the website.

3. Page Cache Killer:

Whenever the block’s cacheable attribute is set to False, the block is a page cache killer. If any page contains a cache page killer block that shows the entire page is not cacheable.

Some situations where the block includes the content that is updated regularly or the content displayed only once. This caching should be used. To enable this caching, set the cacheable attribute of the block node to False.

<block class = “Myblock”, cacheable = false>

4. Private Block:

Incase, when _isScopePrivate property of the block is set to true, then the block is called Private Block. Instruction is given to replace the private block with a placeholder, or a separate AJAX request receives the actual content and puts it instead of the placeholder. Whenever the block includes any private information on a cacheable page, this caching type is used. To enable this caching, set the property of the Abstract Block to true.

$this -> isScopePrivate = true;

5. ESI Block:

If in the XML Layout, the declaration of the block contains a TTL attribute, then only the block is referred to as ESI Block. When a full page cache application is set to Varnish, then only these blocks are useful.

This block is fetched by a separate Varnish request, cached, and revoked independently from the page.

To enable the ESI Block, insert a TTL attribute in the block declaration.

<block class = “Myblock”, ttl = “3600”>

Different Categories of Cache:

Page Cache: This refers to the HTML pages; hence it is essential to clean this cache regularly or at least after modifying the HTML structure.
Reflection Data: The entire reflection data for the APIs Interfaces will be flushed.
Translations: When translations from all the modules are merged, the merger cache will be clean.
Integrations Configuration: Cached the compiled integrations on your store. You should clean the cache if a new extension has been added or the original extension has been modified.
Layouts: This refers to the designs from different components. After modifying layout files, it is necessary to flush them, including the compiled page layout from various components.
Blocks HTML Output: As the name suggests, It refers to HTML page fragments per block. If the view layers are adapted, it is necessary to change flush them, including page fragments per block.
EAV Types: It refers to the metadata regarding the entity attribute value.
Database DDL Operations: No need for human involvement. It can be flushed automatically by Magento.
Web Services Configuration: Caching the web API structure of a website.
Collections Data: This refers to collecting the database queries, and Magento can clean the database queries by itself. However, there might be a situation where Magento can not clean by itself, and hence human involvement is needed.
Integrations API Configuration: Refers to Compiled integration APIs

How to Disable Custom Block Caching in Magento 2?

Caching in Magento 2 is most important for the performance of the website. However, it causes issues with a few of the features that require the dynamic content output. Every time caching can not be used, depending upon the requirements. Still, there is a way out to disable the caching for particular blocks only.

For instance, let’s say you have implemented a feature that behaves differently for different devices. When the customers will access it from mobile, and then from the desktop, the difference should be seen clearly, which is possible only when the cache is disabled.

The cache can be disabled for the entire page or can be disabled for a single block.

To disable the cache for the entire page, set cacheable = false.

To disable the cache for a particular block, you can set the isScopeProperty to true in a block class. An instruction to page cache module is given to replace the block content with the placeholder before caching. When the page is loaded from the cache, the block can be rendered via an AJAX request.

Wrapping up!!

Magento 2 page cache directly improves the performance of your website. The website should be developed to be friendly and adapt all the caching features using the cache-friendly extensions.

The website’s speed will affect the Google search results, attracting the customers leading to increased conversions and repeated purchases. Sometimes the merchant might not want to use the cache, and Magento 2 has provided the flexibility of disabling the cache.

The customers no longer have to wait for the products to load and have a better shopping experience. Interested to know more about Magento programming? Keep learning at Extensions Ninja!