Is your Magento full-page cache working correctly?

When cache misses arrive together

Use the cache stampede guide to separate repeated invalidation from concurrent regeneration.

• Magento cache stampede: when many misses arrive together

First establish what should be cached

“The Magento cache is not working” can describe several different problems: repeated slow public pages, a cache status that never changes, stale content after an update, or a cart that behaves differently from the catalogue. Each needs a different check.

Full-page caching reuses eligible public HTML. Customer-specific content needs a separate design, and routes such as cart and checkout are not equivalent to a public category page. Do not try to make every response cacheable. Correct prices, session separation and personal data matter more than making a diagnostic header say HIT.

Start with one ordinary public product or category URL in a consistent anonymous session. Record the symptom and the expected behaviour. If you are mainly seeing a slow initial response, our high TTFB guide explains how to compare timings before attributing the delay to caching.

Identify which cache you are observing

A Magento installation can have browser caching, a CDN or reverse proxy, full-page caching and other application caches. A successful response at one layer does not prove another is correctly configured. Equally, a missing diagnostic header does not prove the entire cache is disabled.

Ask your technical team to map the request path and explain the evidence available from each layer. Header names and visibility depend on the implementation. Production systems may expose different diagnostics from development environments, and an intermediary may change or remove a header.

For the merchant, the useful record is the exact URL, customer state, time and visible outcome. For the developer, the next step is to correlate that observation with the relevant cache and application evidence. Keep these two levels together so the investigation stays focused on a reproducible problem.

Read the symptom before choosing a fix

• A public page is slow on every visit. Check whether comparable requests are eligible for reuse and whether the response comes from the expected layer. Compare application timings too; an apparent cache issue may have another cause.
• The first visit is slow, repeat visits are fast. Establish whether this follows a legitimate expiry or content update. A miss followed by a hit can be expected behaviour, not evidence of failure.
• A page becomes slow again immediately after updates. Correlate the timing with cache invalidation events. Find what changed before assuming that the whole cache needs replacing.
• One page type behaves differently. Compare its layout, extensions and request conditions with a similar working page. Narrow differences help avoid broad live changes.
• Content stays old after an edit. Identify the layer serving the old response and whether its invalidation path ran. Repeatedly clearing unrelated caches can obscure the cause.
• Customer-specific content appears wrong. Treat this as a correctness and potentially privacy-related issue. Do not continue tuning for speed while ignoring incorrect account or cart information.

This is an evidence checklist, not a list of confirmed causes. Save the observations before making changes so the result can be compared afterwards.

Check layout and extension behaviour carefully

Adobe documents that an uncacheable block can make the page containing it uncacheable. This makes recent layout changes and extensions relevant when a previously cacheable public page changes behaviour. The correct response is to review the block’s purpose and data, not blindly remove its cacheability setting.

A developer should trace where the block is used, what information it displays and whether it belongs in shared HTML or private content. A change that appears to improve timing can still be wrong if it exposes one shopper’s information to another or makes customer state stale.

Review the actual layout applied to the affected page, including theme customisations. Test the correction in a suitable environment with representative customer states. Functional checks should cover the behaviour the block exists to provide, not only the presence of a cache-hit header.

Reference: Adobe’s page caching and public/private content guidance.

Investigate repeated invalidation rather than flushing again

A cache must respond when relevant content changes. An investigation should distinguish normal invalidation from an unexpectedly broad or frequent pattern. Catalogue imports, integrations, scheduled activity and custom code are possible places to examine when the timing matches, but they should not be blamed without evidence.

Create a short timeline of when the public page slows down and when updates occur. Ask the technical team to identify the relevant invalidation activity and compare it with the affected pages. That can reveal whether the system is doing necessary work or unnecessarily losing useful cached responses.

A blanket flush can temporarily increase the work required to serve pages and remove useful diagnostic context. Avoid making it a repeated troubleshooting ritual on a busy store. If a scoped cache operation is required for a particular change, the person making it should understand the impact and verify the result.

Likewise, extending cache lifetimes is not automatically a fix. It may reduce rebuilds while allowing incorrect content to remain visible if invalidation is broken. Agree both freshness and performance expectations.

What a controlled cache investigation should demonstrate

Define a small set of page types and customer states. Capture the existing response behaviour, then compare the same conditions after the proposed correction. Record any differences in infrastructure, cache warmth or data between staging and production.

The outcome should explain which layer was affected, what evidence supported the finding, what changed and what remains unverified. Test that updated public content becomes visible as intended and that private information stays private. Include cart, account and checkout behaviour where the change could affect shared layout.

If more than one change is made together, be honest about attribution. A faster result after changing hosting, extensions and cache settings simultaneously does not show which change produced the benefit. A controlled sequence provides a more useful basis for future maintenance.

Get the right level of help

For an initial brief, provide affected public URLs, when the symptom started, recent deployments or catalogue activity, and whether you see slow pages or stale content. You do not need to supply a server diagnosis before contacting us.

Our Performance Investigation packages distinguish external observation from access-based investigation. Snapshot can assess public behaviour; confirming internal cache configuration and application causes requires suitable access and scope. Implementation can then be agreed through Magento performance optimisation.

If the store is unavailable rather than simply slow, use our Magento outage guide and the emergency support route. Keep credentials and customer data out of the initial message; secure access is arranged when needed.