Solving Full Page Cache Problems with Freento Full Page Cache Analyzer
When Full Page Cache performance issues strike a Magento store, they can dramatically impact user experience and conversion rates. This case study demonstrates how our internal Freento Full Page Cache Analyzer module helped identify and resolve persistent cache invalidation problems that were causing response time spikes from the expected 0.1-0.3 seconds to 1-3 seconds.
User Story
The client was experiencing spikes in Full Page Cache (FPC) performance. Frequently, when accessing the homepage or other pages, it was evident that they weren't loading from the FPC but were being served with a delay. This meant response times of 1-3 seconds instead of the expected 0.1-0.3 seconds. Refreshing the page immediately after would load it from the FPC with the correct 0.1-0.3 second response time. However, after some time, the problem would reoccur.
This issue was visible in New Relic monitoring and the browser Network tab, showing clear evidence of cache misses occurring far more frequently than expected.
Investigation Process
To investigate, we installed our internal module, Freento Full Page Cache Analyzer, for several days. The module revealed that many store pages were being returned over 100 times a day without FPC. For example, the homepage was loaded around 150 times without FPC.
This indicated that the store's Full Page Cache was being cleared frequently for many pages, for reasons unknown. The module allows for the analysis of cache tags used on pages. For the homepage, the tags were analyzed.
Next, we enabled a setting to analyze FPC tag clearings. For 24 hours, we recorded all Full Page Cache clearings, both by tag and full clearings. This generated a list of tags that were cleared and the processes that triggered these clearings. It was found that tags were being cleared during re-indexing via cron jobs.
Performance Analysis
The analysis revealed a dramatic improvement in cache performance, with homepage FPC misses dropping from approximately 150 per day to just 1-3 per day after implementing the solution.
Investigation Results
By cross-referencing the tags, we identified problematic tags that were associated with specific products. Code analysis revealed two culprits:
- A block present on multiple pages that had overly broad tags
- An import functionality that was clearing tags too frequently
| Metric | Before | After |
|---|---|---|
| Homepage FPC Misses per Day | ~150 | 1-3 |
| Average Response Time | 1-3 seconds | 0.1-0.3 seconds |
| Cache Tag Clearings | Frequent during cron | Manual/controlled |
Solutions Implemented
Primary Solution
- Replaced problematic block tags with specific, controlled tags
- Implemented manual cache clearing option via admin panel button
- Reduced tag scope to prevent unnecessary invalidations
Supplementary Improvements
- Modified import script update frequency
- Optimized cache tag management for import processes
- Reduced overall system load during automated operations
Key Freento Full Page Cache Analyzer Features
Our internal module provides comprehensive FPC analysis capabilities that standard Magento tools lack:
- Real-time FPC miss/hit tracking with detailed statistics
- Cache tag analysis and cross-referencing capabilities
- 24-hour monitoring of cache clearing processes and triggers
- Visual reporting and performance trend analysis
- Integration with existing monitoring tools like New Relic
This tool enables precise identification of cache invalidation patterns that would otherwise require extensive manual investigation.
Outcome
Performance Stability
The client's Full Page Cache for the homepage is now cleared infrequently, only 1-3 times a day due to legitimate changes in products displayed on the storefront. Response time spikes have been completely eliminated.
Monitoring Improvements
Analysis in New Relic showed that the average page response time improved significantly, with consistent performance metrics and no more intermittent slowdowns affecting user experience.
Technical Implementation Details
The key solution involved replacing the tags for the problematic block. This block didn't require frequent updates, so we assigned a specific tag to it with the option for manual clearing from the admin panel via a button.
A supplementary finding was also addressed. Through analysis of the import scripts, their update mechanism was modified to a lower frequency to reduce the load on the store. While the key solution resolved the primary issue, we opted to identify and fix this additional problem as well, as we often discover supplementary issues during our investigations.