Magento 2 Cache Management: Benefits, Problems, Solutions

According to Google, one second of page load can reduce site conversion by up to 20%. With a long enough wait for a response from the server, a person might give up and opt for another resource. Every moment matters, especially relating to online stores. Page caching helps optimize this process.

Today, we'll walk through why cache management matters for your store, what problems it solves, when it's worth adding extra tooling like a cache warmer, and why a cache hit on one layer of Magento's stack doesn't guarantee one on the next. If your cache is already set up and you're chasing a specific problem, see our guide to common Full Page Cache issues instead.

Table of Contents

• How Magento cache works
• How to distinguish between page loads from the server and cache
• How cache usage impacts online business
• How the default Magento cache system works
• Magento's other cache types
• How pages are warmed using a Magento 2 Cache Warmer
• Why a cache hit on one layer doesn't mean a hit on the next
• More cache isn't always the answer

How Magento cache works

How fast a page loads has a real effect on how visitors feel about a website: it's much easier for a fast site to win users over. Various tools and approaches serve to reduce page load time: code optimization, image compression, and caching play an important role in the fight for seconds.

For example, if the pages are static, as in the early years of the Internet, when the page is a mere HTML document with already written content, caching isn't an issue. Given a request for this page, the finished document is immediately returned. No challenging operations, no processing.

In modern systems, including Magento, pages are dynamic. That is, ready-made full-fledged pages are not directly stored on the server. Setting aside the special case of pre-built landing pages, a page is assembled from components: something is drawn in blocks, some data requests are made to the database, and certain calculations are performed. Then everything is collected on one page and sent out.

Even if each of these operations takes a little time, they sum up and increase the page loading time.

How to distinguish between page loads from the server and cache

To solve the problem of slow page loads, caching is used. This is saving a copy of the finished page in the cache. Consequently, when a person requests a page, they do not have to wait for it to be assembled from scratch.

How noticeable is the difference?

Page loading speed is affected by various parameters: server load, volume of content, number of images, scripts, database requests, and their complexity.

However, all these operations are not performed when a page is cached. The cache system simply checks whether the page is in the cache and, if so, immediately returns it. As a result, the difference in loading time can easily be several times shorter.

You can easily verify this in practice. Open Developer Tools > Network in your browser and load the page. If you are sure it is not cached, then opening it for the first time, you can see the download time: the Time to First Byte (TTFB) parameter.

The second time, the page will be loaded from the cache, so the time for all subsequent downloads will be shorter.

Thus, you can clearly see the difference in loading between non-cached and cached pages from the server. To track this across your whole store rather than one page at a time, see our guide to Magento's cache hit rate.

How will this affect the overall performance of the store? Let's take a look.

How cache usage impacts online business

Fast loading of online store pages with caching provides several valuable advantages.

Time savings through faster loading

This is the main advantage, and everything else follows from it. First, the page load time is shorter, which reduces the risk of lost conversions. Second, it improves the impression of site visitors (user experience), allowing them to quickly move from page to page in search of the necessary data. Third, page caching helps reduce the load on the server.

Improved SEO performance

Performance is a separate part of site evaluation for search results. Load speed affects many of the key web metrics that this score is based on.

For example, the SEO ranking index increases, which improves the store's position in search results.

Download speed directly affects the following parameters:

• Time to display the first content. The first part of the assessed time is always the Time to First Byte (TTFB). The smaller it is, the less the overall time of this metric and the total score, respectively.
• Speed index. The faster the page loads, the speedier the search bot will open it, scan it, and move on to another page. The more pages this site has cached, the faster crawlers can scan the whole site.

Better website availability

Stable access to the online store is another important advantage of using a cache.

Imagine the server stops responding for a short period of time. Visitors will still see the cached pages of your store instead of an error notification, and in most cases won't even notice anything was wrong. They can keep browsing and buying while the server recovers.

How the default Magento cache system works

So, we've defined the benefits of page caching. Now, let's examine the main aspects of the default Magento Cache system and how you can influence its effectiveness. The first version of Magento did not have a built-in page cache. If the owners of online stores wanted to speed up the website in this way, they had to use third-party modules. The second version of Magento already has a separate type of cache: Full Page Cache, which uses the built-in cache system by default.

Its peculiarity lies in its file-based nature: cached pages are stored in the file system, so this caching system may run slower than others.

This can be a good option if you have a small or medium-sized online store where changes do not happen very often. If possible, Magento recommends using an external cache system such as Varnish, one of the fastest available. However, there are nuances here: it needs the correct setup.

The choice at the admin level is really between two caching applications - Built-in and Varnish. Redis isn't a third option alongside them; it's a faster storage backend you can point the Built-in application to instead of the file system. We benchmarked the real difference between Built-in and Varnish across 12 live stores, and which one you actually need in Magento 2 Full Page Cache vs. Varnish.

Every cached page also has an identifier based on more than just its URL: store, currency, customer group, and similar parameters all get their own cache entries, and Magento clears them automatically as content changes (by default, every 24 hours or sooner if a product or category is updated). For the full mechanics of TTL, cache clearing, and per-visitor cache variations, see our deep dive on common Full Page Cache issues.

Not all pages in Magento need to be cached: cart, checkout, and account pages are excluded by default since their content is unique to each visitor. The same guide above covers how to find and fix incorrectly excluded blocks using the cacheable="false" attribute.

