You're probably looking at a web stack that feels fine under light load and starts dragging the moment traffic spikes, cache headers get messy, or logged in traffic mixes with anonymous requests. That's where Varnish proxy cache usually enters the conversation, not as a magic fix, but as a very fast HTTP layer that can absorb repeat traffic before your app burns CPU on work it has already done. If you want to verify the impact after rollout, the practical move is to track request level behavior and user facing latency together. For teams running WordPress, our WordPress plugin can help cover adjacent optimization work like page caching, compression, and front end asset tuning while Varnish handles the reverse proxy layer.
Varnish sits in front of your application as a reverse proxy cache. A browser requests a page, Varnish checks whether it already has a valid copy in memory, and if it does, it returns that response immediately. If it doesn't, it asks the backend for the response, stores it, and serves future requests from cache.
The restaurant analogy works because it maps cleanly to production behavior. The diner is the client, the prep cook is Varnish, and the main kitchen is your origin app. If the prep cook already has the dish ready, the kitchen stays free for the orders that require fresh work.
Practical rule: A cache hit saves backend work. A cache miss still helps if the object becomes reusable for the next request.
Varnish Cache serves responses in microseconds because it stores content in RAM, not disk, which is why it can be about two orders of magnitude faster than typical backend servers for cached delivery according to the Varnish Cache introduction. That speed is why it's useful for HTML, API responses that can be cached safely, and static content that doesn't need app logic on every request.
Varnish is popular because fast caching is no longer a niche concern. The global cache server market was valued at USD 1.27 billion in 2024 and is projected to reach approximately USD 3.37 billion by 2034, expanding at a CAGR of 10.24%, according to Precedence Research on the cache server market. That doesn't make Varnish the right answer for every stack, but it does show how central low latency delivery has become.
If you're tuning application behavior as well as proxy behavior, it also helps to look at app level patterns that improve Node.js application speed, especially around what belongs in process, what belongs at the edge, and what should never be cached at all. For front end assets, a separate browser caching policy still matters, and this guide on serving static assets with an efficient cache policy is worth pairing with your proxy work.
| Term | What it means in practice |
|---|---|
| Hit | Varnish returns a stored response without calling the backend |
| Miss | Varnish has no usable object and must fetch from origin |
| Pass | Varnish deliberately skips caching for that request |
VCL isn't just a config file. It's a domain specific language for request handling. That matters because real caching logic usually depends on headers, cookies, request paths, and backend behavior.
The three common starting points are vcl_recv, vcl_backend_response, and vcl_deliver. In plain terms, vcl_recv decides what to do with the incoming request, vcl_backend_response decides whether and how the response should be cached, and vcl_deliver controls what gets sent back to the client.
| Subroutine | Purpose |
|---|---|
vcl_recv |
Inspect the request and choose lookup, pass, or other behavior |
vcl_backend_response |
Set TTL, cacheability, and response handling after backend fetch |
vcl_deliver |
Adjust response headers before the client receives the response |
A clean starting point is better than a huge borrowed file full of assumptions from someone else's CMS. This kind of baseline is enough to learn the flow:
vcl 4.1;
backend default {
.host = "backend";
.port = "8080";
}
sub vcl_recv {
if (req.method != "GET" && req.method != "HEAD") {
return (pass);
}
if (req.http.Authorization) {
return (pass);
}
return (hash);
}
sub vcl_backend_response {
set beresp.ttl = 10m;
}
sub vcl_deliver {
if (obj.hits > 0) {
set resp.http.X-Cache = "HIT";
} else {
set resp.http.X-Cache = "MISS";
}
}The common mistake is leaving TTL behavior untouched and assuming the defaults are good enough. They often aren't. A frequently missed detail is Varnish's default 120 second cache TTL, which can create frequent backend hits on dynamic WordPress style sites if you don't align TTL with your content update pattern, as documented by Gandi's Varnish cache guide.
Short TTLs don't make a site safer by default. They often just make the backend busier.
If your app sends noisy cookies, strip the ones that don't affect rendered output. If an endpoint is user specific, pass it. If a page is public and stable, cache it deliberately. That split matters more than fancy VCL tricks.
Field note: Most broken Varnish setups fail because they cache too little, not because they cache too much.
Caching stops being useful the moment stale content becomes unpredictable. The issue isn't whether you need invalidation. It's which invalidation tool matches your publishing pattern.
TTL is the passive option. You let objects expire on schedule. It's simple and safe for content that changes on a known rhythm, but it won't react instantly to edits or deploys.
PURGE is for a specific object. If one article, one landing page, or one JSON response changes, purge that URL and move on. This is the most predictable option when your CMS can emit exact paths.
BAN is broader. Instead of removing one object directly, you invalidate groups by rule. That's useful when a content change affects multiple pages, like category listings, related content widgets, or shared fragments.
A practical decision table helps:
| Method | Best use |
|---|---|
| TTL | Scheduled freshness for content with predictable update windows |
| PURGE | Single URL updates after an edit or publish event |
| BAN | Pattern based invalidation across related pages |
For sites that suffer from cold cache after invalidation, warming matters almost as much as purging. A tool like the PageSpeed Plus Cache Warmer helps refill important URLs after a purge cycle so users don't take the miss penalty first.
A Varnish rollout often looks good in the first hour. Then traffic spikes, editors publish a batch of updates, and hit rate drops because half the requests were never cacheable in the first place. Good tuning starts with that kind of messy traffic, not with a clean benchmark.
Default installs are rarely production ready. Watch memory pressure, thread saturation, backend health, and request shape. A fast cache still performs badly if it is undersized or if loose VCL rules send too many requests to pass.
Vendor benchmark data from Varnish Software shows why careful tuning pays off for cacheable objects. Memory delivery is extremely fast when the object is eligible for caching and the request path is free of cookie noise, authorization headers, and other common blockers.
thread_queue_len is one of the fastest ways to spot trouble. If it stops hovering near zero, requests are arriving faster than worker threads can process them. Check thread pool settings, backend response times, and whether a burst of misses is forcing too much work downstream.
n_lru_nuked matters too. If it climbs steadily, Varnish is evicting objects early to make room. That usually means the cache is too small for the working set, object TTLs are too long for the available memory, or you are storing too many low-value variants.
Healthy Varnish behavior is boring. Hits stay high, queues stay flat, and the backend only handles requests that need fresh generation.
Teams often ask which one is faster. The better question is faster at what.
Varnish is excellent as a dedicated HTTP accelerator when you need fine-grained cache control, flexible invalidation logic, and clear separation between cache tier and app tier. NGINX can be a better fit when you want one component handling proxying, TLS termination, and lighter caching rules with less operational overhead.
That trade-off gets sharper on dynamic workloads. Community comparisons have shown cases where NGINX can outperform Varnish on requests per second for some dynamic content patterns, especially when the workload depends less on deep cache logic and more on efficient proxying, as discussed in this benchmark comparison video. I would not treat that as a universal winner. It is a reminder to benchmark your own mix of authenticated traffic, cookies, API calls, and personalized fragments.
A common Varnish gotcha is default TTL behavior. If you leave TTL policy too loose, modern sites can serve content longer than editors expect, especially across headless frontends, JSON endpoints, and pages assembled from shared components. If you clamp TTL too aggressively, hit rate falls and the origin does more work. The right setting is usually a deliberate compromise: short TTLs for frequently edited content, longer TTLs for stable assets, and explicit rules for anything personalized or session-aware.
User-facing impact still comes back to latency. Track cache efficiency, but also keep an eye on how to improve first byte time so lower origin load translates into faster responses for visitors.
A Varnish deployment earns its keep only when it stays predictable during traffic spikes, cache churn, and backend slowdowns. A single X-Cache: HIT header proves configuration. It does not prove operational value.
Start with varnishstat. Watch cache hits and misses over time, not as a one-off snapshot, because a good hit rate during a quiet test window can fall apart once cookies, query strings, and logged-in traffic show up. The point is not to chase one perfect percentage. The point is to see whether Varnish is offloading enough repeat traffic to reduce backend work without serving the wrong content.
Then look at pressure indicators. sess_dropped usually means the cache tier is struggling to accept or process connections fast enough, and thread_queue_len shows whether worker threads are backing up under load. n_lru_nuked matters too. If it keeps climbing, your cache is evicting objects early, which often means the storage size, TTL policy, or object mix no longer matches production traffic.
These counters are more useful together than in isolation. A rising hit rate can still hide a problem if thread queues are growing or objects are being evicted too aggressively. That is one reason Varnish can look excellent in a benchmark and still disappoint on a busy site with mixed anonymous, personalized, and API traffic.
For teams exporting stack telemetry into broader observability systems, this CloudCops' guide to Prometheus monitoring is a useful reference for external checks and service validation around your cache tier.
Backend relief is only part of the result. Visitors need to see the improvement in lower TTFB, steadier page loads, and fewer latency spikes during busy periods.
Use varnishstat for cache internals, and pair it with real user monitoring for TTFB and page speed trends. Compare before-and-after baselines after TTL changes, cookie stripping, or new bypass rules. If backend load drops but user-facing latency does not improve, check the rest of the path: TLS termination, upstream app time, database saturation, or a cache policy that helps static pages but misses the dynamic requests users hit most.
That last point matters when teams compare Varnish with NGINX. Varnish often wins when cache policy is the main performance lever. If a large share of requests must pass through to origin, the gains can narrow fast, so measure user outcomes instead of assuming lower backend load automatically means a faster site.
The best Varnish setups are disciplined, not clever. Start with a small VCL that makes clear decisions about cacheable traffic, define invalidation before launch, and monitor live behavior instead of trusting a synthetic test from a single request.
Keep your bypass rules tight. Strip irrelevant cookies aggressively. Don't leave TTL on autopilot for dynamic pages. If your backend goes soft under load, use health checks and stale serving patterns instead of letting every miss turn into a timeout chain.
If you run WordPress, one practical approach is to combine Varnish with the PageSpeed Plus WordPress plugin for page caching, compression, JavaScript delay, CSS optimization, and modern image handling in the application layer where those features belong. That keeps Varnish focused on what it does best, which is fast HTTP delivery and smart request handling.
If you want to measure whether your Varnish work is improving real world performance, PageSpeed Plus gives you URL monitoring, real user metrics, site scans, and cache warming so you can connect cache changes to visible speed outcomes.