Caching overview and configuration options
Adobe Commerce relies on a multi-layered caching architecture to reduce database load, minimize redundant processing, and accelerate page delivery. At the application level, Commerce maintains over a dozen cache types—such as configuration, layout, block HTML, and collections—each of which you can route to a dedicated storage backend like Redis or Valkey. For full-page caching in on-premises deployments, Adobe strongly recommends Varnish. Commerce on Cloud deployments use Fastly. Additional layers such as L2 caching and static content signing further improve performance for high-traffic, multi-node deployments.
This guide explains how each caching layer works and shows you how to configure frontends, backends, and advanced options to match your deployment requirements.
Caching frontends
A cache frontend is an interface between Commerce and the cache storage backend. You can define multiple frontends, each with different backend settings, and then assign specific cache types to each frontend. For configuration details, see Configure cache frontends.
Caching backends
A cache backend is the underlying storage mechanism for cached data. Commerce provides a default file-system backend, but you can configure other backends such as Redis or Valkey for improved performance and scalability. For details on the available options, see Cache backend options.
Full-page caching with Varnish
Varnish Cache is an HTTP accelerator that caches full pages in memory. For on-premises production environments, Adobe strongly recommends Varnish because it is significantly faster than the built-in full-page cache. Commerce on Cloud environments use Fastly for full-page caching instead of Varnish.
L2 (two-level) caching
L2 cache stores cache data locally on each web node while using a remote cache (Redis or Valkey) as the source of truth. This reduces network traffic between your web nodes and the remote cache, which improves performance for high-traffic sites.
Static content caching
Static content signing invalidates the browser cache for static resources (CSS, JavaScript, images) by embedding a deployment version in file URLs.
Caching terminology
Commerce uses the following caching terminology:
- Frontend – An interface or gateway to cache storage, implemented by Magento\Framework\Cache\Frontend.
- Cache types – One of the built-in types provided with Commerce (such as
config,layout,block_html,full_page) or a custom type. - Backend – Specifies the details of cache storage, implemented by Magento\Framework\Cache\Backend.
- Two-level backend – Stores cache records in two backends: a local (fast) cache and a remote (shared) cache. See L2 cache configuration.
Configuration options
For frontend-to-type mapping and cache configuration syntax:
On-premises—Cache configuration is stored in two files:
<magento_root>/app/etc/di.xml– The global dependency injection configuration. Modify this file to change the provideddefaultcache frontend.<magento_root>/app/etc/env.php– Environment-specific configuration. Modify this file to configure custom cache frontends. This file overrides the equivalent configuration indi.xml.
For details, see:
- Configure cache frontends—Associate a cache frontend with specific cache types
- Cache backend options—Backend option reference
Adobe Commerce on Cloud—Configure caching with CACHE_CONFIGURATION in .magento.env.yaml. See Best practices for Redis and Valkey service configuration.