What is Magento Varnish Cache ?

Typically 5 – 10x on TTFB under load. Built-in FPC stores serialised page payloads in Redis (or filesystem); every hit costs a Redis round-trip, an unserialise, and a PHP-FPM worker. Cold-cache TTFB is 250 – 600 ms, warm-cache TTFB is 80 – 180 ms. Varnish keeps the rendered HTML entirely in RAM in front of PHP — cached TTFB drops to 10 – 50 ms regardless of cache state, and uncached pages don’t bottleneck because Varnish serialises the slow path away from the fast path. On a store doing 200 req/min the difference between Built-in FPC and Varnish is the difference between "site is fine" and "site falls over during a sale".

Yes — they solve different problems and stack cleanly. A CDN caches at the edge (Cloudflare, Fastly, CloudFront, Akamai), but on a miss the CDN still hits your origin. If your origin is slow on a miss, every cache-fill takes 800 ms and the first visitor in every region pays for it. Varnish in front of Magento makes the origin fast on misses (sub-50 ms instead of sub-second), so CDN cache-fills are quick and the overall edge-cache hit rate climbs because pages don’t expire before they get warm. The standard performant Magento stack in 2026 is CDN → Varnish → nginx → PHP-FPM → Redis (block / session) + OpenSearch (catalogue) + MySQL.

Send a PURGE request directly: <code>curl -X PURGE -H "Host: example.com" http://127.0.0.1:6081/p/some-product.html</code>. Magento’s admin-save flow does this automatically by sending PURGE with <code>X-Magento-Tags</code> headers so Varnish can purge by tag (every page touching catalog_product_1234) rather than by URL. For manual cache flush, <code>bin/magento cache:flush full_page</code> on the Magento CLI iterates the http-cache-hosts list and issues a PURGE.* (regex-all) request to wipe everything. Always verify the purge worked by re-requesting the URL with <code>-H "X-Magento-Cache-Debug: srcache"</code> and checking for MISS → HIT transitions.

ESI hole-punching is broken — the mini-cart block is being cached as part of the full page instead of being fetched per-request. Three causes in order of frequency: (1) custom theme overrode the <code>minicart</code> block and dropped the <code>ttl="0"</code> / <code>cacheable="false"</code> attribute, (2) the generated VCL is missing <code>vcl_recv</code> ESI logic because it wasn’t regenerated after a Magento upgrade, (3) a CDN (Cloudflare in Full caching mode, Fastly without origin-shielding rules) is caching the full HTML in front of Varnish. Fix: regenerate the VCL, audit <code>cacheable="false"</code> on every block in customer_section_load, and add <code>Cache-Control: private</code> to the customer-section response. Test by logging in as two different customers in two different browsers and adding different items to each cart.

No — Hyvä is purely a frontend rewrite (Tailwind + Alpine.js replacing KnockoutJS), so the server-side rendering layer that Varnish caches is unchanged. X-Magento-Tags, ESI blocks, purge flow, VCL — all identical between Luma and Hyvä stores. Hyvä actually makes Varnish more valuable: because Hyvä ships ~85% less JavaScript, cached HTML pages render in under a second even on mid-tier Android, so the perf win from sub-50 ms TTFB is fully realised end-to-end. Build a 2026 Magento stack as Hyvä on the frontend + Varnish on the backend — they’re complementary, not alternatives.

No — pick one. Magento’s full-page cache slot is exclusive: either "Varnish Cache" or "Built-in Cache" in admin, never both. If you select Built-in Cache, you can back it with Redis for storage (faster than filesystem); if you select Varnish, the Built-in FPC layer is bypassed entirely. What you can — and should — run alongside Varnish is Redis for the <strong>other</strong> cache types: block cache, config cache, session storage, and so on. The standard performant stack is Varnish for FPC, Redis instance 1 for sessions, Redis instance 2 for default + block + config cache, OpenSearch for catalogue, MySQL for the database.