Magento 2 Full Page Cache: Configuration, Varnish Setup, and Performance (2026)

TL;DR

Full Page Cache = stores rendered HTML pages and serves them without executing PHP or querying the database. Cuts page load from seconds to milliseconds. Requires proper backend (Varnish for production) and correct block configuration.

Perfect for: Production stores wanting fast page loads, high-traffic catalogs, stores with multiple store views and customer groups.

Not ideal for: Development environments where you need to see changes in real time, pages with heavy personalization on every element.

What Is Magento Full Page Cache?

Full page cache (FPC) saves the complete HTML output of a page after its first render. Every subsequent request for that page gets a stored copy of the page, skipping PHP execution, database queries, and template rendering. The content is loaded from the cache instead of being generated from scratch.

Without FPC, Magento must generate the page from zero for each request. A single product page can trigger 200+ database queries. Full-page caching stores entire pages so the application does not need to repeat this process. Adobe Commerce and Magento Open Source websites generate thousands of pages, all using the same FPC architecture. The cache in Magento 2 supports two backends:

• Built-in (file system): Stores cached pages as files in var/page_cache/. No extra software needed. Suitable for development and low-traffic stores.
• Varnish: A reverse proxy cache storage layer that sits in front of your web server, serving cached pages before requests reach PHP. The recommended backend for production stores.

Both backends use the same cache tag system for invalidation. The difference is speed and scalability. For stores running on managed hosting, Varnish comes pre-configured.

How Magento 2 Full Page Cache Works

When a visitor requests a page for the first time, the system processes the full stack: PHP execution, database queries, compiled page layouts, and template rendering. FPC stores this generated page using a unique cache key based on the URL, store view, customer group, and currency.

On the next request, the page can be read directly from the cache. The initial page load triggers full processing, but every request after that is served from the cache in milliseconds. Once cached, the page should be served without touching PHP.

This is different from browser cache, which stores assets on the visitor's device. FPC operates at the server level and benefits all visitors, not just returning ones.

Types of Cache in Magento 2

Before diving into FPC configuration, it helps to understand where full page cache fits within the broader cache system. Magento 2 ships with 17+ types of cache, each handling a different layer. Here is the list of cache types most relevant to performance:

Run bin/magento cache:status for the full list of cache types on your installation. Adobe Commerce adds additional types like target_rule and customer_notification.

Full page cache is the most impactful cache type for frontend performance. The other types reduce backend processing. You can view and manage all enabled cache types from the command line using bin/magento cache:status, or through System > Cache Management in the admin.

Managing the cache means knowing which specific cache to target. Flush the cache for all types only when necessary. For most updates, clearing a specific type (like full_page) is enough.

Varnish vs Built-in Magento Cache

This is the single most important FPC decision. The varnish cache option delivers far better results than the file-based alternative:

Recommendation: Use Varnish for every production store. The built-in cache is a fallback, not a real alternative for live traffic.

Varnish supports Edge Side Includes (ESI), which allows caching the page shell while loading dynamic blocks (like the mini-cart) separate. This means pages with some personalization can still benefit from full page cache.

For a deep comparison, see our Full Page Cache vs Varnish analysis.

Full Page Cache in Magento: Settings and Configuration

Step 1: Full Page Cache Management Settings

When you switch your Magento store to production, configure FPC through the admin:

1. Log into the Admin panel.
2. Navigate to Stores > Configuration > Advanced > System.
3. Expand the Full Page Cache section. These are the Magento full page cache settings that control how the full page cache system operates.
4. Set Caching Application to either:
   • Built-in Application for file system cache storage
   • Varnish Caching for Varnish (recommended)
5. Set TTL for public content to 86400 (24 hours, the default).
6. If using Varnish, configure the Varnish Configuration sub-section:
   • Access List: IPs allowed to send PURGE requests (usually 127.0.0.1 or your internal network range)
   • Backend host: 127.0.0.1
   • Backend port: 8080 (or your web server port behind Varnish)
7. Click Save Config.
8. Export the VCL file: Click Export VCL as Varnish 6 to generate the configuration file.

Check the cache status from the command line: bin/magento cache:status. This shows all enabled cache types.

