• Magento

Kannan Rajendiran

September 17, 2026

.

4 Min read

Magento has a reputation for being resource-heavy, and while some of that is inherent to running a full-featured enterprise commerce platform, a large share of slow Magento stores are running with caching layers misconfigured or entirely unused. Understanding what each caching layer actually does removes most of the guesswork from performance tuning.

Magento’s Caching Layers at a Glance

Full Page Cache: The Highest-Impact Layer

Full Page Cache stores complete rendered HTML for pages viewed by anonymous, non-logged-in visitors, meaning subsequent visits to the same page can be served instantly without regenerating content through Magento’s rendering pipeline. This is consistently the single highest-impact caching layer for typical storefront traffic, since most visitors browsing a catalogue are anonymous rather than logged in, particularly before checkout.

Why Varnish Matters Beyond Built-in FPC

Magento includes a built-in Full Page Cache, but Varnish, a dedicated reverse proxy cache, sits in front of the entire application and serves cached pages before a request even reaches PHP. This distinction matters under load: Varnish-served pages bypass PHP execution entirely, while Magento’s built-in FPC still requires PHP to check and serve the cache. For stores with meaningful traffic, Varnish typically delivers noticeably faster response times and better handles traffic spikes, such as festive sale periods, than relying on built-in FPC alone.

Redis for Session and Object Caching

Magento’s default file-based caching works for very low-traffic stores but becomes a bottleneck quickly as concurrent sessions increase, since file-based cache reads and writes are slower than in-memory alternatives. Redis, an in-memory data store, handles both session storage and general object caching significantly faster, and is considered close to mandatory for any Magento store expecting meaningful concurrent traffic rather than a purely optional upgrade.

Common Misconfigurations

• FPC disabled during development and never re-enabled before launch, leaving the store running without its most impactful cache layer.
• Varnish installed but misconfigured VCL rules, causing pages that should be cacheable to bypass the cache unnecessarily.
• Redis configured for sessions but not object cache, missing half the performance benefit Redis can provide.
• Cache not properly invalidated after content updates, leading admins to disable caching entirely out of frustration rather than fixing the invalidation logic.

A Sensible Tuning Order

Working through caching layers in this order addresses the highest-impact bottlenecks first, since Full Page Cache and Varnish typically account for the largest visible speed improvement for most storefronts, while Redis and OPcache provide more consistent, if slightly less dramatic, gains under concurrent load. Askan’s Magento development practice covers these tuning steps as a standard part of store optimisation work, and the team’s Magento 2.4.8 upgrade guide is a useful reference for stores also due for a version update alongside performance tuning.

Measuring Whether Tuning Actually Worked

Before and after any caching changes, measure actual page load times and server response times under realistic load, rather than relying on a single page load in a browser with no traffic. Tools that simulate concurrent visitors give a far more accurate picture of whether Varnish and Redis are actually reducing load on the application server, which is the real goal of this tuning work, not just a faster load for a single isolated visitor.

For a deeper technical explanation of how reverse proxy caching works at the HTTP level, the Wikipedia entry on web cache covers the general principles that apply to Varnish and similar tools, useful background before diving into Magento-specific configuration documentation.