Varnish Cache: full-page caching for high-traffic e-commerce

How Varnish works: the happy flow

When a request arrives, Varnish evaluates whether a cached response exists and whether it is allowed to be served. If it is, the response is returned from memory. The backend, the server running the application, is never queried. If no cache entry exists, or if the content cannot be cached, Varnish passes the request through to the backend and stores the response for future requests.

This is the happy flow: a visitor requests a page, Varnish computes a cache key (a hash based on the request), looks up whether a valid cached response exists, and if so, serves it directly. The backend sees none of it.

What makes Varnish configurable at this level of detail is VCL, the Varnish Configuration Language. VCL maps directly to the Varnish finite state machine: every state the request passes through (receive, hash, lookup, fetch, deliver) can be intercepted and modified. This is what gives operators fine-grained control over caching decisions. It is also what makes Varnish genuinely complex to operate well.

Challenges in full-page caching

A WordPress or Magento store is not a static website. It has logged-in users, shopping carts, personalized content, and dynamic widgets, none of which should be served from cache. Getting this right requires solving a number of structural challenges: how to handle dynamic elements, how to invalidate cached content correctly, how to segment the cache for different visitors, and how to deal with pagination and sorting.

• Dynamic elements. Parts of a page that are user-specific cannot be cached alongside the rest. The solution is hole punching via ESI (Edge Side Includes): the static parts of the page are cached, while dynamic fragments are fetched separately, either via ESI or via Ajax combined with local storage.
• Correct banning and request stapling. Content tagging and soft purging solve both challenges. Savvii recommends the use of xKey + soft purge above regular regex + banning.
• Cache key segmentation. Not every visitor should receive the same cached response.
• Pagination and sorting. Paginated and sortable content requires careful tagging to ensure that cache invalidation hits the right entries without flushing too broadly.

Why configuration is the hard part

Varnish is open source, and the community edition is what most production deployments, including Savvii’s, run on. An enterprise version exists, and Savvii holds enterprise partner status, but in practice the open source build handles everything their customers require.

The complexity is not in the software itself. It is in the configuration. Many hosting providers use Varnish, but the difference lies in the depth of knowledge. Most agencies and teams can get a basic setup running. When edge cases appear, when something breaks unexpectedly in a live environment, or when an application update silently introduces a header that bypasses caching entirely, that is where operational experience becomes the deciding factor.

Open source plugins: giving back to the community

Savvii has developed a configuration baseline for WordPress environments that handles the challenges above correctly across a wide range of setups. This baseline is available as an official open source plugin, built in collaboration with the Varnish team. For Magento, a parallel module exists with significant community contributions.

The WordPress plugin includes:

• Validated support for navigation and ESI tags
• Content tagging by post type and category ID for targeted cache invalidation
• Extended invalidation logic
• Unit tests and end-to-end tests
• A WP-CLI command to export the active VCL configuration

Open source products need active contributors. Savvii is always looking for developers who want to work on the WordPress plugin. Issues and pull requests are welcome.

Stability under pressure: Black Friday

The moments where Varnish proves its value most clearly are peak traffic events. Savvii’s customer base includes retailers with heavily seasonal patterns. Ski webshops like the largest 2 in the Netherlands, also hosted by Savvii, see enormous traffic in winter. Automotive stores peak in summer. Black Friday hits nearly every e-commerce store simultaneously.

Without a properly configured cache layer, these peaks translate directly into backend load: more PHP processes, more database connections, slower response times, and for stores that are not built to scale horizontally on short notice, downtime. And downtime is lost revenue! With Varnish correctly configured, the backend largely does not see the peak at all.

This is not a one-time configuration. Savvii reviews Varnish setups proactively ahead of high seasons because applications change. New features, plugin updates, or A/B testing tools can inadvertently introduce headers or cookies that bypass caching entirely. Catching these before peak traffic arrives, rather than during it, is a core part of what managed hosting at this level means.

Varnish versus CDN

CDNs serve a similar purpose at a high level: reduce origin load, bring content closer to the user. But the comparison with Varnish breaks down quickly once you look at the details.

CDN caching logic is constrained by what the platform exposes. For complex e-commerce environments with non-standard cookies, custom authentication, or precise invalidation requirements, that lack of control creates real problems. Large commercial CDNs act as a black box: you can influence behavior, but you cannot inspect or fully control what is happening.

Varnish, originally from Sweden and headquartered in Stockholm, is a European company. It recently launched its own CDN offering, built on the same open source foundation. For organizations that want edge distribution alongside full configurability and European data governance, this is worth evaluating.

A note on alternatives

LiteSpeed is the most commonly cited alternative in the managed WordPress space. It is a web server with built-in caching, which means it integrates more easily but offers less separation of concerns. It is also closed source, with a per-server licensing fee. Many managed WordPress providers default to LiteSpeed precisely because it requires less configuration expertise. The tradeoff is flexibility and control.

Varnish requires more from the team running it. For high-traffic e-commerce environments where caching behavior needs to be precise and predictable, that depth is what makes it the right choice.

Shared knowledge across Your.Online

Varnish sits naturally alongside the other open source technologies running through the Your.Online group: Ceph for storage, Apache CloudStack for infrastructure orchestration, BGP-to-the-host for networking. In each case the pattern is the same: adopt proven open source infrastructure, develop deep operational expertise, and share that expertise back with the community.

Toon presents regularly conferences and within the Your.Online engineering community. In December 2025 he gave an internal session on Varnish best practices.