Step 2: env.php Configuration

The app/etc/env.php file controls the cache backend at the application level. In a Varnish setup, Varnish handles page serving while Redis stores cache tags for invalidation. The relevant section:

'http_cache_hosts' => [
    [
        'host' => '127.0.0.1',
        'port' => '6081'
    ]
],
'cache' => [
    'frontend' => [
        'page_cache' => [
            // Redis stores cache tags so Magento can
            // send targeted PURGE requests to Varnish
            'backend' => 'Magento\\Framework\\Cache\\Backend\\Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'port' => '6379',
                'database' => '1',
                'compress_data' => '0'
            ]
        ]
    ]
]

The http_cache_hosts array tells the system where to send PURGE requests when cache invalidation is needed. The page_cache backend uses Redis for tag storage: when a product changes, Magento looks up which cache tags are affected and sends PURGE commands to Varnish for those pages. Varnish serves the actual cached pages from RAM. Each cache key maps to a page variant (URL + store view + customer group).

Important: After editing env.php, you need to clean or flush this cache. Run bin/magento cache:flush to flush this cache type. See our clean vs flush guide for when to use which command.

Step 3: TTL Best Practices

TTL (Time To Live) controls how long cached pages remain valid before Varnish considers them stale.

Shorter TTLs reduce cache hit rates without improving freshness. Tag-based invalidation handles product and category changes, so a long TTL is safe.

For stores with flash sales, live stock updates, or frequent promotion banner changes: Consider TTLs of 7200–28800 seconds (2–8 hours) and rely on cache tags for content changes. Test your hit ratio after adjusting.

Clear the Magento Cache via Command Line

Common cache clear commands for managing the Magento 2 cache:

bin/magento cache:clean full_page    # Clear FPC only
bin/magento cache:flush              # Flush the cache (all types)
bin/magento cache:enable full_page   # Enable FPC
bin/magento cache:disable full_page  # Disable FPC

These commands clear the cache and remove invalidated entries. Flushing removes everything, including valid entries. For most situations, cache:clean for the targeted type is sufficient. You can also manage this using the Magento admin under System > Cache Management. Keep this cache enabled on all production stores.

Cache Tags and Invalidation

Cache tags track which pages contain which content. When a product changes, the system identifies all pages tagged with that product's ID and removes outdated pages from the cache.

How Cache Tags Work

Every cacheable page block generates cache tags. A product page for SKU "shirt-red-m" might carry these tags:

• cat_p_42 (product ID 42)
• cat_c_15 (category ID 15)
• cms_b (CMS blocks on the page)
• store_1 (store view)

When you save product ID 42, PURGE requests go to Varnish for all pages tagged with cat_p_42. Category listing pages, the product detail page, and any CMS page featuring that product all get invalidated. The cache management system handles this without manual intervention.

Cache Invalidation Triggers

Key insight: You do not need to flush everything after most changes. The tag system handles surgical invalidation. The cache management system cleans up this cache automatically when content changes through the admin.

You can also invalidate cache programmatically using the \Magento\Framework\App\CacheInterface in custom modules.

Cacheable vs Uncacheable Pages

The system classifies every page as cacheable or uncacheable based on the page blocks it contains. One uncacheable block makes the entire page uncacheable.

Default Cacheable Pages

Default Uncacheable Pages

How Blocks Control Cacheability

In layout XML, any block with cacheable="false" makes the entire page uncacheable:

<block class="Vendor\Module\Block\Custom"
       name="custom_block"
       template="Vendor_Module::template.phtml"
       cacheable="false" />

Warning: Third-party extensions often add cacheable="false" blocks to global layouts like default.xml. This disables full page cache across your Magento website. To find problematic blocks:

grep -r 'cacheable="false"' app/code/ vendor/ app/design/

Check the results against default.xml (all pages), catalog_product_view.xml, catalog_category_view.xml, and cms_page_view.xml. If an extension adds cacheable="false" to default.xml, contact the developer. This is a bug.

Private Content and Hole Punching

Not all page content can be public. The mini-cart, welcome message, and recently viewed products differ per customer. This is handled with a two-layer approach:

