SALT CITY DIGITAL
A SIMPLE GUIDE TO UNDERSTAND HOW CACHING WORKS IN MAGENTO 2
Resource
01
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:
02
CONFIGURATION (CODE NAME: CONFIG)
LAYOUT (CODE NAME: LAYOUT)
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.
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.
03
COLLECTIONS DATA (CODE NAME: COLLECTIONS)
BLOCKS HTML OUTPUT (CODE NAME: BLOCK_HTML)
DDL (CODE NAME: DB_DDL)
The complete chain of
Featuring HTML page
This cache pertains to
database queries, or rather
fragments per block, this
the database schema of
the results of database
cache type needs flushing or
the Magento system
queries, are contained into
cleaning after any changes
containing all the custom
the collections data cache
are done to the store view
changes made to the
type. Magento offers
layer.
schema. Whenever any
automatic cleaning up of
new custom changes are
this cache, but data
made to the database
insertion into any segment
schema, this cache
of this cache is also feasible.
needs to be cleaned or
Your custom modules may
flushed. Even though
be built using logic that lead
Magento does automatic
to entries that can’t be
clean up of the cache, it
automatically cleaned up by
can’t do so for the
Magento, in which case
schema updates that
you’ll need to flush or clean
haven’t been made by
collections cache manually.
itself, meaning the custom updates.
04
ENTITY ATTRIBUTE VALUE (CODE NAME: EAV)
REFLECTION (CODE NAME: REFLECTION)
TRANSLATIONS (CODE NAME: TRANSLATE)
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.
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.
As the name suggests, the translations cache type caches the merged translations from across all modules.
INTEGRATION CONFIGURATION (CONFIG_INTEGRATION)
INTEGRATION API CONFIGURATION (CODE NAME: CONFIG_INTEGRATION_ API)
WEB SERVICES CONFIGURATION (CONFIG_WEBSERVICE)
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.
This cache type deals with the compiled integration APIs. All the API configurations of the store’s integrations are cached here.
This is the cache of the web API structure of the website.
05
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.
06
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 inbuilt 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.
07
WEBSITE
https://www.saltcitydigital.com/
SALT CITY DIGITAL
SAY HELLO
lance@saltcitydigital.com ADDRESS 474 I Street, Salt Lake City, UT 84103
08
thank you. we look forward to working with you.
09