Varnish is the single biggest performance win available to a Magento 2 store. With the full page cache (FPC) served from memory at the edge, cached pages never touch PHP or MySQL, and time to first byte drops from hundreds of milliseconds to single digits. Yet we regularly audit stores where Varnish is installed but misconfigured, silently bypassed, or caching nothing at all. This guide walks through a correct production setup.
Why Varnish over the Built-in Cache
Magento ships with a built-in FPC that stores rendered pages on disk or in Redis. It works, but every hit still boots PHP. Varnish sits in front of the web server and answers requests directly, which is why Adobe recommends it for any serious production store.
Install and Point Magento at Varnish
Install Varnish 7.x on your cache tier, then tell Magento to use it:
bin/magento config:set system/full_page_cache/caching_application 2
bin/magento config:set system/full_page_cache/varnish/backend_host 127.0.0.1
bin/magento config:set system/full_page_cache/varnish/backend_port 8080
bin/magento config:set system/full_page_cache/varnish/access_list localhost
bin/magento cache:flush
Move your web server to port 8080 and let Varnish listen on 80, with your TLS terminator (Nginx or a load balancer) in front on 443 passing to Varnish.
Export and Load the VCL
Magento generates a purpose-built VCL for you:
bin/magento varnish:vcl:generate --export-file=/etc/varnish/default.vcl
systemctl reload varnish
Do not hand-write caching rules on top of this file unless you understand the grace, saint mode and purge logic it already contains. Most “Varnish does not cache” bugs we are called in to fix turn out to be a hand-rolled VCL that contradicts Magento’s own.
Verify It Is Actually Caching
Send two requests and inspect the headers:
curl -I https://your-store.example/
You want X-Magento-Cache-Debug: HIT on the second request (enable debug mode with bin/magento setup:config:set --http-cache-hosts and developer mode headers on staging, never in production). A persistent MISS almost always means a session cookie is being set on every page, a third-party module is marking pages non-cacheable, or private content is leaking into a public block.
Purging and Cache Invalidation
Magento purges Varnish through HTTP PURGE requests when content changes, using cache tags. Make sure the access_list above matches the hosts Magento runs on, or purges will be refused and your store will serve stale content until TTLs expire. After deployments, run bin/magento cache:flush rather than restarting Varnish.
Common Pitfalls
- ESI blocks: hole-punched blocks (
<esi:include>) only work when Varnish processes ESI correctly; a broken ESI block shows up as missing mini-cart or navigation fragments. - TTL too short: the default TTL is fine for most stores; lowering it to paper over invalidation bugs makes performance worse, not better.
- Double caching: do not put another page cache or CDN HTML cache rule in front that ignores cache tags; let Varnish own page caching.
A correctly configured Varnish layer turns Magento 2 from a heavy application into a fast storefront. Measure cache hit ratio in varnishstat, keep it above 95 percent, and investigate every regression as a bug rather than a fact of life. If your store still feels slow after this, the bottleneck has moved to uncached routes such as cart, checkout and search, which is exactly where a performance audit should look next.