Magento 2.4.9 Built-in FPC Bug: Why Your Cache Hits Are Still Slowing You Down

As e-commerce migration and optimization experts at Shopping Mover, we are constantly vigilant about issues that can impact the performance and stability of Magento stores. A recent discovery, highlighted in GitHub issue #41643, has brought to light a significant concern for merchants and developers running Magento Open Source or Adobe Commerce 2.4.9, particularly those relying on the built-in Full Page Cache (FPC).

The Magento 2.4.9 Cache Conundrum: A 'HIT' That Behaves Like a 'MISS'

The core of this perplexing problem lies in a peculiar behavior of Magento 2.4.9's built-in Full Page Cache. While the internal FPC mechanism correctly identifies and serves cached pages—indicated by the reassuring X-Magento-Cache-Debug: HIT header—the accompanying Cache-Control HTTP header remains stubbornly set to no-store, no-cache, must-revalidate, max-age=0. This is a critical deviation from expected behavior, where a genuine cache hit should ideally be accompanied by a Cache-Control: public, max-age=... header, signaling to browsers and intermediary caches (like CDNs) that the content is indeed cacheable for a specified duration.

Understanding the Discrepancy: Internal Logic vs. External Communication

The GitHub issue's trace provides crucial insight: Magento\Framework\App\PageCache\Kernel::buildResponse() correctly constructs a new HTTP response instance and replays the saved headers onto it. This instance is then returned up through Magento\PageCache\Model\App\FrontController\BuiltinPlugin::aroundDispatch(). However, the final response sent to the browser does not reflect these correctly set headers. This suggests a disconnect where the internal FPC logic successfully retrieves the cached content and its associated cacheable headers, but something later in the request lifecycle overrides or fails to apply these headers before the response is finalized and sent to the client.

X-Magento-Cache-Debug: MISS (first request)
X-Magento-Cache-Debug: HIT (second request)
Cache-Control: no-store, no-cache, must-revalidate, max-age=0 (both requests)

This scenario effectively negates the benefits of a cache hit at the browser and CDN level, leading to repeated full requests to the Magento server.

Reproducibility and Far-Reaching Impact

This isn't an isolated incident or a conflict with custom extensions. The issue has been confirmed on a fresh Magento 2.4.9 installation, without any custom modules, and reproduced across both the stock Luma theme and the performance-optimized Hyvä theme. This broad reproducibility suggests a fundamental flaw within the core Magento FPC implementation for this specific version, making it a critical concern for any store running 2.4.9 with the built-in FPC enabled.

The implications for Magento merchants and developers are substantial:

• Reduced Frontend Performance: Without proper Cache-Control: public headers, browsers are instructed not to cache pages locally. This means every subsequent visit to a previously loaded page requires a full request to the server, increasing load times for repeat visitors and diminishing the perceived speed of your site.
• Increased Server Load: Each request, even for a cached page, bypasses browser and CDN caching, forcing your Magento server to process the request fully. This leads to higher CPU and memory usage, especially during peak traffic, potentially causing slowdowns or even outages.
• Suboptimal SEO Performance: Page speed is a critical ranking factor for search engines. Consistently slow page loads due to ineffective caching can negatively impact your search engine rankings, reducing organic traffic and visibility.
• Poor User Experience: Slow loading times frustrate users, leading to higher bounce rates and lower conversion rates. In today's competitive e-commerce landscape, speed is paramount for customer satisfaction.
• Inefficient CDN Utilization: Content Delivery Networks (CDNs) rely heavily on cache-control headers to effectively cache content at edge locations. If Magento instructs CDNs not to store content, you lose a significant portion of your CDN's performance benefits, increasing origin server load and latency.
• Scalability Challenges: As your store grows, the inability to leverage client-side and CDN caching will severely limit your store's ability to scale efficiently without significant infrastructure investment.

What Can Merchants and Developers Do?

While we await an official fix from the Magento core team, here are some actionable insights and recommendations:

For Merchants:

• Monitor Performance Closely: Regularly check your site's loading times using tools like Google PageSpeed Insights, GTmetrix, or WebPageTest. Pay attention to TTFB (Time To First Byte) and overall page load.
• Consider External Caching Solutions: If you're experiencing significant performance degradation, consider implementing or optimizing an external caching layer like Varnish Cache (which is often recommended for Magento) or a robust CDN. These can often be configured to override or enforce specific Cache-Control headers, mitigating the impact of this bug.
• Stay Informed: Keep an eye on the official Magento GitHub repository for updates on issue #41643 and subsequent patch releases.

For Developers:

• Verify Headers: Use browser developer tools or command-line tools (like curl -I) to inspect HTTP headers on your Magento 2.4.9 pages. Confirm if Cache-Control is indeed no-store on cache hits.
• Temporary Workarounds (with caution): If using Nginx or Varnish, you might be able to implement rules to explicitly set Cache-Control: public, max-age=... for known cacheable pages. This requires careful testing to ensure no unintended side effects, especially with private content.
• Debugging the Core: For advanced debugging, trace the execution flow through Magento\PageCache\Model\App\FrontController\BuiltinPlugin::aroundDispatch() and the subsequent response handling to pinpoint where the Cache-Control header is being reset or ignored.
• Plan for Upgrades: Be prepared to apply patches or upgrade to a newer Magento version once a fix is released. This issue underscores the importance of keeping your Magento instance updated.

Shopping Mover's Perspective: The Importance of Robust Caching

At Shopping Mover, we understand that efficient caching is the backbone of a high-performing e-commerce store. Issues like this Magento 2.4.9 FPC bug highlight the complexities involved in maintaining optimal performance, especially during platform migrations or major updates. Our expertise in Magento development and migrations ensures that your store not only moves seamlessly but also operates at peak efficiency, leveraging every available optimization technique.

Whether you're struggling with performance bottlenecks, planning a Magento migration, or need expert guidance on complex integrations, the Shopping Mover team is here to help. Don't let core platform issues compromise your e-commerce success.