Speeding Magento 2 with Varnish: How Full‑Page Cache Works and When to Use It

Problem: Heavy PHP Overhead on Catalog Pages

In a typical Magento 2 store, each product or category page requires a full PHP request, database queries, and rendering of blocks. On a busy site, this can push response times to 1–2 seconds, hurting SEO and conversion rates.

Magento ships a Full Page Cache (FPC) that stores the entire rendered page as static HTML. However, the default FPC is served by PHP, so it still incurs the overhead of a PHP process for every request. The question is: how can we move that caching into the HTTP layer to avoid PHP entirely?

Why Varnish Matters

Varnish is a high‑performance HTTP accelerator that can serve cached pages directly to the client. When Magento’s FPC is configured to work with Varnish, the first request to a page is processed by PHP, cached by Magento, and then stored in Varnish. Subsequent requests bypass PHP entirely, resulting in sub‑200 ms response times for most catalog pages.

Varnish also allows fine‑grained control over cache invalidation, ACLs, and backend health checks. It is a proven solution in e‑commerce environments that need to scale under heavy traffic.

Setting Up Varnish with Magento

Prerequisites

• Magento 2.4.x installed and accessible via a public domain (e.g., https://store.com).
• Varnish 6.x (or newer) installed on the same host or a dedicated edge server.
• Root access to edit Varnish configuration and restart the service.
• Magento CLI access as the web server user (usually www-data).

Step 1 – Enable Full Page Cache in Admin

Navigate to Stores → Configuration → Advanced → System → Full Page Cache and set Cache Lifetime to a value such as 86400 (seconds). Save and clear the cache via System → Cache Management or run:

bin/magento cache:flush full_page

Step 2 – Configure Magento’s Varnish Settings

In the same configuration screen, set Varnish Host to 127.0.0.1 and Varnish Port to the port Varnish listens on (default 6081). Save again.

Step 3 – Export the Varnish Configuration

Magento provides a VCL (Varnish Configuration Language) file that contains the necessary backend definition and caching rules. Run:

bin/magento setup:config:set --varnish-vcl-path=varnish/default.vcl

This writes the VCL to varnish/default.vcl. Verify the backend default block points to your PHP‑FPM socket or port (commonly 127.0.0.1:8080 or /var/run/php/php8.1-fpm.sock).

Step 4 – Deploy the VCL to Varnish

Copy the generated VCL to Varnish’s configuration directory (e.g., /etc/varnish/default.vcl) and restart Varnish:

# cp varnish/default.vcl /etc/varnish/default.vcl
# systemctl restart varnish

Ensure the Varnish service is running and listening on the configured port.

Step 5 – Verify Cache Hits

Use curl to inspect the response headers. A cache hit is indicated by the X-Magento-Cache-Debug: HIT header. Example:

curl -I http://store.com/product/123

Expected output (snippet):

HTTP/1.1 200 OK
X-Magento-Cache-Debug: HIT
Cache-Control: max-age=86400, public

If the header shows MISS or is absent, double‑check the VCL backend definition and that Varnish is correctly routing to Magento.

Concrete Example: Caching a Product Page

Assume cache_lifetime is set to 86400 in app/etc/env.php:

'cache_lifetime' => 86400,

After a user requests https://store.com/product/123 for the first time, Magento renders the page, stores the HTML in its internal cache, and sends it to Varnish. Varnish writes the response to its own cache. The next request for the same URL will hit Varnish directly, returning the cached HTML in under 200 ms.

Trade‑offs & Limitations

• Dynamic Blocks: Magento replaces blocks that depend on user state (e.g., cart totals, personalized recommendations) with placeholder tags. These placeholders are rendered on the fly by PHP, so the page still incurs a PHP request for that portion. If your store relies heavily on personalized content, consider using block caching or custom VCL rules to preserve those blocks.
• Cache Invalidation: When many products change (price updates, stock changes), Magento may need to flush large parts of the cache. Varnish will then serve stale content until the next invalidation cycle. Use the Cache Management admin or bin/magento cache:clean to target specific cache types.
• SSL Termination: If Varnish terminates HTTPS, you must configure SSL certificates and ensure the backend points to the correct HTTPS port. Misconfiguration can expose sensitive data or break HTTPS sessions.

Next Steps

• Explore Cache Management in the admin to schedule regular cache flushes or to clear only the full page cache.
• Use varnishstat and varnishlog to monitor cache hit rates and backend health.
• Consider advanced VCL customizations: setting hash_data for customer groups, or using sub vcl_recv to add ACLs for logged‑in users.
• For production, deploy Varnish behind a load balancer and use vcl_fetch to implement cache purging via HTTP PURGE requests.

By following these steps, you can leverage Magento 2’s Full Page Cache with Varnish to dramatically reduce page load times, improve SEO, and handle higher traffic volumes without compromising the dynamic nature of your storefront.