1. Public content: The page HTML, cached in Varnish. Identical for all visitors.
2. Private content: Customer-specific data, loaded via AJAX after the page renders. Stored in browser local storage.

Varnish serves the cached page, and JavaScript fills in personalized sections after. The initial page load appears instant, and private data loads within milliseconds. You can find the private content section definitions at the bottom of the page layout XML files.

With ESI (Edge Side Includes): Varnish can fetch uncacheable blocks in a separate sub-request during page assembly. This is faster than AJAX for above-the-fold dynamic content.

Only HTTP GET and HEAD requests are cacheable. POST requests (form submissions, add-to-cart) always bypass full page cache.

Cache Hit Ratio and Performance

The difference between cached and uncached pages is dramatic. When full page cache is enabled and a request hits Varnish, it skips the entire PHP stack. FPC is the primary cache used by Magento for frontend acceleration.

Values based on typical 2.4.8 production stores with 10,000+ SKUs. Results vary by server specs, extensions, and page complexity.

A high cache hit ratio is the goal. Aim for 90%+ of requests served from cache. You can check if a page is loaded from FPC using debug headers, or monitor hit rates with varnishstat or through your hosting provider's dashboard.

Hit ratio formula: Hit Rate (%) = (Hits / Total Requests) * 100

A rate below 80% indicates problems: too many uncacheable pages, excessive cache flushing, or short TTL.

Page Cache Is Not Working: Troubleshooting

Problem 1: Pages Not Being Cached

Symptoms: High TTFB on all pages, X-Magento-Cache-Debug: MISS header on every request. The page cache is not working as expected.

Diagnosis: Check response headers from the command line:

curl -sI https://yourstore.com/ | grep X-Magento-Cache

If you see MISS on every request:

1. Check for cacheable="false" blocks in global layouts.
2. Verify FPC is enabled: bin/magento cache:status | grep full_page.
3. Confirm Varnish is running and configured in the full page cache management settings.

Problem 2: Cache Invalidated Too Often

Symptoms: Low cache hit ratio despite FPC being enabled. varnishstat shows high eviction rate.

Common causes:

• Frequent admin saves: Batch your catalog updates instead of saving products one by one.
• Cron jobs triggering reindex: Schedule reindexing during low-traffic hours.
• Low TTL: If set below 3600 seconds, cached pages expire faster than visitors return.
• Insufficient Varnish memory: Default is 256MB. Production stores need 1-4GB depending on catalog size and store views.

Problem 3: Stale Content After Updates

Symptoms: Product changes do not appear on the frontend.

Fix: Check if PURGE requests reach Varnish:

1. Verify http_cache_hosts in env.php points to your Varnish instance.
2. Check Varnish logs: varnishlog -g request -q "ReqMethod eq PURGE".
3. To clear the Magento cache manually: bin/magento cache:clean full_page.

For more on when to clean or flush, see our cache operations guide. Avoid excessive cache flushing as it forces cold page loads for all visitors.

Full Page Cache Warmer and Cache Warming

After a full flush, every page loads cold until a visitor or Google visits a page and triggers generation. A full page cache warmer extension warms up the cache by visiting pages before real users arrive. Full page cache Magento 2 stores support both built-in and third-party warming approaches.

The built-in approach: use a sitemap-based crawler. A simple script or cron can request each URL:

wget --quiet --spider --input-file=sitemap_urls.txt

What to warm first (priority order):

1. Homepage
2. Top category pages (by traffic)
3. Best-selling product pages
4. CMS landing pages

Warm per store view and customer group. Separate cache entries exist for each combination. A store with 3 store views and 2 customer groups has 6x the entries to warm.

For stores needing automation, a dedicated full page cache warmer extension handles scheduled warming, priority queues, and per-store-view warming. Several third-party extensions exist for this purpose. The warmer extension warms up the cache on a schedule so Magento must not regenerate cold pages for real visitors.

Beyond Varnish: CDN and Modern Caching in 2026

Varnish remains the standard full page cache backend for Magento. But modern production stacks combine Varnish with a CDN layer for global performance:

