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, Adobe strongly recommends Varnish, an HTTP accelerator that serves cached pages directly from memory. 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. Adobe strongly recommends Varnish for production environments because it is significantly faster than the built-in full-page cache.

NOTE
Varnish operates as a reverse proxy in front of your web server and does not require changes to the Commerce cache backend configuration.

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:

Configuration options

Cache configuration is stored in two files:

  • <magento_root>/app/etc/di.xml – The global dependency injection configuration. Modify this file to change the provided default cache frontend.
  • <magento_root>/app/etc/env.php – Environment-specific configuration. Modify this file to configure custom cache frontends. This file overrides the equivalent configuration in di.xml.

For details on frontend-to-type mapping and cache configuration syntax, see:

recommendation-more-help
commerce-operations-help-configuration