We have examined the main principles by which the default cache system in Magento works. Is that enough for an e-commerce business? Yes, especially a small one where the pages don't change often. However, the caching speed will not be very high.

How to optimize this process? The solution is to warm up the cache: a process where some utility, service, or module forces a page to be cached before a real user visits it in the browser.

Let's take a closer look at its working principle.

Magento's other cache types

Full Page Cache is only one of Magento's 12 built-in cache types. The others matter too, and mixing them up is a common source of "why isn't this working" support tickets:

• Config: collects settings from every module's config.xml.
• Layout: the compiled page layout assembled from all your modules and theme.
• Block HTML: the rendered HTML of individual blocks.
• Collections data, Reflection data, DDL (database structure), EAV types and attributes, Translations, and three integration-related caches round out the list.

Each of these has to be cleared on its own. Flushing Full Page Cache doesn't touch them. Run bin/magento cache:status to see the full list and current state for your store.

This isn't just a formality.

Why a cache hit on one layer doesn't mean a hit on the next

In our support experience, the most confusing incidents come from mixing up which layer of the cache stack actually needs attention:

• Redis eviction mistaken for "Varnish not caching." A store shared one Redis instance between sessions, Block HTML/Config/Layout, and Full Page Cache, with maxmemory-policy allkeys-lru. Once session data filled the memory, Redis quietly evicted Full Page Cache entries under LRU pressure. Varnish correctly reported MISS and fell through to PHP. The VCL was fine; Redis was the actual bottleneck. The fix: separate Redis databases (or instances) for sessions and Full Page Cache, with maxmemory-policy noeviction for the cache one.
• A direct redis-cli FLUSHDB breaking a cache warmer's own bookkeeping. Flushing Redis directly (instead of through Magento) empties the cache but never fires the clean_cache_by_tags event, so a cache warmer's own page-status table still thinks everything is warm. Visitors get cache misses while the warmer reports everything fine. Always flush through Magento (bin/magento cache:flush) so every layer hears about it.
• Full Page Cache warmed, but the store is still slow. After a deployment, Full Page Cache fill rate looked perfect, but response times didn't improve. The cause: setup:di:compile had cleared the generated code, but Block HTML and Layout cache were never flushed for the new deploy, so every page still had to rebuild its blocks from scratch on first render even though the page itself served from cache.

The pattern across all three: a hit at one layer (Varnish, a warmer's status table, Full Page Cache) doesn't guarantee a hit at the next one down. Magento's caching stack has at least four independent layers: Varnish, Full Page Cache (Redis or file), Block HTML/Layout/Config (Redis), and the PHP opcode cache. Each needs its own check.

How pages are warmed using a Magento 2 Cache Warmer

If you want online store users to load pages faster, you can use cache warmers: third-party modules, console or server utilities, or web services built on top of Magento.

A cache warmer handles the initial request phase by simulating a visit. As a result, the cache chain looks like this:

1. The module sends a request to the server.
2. The page is being built and cached.
3. Real requests from the browser or from search bots receive an already cached page, which shortens its download time.

In other words, such a tool collects site pages (or works on a prepared list of pages) and warms them up in the cold cache.

If a page is cleared from the cache, the latter should pick it up on time and re-cache it for a repeated update.

Therefore, a cache warmer enhances the loading speed for real visitors. Since the number of operations on the server’s behalf decreases, the waiting time for the user is notably reduced. This subsequently increases customer satisfaction and store conversion.

Of course, in addition to this basic function, cache warmers can provide extra benefits. We will provide examples based on our module.

Magento 2 Full Page Cache Warmer by Mirasvit: additional features to boost performance

Full Page Cache Warmer increases page loading speed and minimizes server load.

The module works with any cache system supported by Magento: built-in file cache, Varnish (recommended by Magento), Redis, LiteMage, and FishPig's Bolt FPC.

What are its advantages, and what additional opportunities can it provide to an e-commerce business?

1. Flexible Magento cache management.

You can adjust which pages should be warmed up first. It could be high-traffic content, best-selling product pages, or key landing pages. Due to this, the cache always contains the most important data, which minimizes loading delays. You can also completely exclude certain pages from the cache warm-up queue, for example:

• Categories with a large number of applied filters.
• With marketing GET parameters.
• All pages of a certain type (for example, each related to the shopping cart).

2. Performance and cache optimization

Full Page Cache Warmer helps avoid server overload due to flexible performance tuning. It provides the ability to control the frequency of requests, launch caching at times of low load, and efficiently use the cache for multi-stores, avoiding duplicate copies of pages. This reduces the load on the server and ensures a stable download speed.

3. Automatic monitoring and advanced caching.

The extension automatically monitors cache clearing and instantly warms up pages so that users and search bots always get relevant content. It also allows you to cache those page elements the standard Magento system ignores, which speeds up their loading too.

This matters most for large stores, where unmanaged caching can add load or leave important pages uncached.

More cache isn't always the answer

Magento's built-in caching gets small and medium stores most of the way there; cache warmers and a well-understood cache stack matter most once your catalog, traffic, or deployment frequency grows.

One honest caveat from our support experience: the fix for a caching problem is rarely "cache more aggressively." In the cases where merchants hit real limits, from an ERP syncing prices every few minutes to a CDN layered on top of Full Page Cache, the right move was almost always to change the caching strategy (what gets cached, when, and by which layer), not to pile on more warming.