• Varnish + CDN (Cloudflare, Fastly, CloudFront): Varnish handles origin caching and PURGE logic. The CDN caches pages at edge locations worldwide, reducing latency for international visitors. Fastly is the CDN behind Adobe Commerce Cloud and supports Varnish VCL natively.
• CDN-only caching: Some stores skip Varnish and cache full pages at the CDN edge. This works for simpler setups but requires custom PURGE integration since Magento sends invalidation to http_cache_hosts, not the CDN API.
• Headless / PWA storefronts: GraphQL and REST API responses need their own caching layer. Redis or CDN-level response caching replaces FPC for API-driven frontends. Magento 2.4.8 improved GraphQL query caching for this use case.

For most stores, Varnish at the origin + a CDN in front is the proven stack. It combines fast invalidation with global reach.

Commerce Cache Updates in 2.4.8

Magento 2.4.8 (released April 2025) focuses on platform compatibility and stability:

• PHP 8.4 support: Full compatibility with PHP 8.4, bringing performance improvements for array operations and JIT compilation relevant to cache data handling.
• MariaDB 11.4 support: Expanded database compatibility alongside MySQL 8.4.
• Security and stability: Over 200 bug fixes and security patches across the platform.
• Improved GraphQL caching: Better coverage for headless storefronts with expanded query result caching for customer, CMS, and product media data.

The core FPC mechanism remains unchanged in 2.4.8. The main benefit is better PHP performance and broader infrastructure support.

Check our system requirements guide for the full 2.4.8 tech stack.

FAQ

What is full page cache in Magento 2?

Full page cache stores the complete HTML output of a page. Subsequent requests get the cached HTML without PHP processing or database queries. This cache type reduces page load from seconds to milliseconds.

How do I enable full page cache in Magento 2?

Navigate to System > Cache Management in the Admin. Find "Page Cache" in the list and set its status to Enabled. Or use the command line: bin/magento cache:enable full_page.

How do I disable FPC?

Run bin/magento cache:disable full_page from the command line. Or set "Page Cache" to Disabled in System > Cache Management. Useful during development when you need to see template changes in real time.

Should I use Varnish or the built-in cache?

Use Varnish for production. Built-in Magento 2 file system cache works for development and staging. Varnish serves cached pages from RAM with 5-50ms TTFB. The built-in option reads from disk with 50-200ms TTFB and cannot handle high concurrent traffic.

What causes "full page cache invalidated"?

Product saves, category updates, CMS block edits, configuration changes, and reindexing all trigger cache invalidation. Cache tags ensure only affected pages get invalidated, not everything. Check var/log/debug.log for invalidation events.

How do I check if a page is served from cache?

In developer mode, check the X-Magento-Cache-Debug response header. HIT means the page was loaded from FPC. MISS means it was generated fresh. Use browser DevTools (Network tab) or curl -sI URL | grep Cache.

What is a good cache hit ratio?

90% or higher. This means 9 out of 10 requests are served from cache. Below 80% indicates issues with uncacheable blocks, excessive flushing, or misconfigured TTL. Monitor with varnishstat or your hosting provider's tools.

Why does one uncacheable block disable FPC for the entire page?

Pages are treated as atomic units. If any page block requires per-request generation, the output becomes unpredictable. The fix: use private content (AJAX) or ESI for dynamic blocks instead of marking them uncacheable.

How much RAM does Varnish need?

Default is 256MB, which is too low for most production stores. Allocate 1-4GB depending on catalog size, number of store views, and customer groups. Each combination creates separate cache entries.

Does FPC work with headless / PWA?

Full page cache handles HTML responses. Headless storefronts using GraphQL or REST APIs use a separate caching layer. 2.4.8 improved GraphQL query result caching for this use case. For API responses, implement Redis or CDN-level caching.

Conclusion

Full-page cache is the single biggest performance lever for any Magento store. Proper configuration with Varnish, correct TTL, and clean cacheable blocks deliver sub-100ms page loads for the majority of requests.

The most common mistake is third-party extensions adding cacheable="false" to global layouts. Audit your layout files, monitor your cache hit ratio, and avoid excessive cache flushing.

For production stores, Varnish on managed hosting with Redis for tag storage is the proven stack. Combine it with a full page cache warmer after deployments, and every visitor gets a fast page from the first request.