Caching overview and configuration options
Adobe Commerce uses multiple caching layers to reduce repeated processing, lower database load, and improve response times. These layers operate at different points in request and asset delivery:
- Application caching stores generated or processed data using Commerce cache types.
- HTTP full-page caching stores complete HTTP responses before they reach the Commerce application.
- L2 caching can add a local cache on each web node in front of shared remote cache storage.
- Static content caching allows browsers to reuse CSS, JavaScript, images, and other static resources.
This page provides a conceptual overview of these layers and links to their configuration guidance. For backend choices, implementation details, and version-specific settings, see Cache backend options and storage reference.
Caching layers
Application caching
Commerce application caching is organized as:
cache type → cache frontend → cache backend
A cache type identifies the kind of data being cached, such as configuration, layout, block HTML, or full-page content. A cache frontend connects one or more cache types to storage. A cache backend provides the storage implementation.
You can assign different cache types to different frontends when separate cache settings or storage are required. For configuration details, see Configure cache frontends and types.
Full-page HTTP caching
HTTP full-page caching stores complete responses at the HTTP or CDN layer. For production deployments:
- Adobe Commerce on-premises—Adobe recommends Varnish for full-page caching. Varnish operates as a reverse proxy in front of the web server.
- Adobe Commerce on Cloud infrastructure uses Fastly for the edge and full-page caching layer. Cloud infrastructure does not use a separately managed Varnish service.
L2 caching
L2, or two-level, caching adds a local cache on each Commerce web node while retaining shared remote cache storage. Frequently accessed data can be served locally, reducing communication with the remote cache in multi-node deployments.
L2 configuration and supported implementations vary by Commerce version and deployment type. For details, see L2 cache configuration.
Static content caching
Commerce can improve browser caching for static resources such as CSS, JavaScript, and images by adding a deployment version to their URLs. When the content changes, the URL changes, causing the browser to request the new resource instead of using an older cached copy.
Deployment-specific configuration
The following configuration tasks vary by deployment type.
The following tasks apply to all deployment types:
- Configure cache types and frontends Configure cache frontends and types to associate cache types with cache frontends.
- Configure L2 caching—L2 cache configuration.
- Configure browser cache invalidation for static content—Static content signing and browser cache invalidation.