Magento 2 Full Page Cache: Varnish 7.6 and Valkey Configuration Guide
[Updated: March 20, 2026]
A 3-second page load costs you 32% of visitors before they see a single product. Full Page Cache is the single biggest performance lever in Magento 2, and most stores leave it misconfigured.
This guide covers FPC setup for Magento 2.4.8 with Varnish 7.6, the new Valkey cache backend, and HTTP/3 reverse proxy configuration.
Key Takeaways
- Magento 2 Full Page Cache stores complete HTML pages and serves them without regenerating content on each request.
- Magento 2.4.8 supports Varnish 7.6, Redis 7.2, and Valkey 8 as cache backends.
- CLI commands let you enable, disable, clean, and flush cache without touching the admin panel.
- Any single block marked
cacheable="false"makes the entire page uncacheable. - HTTP/3 requires a reverse proxy (Nginx or Caddy) in front of Varnish since Varnish does not support HTTP/3.
- Valkey 8 is a new Redis-compatible cache backend option with improved memory efficiency.
What is Magento 2 Full Page Cache?
Magento 2 Full Page Cache = a server-level caching mechanism that stores complete HTML output of pages after first generation. Eliminates repeated content generation for identical requests.
Perfect for: High-traffic stores, product-heavy catalogs, stores running flash sales or seasonal promotions.
Not ideal for: Development environments, stores with heavy personalization on every page.
FPC operates at the server level through Magento's built-in file system cache or external solutions like Varnish. When a visitor requests a page, the system checks for a cached HTML version first. If one exists, it serves the cached copy without executing PHP, querying the database, or rendering templates.
This cuts page load from seconds to milliseconds. The performance gap between cached and uncached pages is dramatic: uncached Magento pages with extensions can take 3 to 8 seconds, while cached pages serve in under 200ms.
Magento 2.4.8 supports three cache storage options: file system (built-in), Redis 7.2, and Varnish 7.6. Check the full Magento 2.4.8 system requirements for version compatibility details.
How Magento 2 Full Page Cache Works
FPC follows a predictable lifecycle from first request to cache expiration:
- First Request: A visitor hits a page. Magento executes PHP, queries the database, applies the theme, and renders full HTML output.
- Cache Storage: The rendered HTML gets stored in cache, tagged with a unique key based on the URL, store view, and customer group.
- Subsequent Requests: Magento checks the cache first. If a valid cached version exists, it serves the HTML direct without PHP execution.
- Cache Invalidation: Product updates, category changes, or CMS edits trigger targeted cache invalidation through cache tags.
- Cache Warming: Cache warmer extensions pre-generate cached versions of high-traffic pages before visitors request them.
- Dynamic Content: Blocks like cart totals, customer greetings, and recently viewed products get injected into cached pages through hole-punching (ESI tags or AJAX).
- Cache Expiration: The TTL (Time to Live) determines when cached content expires. Default is 86,400 seconds (24 hours).
The cacheable="false" Trap
This is the most common FPC pitfall. If any single block in a page layout carries the cacheable="false" attribute, the entire page becomes uncacheable. One misconfigured custom module can disable FPC for your whole store without any warning.
Check your layout XML files for this attribute:
<block class="Vendor\Module\Block\Example" cacheable="false" />
Remove it unless the block contains customer-specific data that cannot use hole-punching.
Cache Management via CLI
| Command | Purpose | When to Use |
|---|---|---|
bin/magento cache:enable full_page |
Activates FPC | After initial setup or re-enabling after development |
bin/magento cache:disable full_page |
Deactivates FPC | During development or troubleshooting |
bin/magento cache:clean full_page |
Removes expired entries | Regular maintenance without disrupting active cache |
bin/magento cache:flush full_page |
Erases all cached content | After major site changes that need complete regeneration |
bin/magento cache:status |
Shows status of all cache types | Verifying configuration during diagnostics |
Clean vs flush: cache:clean removes only outdated entries. cache:flush wipes everything. For production stores, prefer clean for routine maintenance. Use flush only after major deployments or structural changes. See our detailed clean vs flush comparison for more on when to use each command.
How to Configure FPC with Varnish in Magento 2.4.8
Varnish is the recommended FPC solution for production stores. The built-in file system cache works for small stores, but Varnish handles high traffic with lower latency.
Step 1: Choose Your Cache Backend
- Log into the admin panel. Navigate to Stores > Settings > Configuration.
- Select Advanced > System from the left menu.
- Open the Full Page Cache section.
Select either:
- Built-in Application for stores with fewer than 10,000 daily visitors
- Varnish Caching for production stores with higher traffic
- Set the TTL for public content. The default of 86,400 seconds (24 hours) works for most stores. Reduce it if your catalog changes multiple times per day.
Step 2: Configure Varnish Settings
Magento 2.4.8 requires Varnish 7.6. Earlier versions like 7.4 or 7.5 are no longer supported.
- Access List: Add IP addresses authorized to purge the Varnish cache. Use comma separation. Defaults to localhost if left empty.
- Backend Host: Enter your server's hostname for VCL config file generation.
- Backend Port: Set the backend port (standard: 8080).
- Grace Period: Define how long (in seconds) Varnish serves stale content while fetching a fresh copy. Set this to 300 seconds for a good balance between freshness and availability.
Step 3: Export and Deploy VCL
Click Export VCL to generate the Varnish configuration file. Copy this file to your Varnish server and reload the service:
varnishadm vcl.load new_config /etc/varnish/default.vcl
varnishadm vcl.use new_config
Valkey 8: The New Cache Backend in Magento 2.4.8
Magento 2.4.8 introduces Valkey 8 as a supported cache backend alongside Redis 7.2. Valkey is an open-source fork of Redis maintained by the Linux Foundation. It is wire-compatible with Redis, meaning existing Redis configurations work with minimal changes.
Why Consider Valkey?
| Feature | Redis 7.2 | Valkey 8 |
|---|---|---|
| License | Dual (RSALv2 + SSPLv1) | BSD 3-Clause (pure open source) |
| Memory Efficiency | Standard | Improved multi-threaded I/O |
| Magento 2.4.8 Support | Yes | Yes |
| AWS ElastiCache | Supported | Supported (default for new clusters) |
| Drop-in Replacement | N/A | Yes, no code changes needed |
For existing stores, Redis 7.2 remains a solid choice. For new deployments, Valkey 8 offers licensing clarity and active community development. Adobe provides official Valkey configuration documentation for setup details. See our Redis configuration guide for backend steps that apply to both Redis and Valkey.
HTTP/3 Support with Reverse Proxy
Varnish does not support HTTP/3. To serve cached pages over HTTP/3 (QUIC), you need a reverse proxy in front of Varnish that handles the protocol translation.
Architecture
Client (HTTP/3) → Nginx/Caddy (HTTP/3 termination) → Varnish (HTTP/1.1) → Magento (PHP-FPM)
Setup Steps
- Install Varnish 7.6 on the default backend port (8080).
- Configure Nginx (1.26+) or Caddy as a front-facing proxy with HTTP/3 enabled.
- Point the proxy to Varnish as the upstream backend.
- Update your SSL/TLS certificates. HTTP/3 requires TLS 1.3.
The benefit of this setup is twofold: Varnish handles cache logic and purging, while the reverse proxy handles modern protocol support and connection multiplexing. Visitors get faster initial connections through QUIC's zero-RTT handshake without sacrificing Varnish's cache capabilities.
Troubleshooting Common Cache Issues
| Issue | Diagnosis | Solution |
|---|---|---|
| Pages not served from cache | Check HTTP headers for X-Magento-Cache-Debug: HIT or MISS |
Enable debug headers in Varnish VCL. Verify no blocks carry cacheable="false" |
| Entire site uncacheable | One block with cacheable="false" in a shared layout |
Grep your codebase: grep -r "cacheable=\"false\"" app/design/ vendor/ and fix or remove the attribute |
| Cache clears too often | Third-party extensions triggering cache:flush |
Review cron jobs and extension code. Switch to targeted cache:clean with cache tags |
| Slow response despite cache | Low TTL, inefficient database queries, or heavy JavaScript | Increase TTL, optimize queries, defer non-critical JS. Check if Varnish hit ratio is above 90% |
| Stale content after product updates | Cache tags not invalidating proper entries | Verify cache tags in your custom modules. Run bin/magento cache:clean full_page after bulk imports |
| Varnish 503 errors | Backend timeout or misconfigured health checks | Increase .first_byte_timeout to 600s in VCL. Check backend health probe settings |
7 Benefits of Magento 2 Full Page Cache
1. Faster Page Loads
Cached pages serve in under 200ms compared to 3 to 8 seconds for uncached pages. This eliminates the wait time that drives visitors away. Bounce rates jump 32% when load time reaches 3 seconds (based on Google research).
2. Lower Server Load
Serving HTML from cache skips PHP execution, database queries, and template rendering. This can cut CPU usage by 80% or more during peak traffic. Your server can handle 5 to 10x more concurrent visitors with FPC enabled.
3. Higher Search Rankings
Google uses Core Web Vitals as a ranking factor. FPC improves Largest Contentful Paint (LCP) and Time to First Byte (TTFB), both critical metrics for search visibility. Read our full guide on speed optimization for more performance techniques.
4. More Conversions
A 1-second improvement in page load can increase conversions by 7% (based on Portent research). FPC delivers the most dramatic speed improvement with the least implementation effort.
5. Better User Experience
Fast pages keep visitors engaged. Quick product browsing, instant category filtering, and responsive checkout flows all depend on server-side caching to feel smooth.
6. Flexible Cache Control
Cache tags let you invalidate specific products, categories, or CMS pages without flushing the entire cache. This granular control keeps fresh content flowing without sacrificing performance.
7. Traffic Scalability
FPC absorbs traffic spikes from flash sales, seasonal campaigns, or viral social media posts. Cached responses cost almost nothing in server resources, so your store stays fast whether you have 100 or 100,000 concurrent visitors.
Pros and Cons of Magento 2 Full Page Cache
| Pros | Cons |
|---|---|
| Sub-200ms response times for cached pages | Dynamic content requires hole-punching (ESI/AJAX) setup |
| 80%+ reduction in server CPU usage | One cacheable="false" block can disable caching site-wide |
| No code changes needed for basic setup | Varnish configuration requires server administration skills |
| Handles 10x more concurrent traffic | Cache warming needed after full flushes to avoid cold starts |
| Granular invalidation via cache tags | TTL misconfiguration can serve stale content to visitors |
FAQ
What is the difference between cache clean and cache flush in Magento 2?
cache:clean removes only expired or invalidated entries while keeping valid cached content intact. cache:flush removes all cached content, forcing complete regeneration. Use clean for routine maintenance and flush only after major deployments.
Does Magento 2 Full Page Cache work with customer-specific content?
Yes, through hole-punching. Dynamic blocks like cart totals, customer names, and recently viewed products get loaded via ESI (Edge Side Includes) or AJAX requests after the cached page renders. The static HTML loads fast while personalized elements fill in afterward.
Should I use the built-in cache or Varnish?
Use the built-in file system cache for development environments or stores with under 10,000 daily visitors. For production stores with higher traffic, Varnish is the recommended solution. Varnish handles cache storage in RAM, making it faster than file-based alternatives.
What is the recommended TTL for Full Page Cache?
The default of 86,400 seconds (24 hours) works for most stores. Reduce it to 3,600 seconds (1 hour) if your catalog changes multiple times per day. Avoid setting TTL below 1 hour unless you have active cache warming in place.
How do I verify that Full Page Cache is working?
Enable debug headers in your Varnish VCL or Magento configuration. Check the HTTP response headers for X-Magento-Cache-Debug: HIT. A HIT confirms the page was served from cache. A MISS means it was generated fresh.
Can Full Page Cache cause issues with A/B testing?
Yes. A/B testing tools that modify page content server-side can conflict with FPC. Use client-side A/B testing (JavaScript-based) instead, or configure cache variations per test segment through Varnish VCL rules.
What is Valkey and should I switch from Redis?
Valkey is an open-source Redis fork maintained by the Linux Foundation. Magento 2.4.8 supports Valkey 8 as a cache backend. It is wire-compatible with Redis, so switching requires minimal configuration changes. New deployments benefit from Valkey's open-source license and active development. Existing Redis setups work fine and don't need immediate migration.
How does FPC affect Magento admin panel performance?
FPC caches frontend pages only. The admin panel runs without FPC by default. However, enabling Redis or Valkey for session and backend cache storage improves admin panel response times as well.
Summary
Magento 2 Full Page Cache transforms store performance by serving pre-rendered HTML instead of regenerating pages on every request. Magento 2.4.8 supports Varnish 7.6, Redis 7.2, and the new Valkey 8 backend. Combined with HTTP/3 through a reverse proxy, FPC delivers sub-200ms page loads that keep visitors engaged and conversions high.
For stores that want this performance without managing Varnish, reverse proxies, and cache warming, managed Magento hosting handles all server-level caching configuration out of the box.
