Quick answer: Varnish Cache sits in front of your web server as a reverse proxy and stores full HTTP responses in memory so repeat visitors get pages without hitting PHP or the origin on every request. It helps most on read-heavy public pages. It hurts when you cache personalised or cart HTML by mistake. Use Varnish when origin CPU is the bottleneck and you can define clear cache rules. Skip it when a simpler page cache or CDN already meets your needs.
What Varnish is (and is not)
Varnish is HTTP acceleration software. Clients talk to Varnish. Varnish either returns a cached object or fetches from the backend (Apache, Nginx, IIS behind another proxy, and so on), stores the response according to your VCL rules and returns it.
It is not a CDN by itself. Many hosts combine Varnish at the origin with a CDN at the edge. It is not a replacement for application profiling when slow SQL is the real problem. Pair cache work with the habits in PageSpeed Insights style testing so you know whether time-to-first-byte, download weight or main-thread work is dominating.
When Varnish is a good fit
Good signals:
- Mostly anonymous traffic on product, article and category pages
- Origin CPU spikes under traffic while databases look fine
- You can purge cache on publish
- You control (or your host documents) VCL or equivalent UI rules
Weak signals:
- Highly personalised HTML for every visitor
- Tiny traffic where memory cache adds ops cost without benefit
- Team has no purge workflow and constantly sees stale prices
WordPress sites often benefit when anonymous front pages are cacheable and admin / cart / checkout bypass the cache. Object caching with Redis solves a different layer (object cache inside PHP). See Redis object cache for that piece. Varnish and Redis can coexist; they are not rivals.
Core ideas: HIT, MISS, TTL, purge
- MISS: Varnish asked the backend and stored the response
- HIT: Served from cache
- TTL: how long an object stays fresh
- Purge / ban: force removal when content changes
Start with conservative TTLs on HTML (minutes to an hour) and longer TTLs on versioned static assets. Infinite TTLs without purge discipline cause support tickets about “the old banner will not die.”
What to bypass every time
Never serve cached HTML for:
- Cart, checkout and account pages
- Admin dashboards
- Requests with authenticated session cookies you care about
- Preview URLs
- Form submissions (POST)
A common WordPress pattern: bypass when cookies like wordpress_logged_in_* or WooCommerce cart cookies are present. Exact cookie names depend on your stack; test with a logged-in browser and a private window side by side.
VCL in plain language
Varnish Configuration Language decides hash keys, bypasses and backend selection. Even if a host hides VCL behind toggles, understand:
- Cache key should usually include host and URL
- Query strings may need sorting or stripping for tracking params
- Compression and HTTPS termination might happen in front of Varnish depending on architecture
Do not paste strangers’ VCL into production without reading it. A wrong set req.hash and you leak one user’s page to another. That is a security incident, not a performance win.
WordPress-specific notes
- Page builders and personalisation plugins increase bypass needs
- Purge on post save, product update and menu change
- Avoid stacking three full-page caches (plugin page cache + host Varnish + aggressive CDN HTML cache) without a clear ownership map
- Login, preview and cart tests after every cache change
Hosting choices influence how much Varnish you must run yourself. Managed WordPress hosting sometimes includes a vetted cache layer. Custom VPSes leave VCL to you or your sysadmin.
For front-end weight after TTFB improves, keep compressing images and trimming scripts. Cache cannot fix a multi-megabyte hero image on mobile; see mobile page speed.
Measuring whether Varnish helps
Compare before and after:
- Origin CPU and PHP-FPM queue depth
- Time to first byte on anonymous pages
- HIT ratio from Varnish stats
- Error rates during purge storms
A high HIT ratio with rising complaints about stale content means TTL or purge rules are wrong, not that you need more Varnish boxes yet.
Load test carefully. Synthetic floods that bypass cookies differently than real users will lie to you.
Stale content playbook
When someone reports old HTML:
- Confirm whether they are logged in
- Check response headers for HIT/MISS age if exposed
- Purge the URL and the related sections (home, menu)
- Fix the rule that failed to purge on publish
- Only then consider shorter TTL
Training editors to soft-reload is not a strategy. Fix purge hooks.
Alternatives and companions
- Application page cache plugins: simpler on single servers, fewer moving parts
- CDN: great for static assets and global distance; HTML caching at CDN needs the same bypass care
- Nginx microcaching: short TTLs for anonymous HTML on some stacks
- Profiling and query tuning: required when MISS responses themselves are slow
Varnish shines when MISSes are reasonably fast and HITs are frequent.
Security and ops basics
- Do not expose Varnish admin ports to the world
- Restrict purge endpoints to trusted IPs or authenticated methods
- Keep backend health checks on
- Monitor disk vs memory storage backends; memory is the usual design point
- Document who can change VCL in production
Example architecture patterns
Host-managed Varnish: you toggle caching in a panel, purge from WordPress with a plugin the host supports. Good when you lack sysadmin time.
Self-managed Varnish on a VPS: you own VCL, monitoring and upgrades. Good when rules are custom and traffic is high enough to justify the work.
CDN HTML cache without Varnish: some teams skip Varnish and cache anonymous HTML at the CDN with similar bypass cookies. The principles stay the same: bypass private paths, purge on publish, measure HIT ratio.
Pick one HTML cache owner. Two systems both caching HTML without shared purge logic create “ghost banner” tickets that nobody can solve in under an hour.
Coordinator checklist for launches
Before a marketing launch that expects a traffic spike:
- Confirm anonymous home and landing pages HIT in cache
- Confirm cart and account MISS
- Purge after the final content freeze
- Watch origin CPU for the first hour
- Keep a rollback note for VCL or plugin toggles
Launches that skip this list discover cache problems in public.
FAQ
Is Varnish only for huge sites?
No. Mid-size publishers and stores use it when host CPU is the bottleneck. Tiny brochure sites often gain more from image compression than from Varnish.
Will Varnish fix a slow database?
Only indirectly by reducing how often you hit it for anonymous pages. Hot MISS traffic still needs query work.
Can we cache logged-in pages?
Rarely as full HTML. Personalised fragments need different approaches (Edge Side Includes or client rendering). Full-page cache for authenticated HTML is where teams leak data.
Does Varnish replace HTTPS?
No. TLS usually terminates at a load balancer, CDN or Nginx in front. Plan the chain deliberately.
Use Varnish when rules are clear
Varnish Cache pays off when you cache anonymous HTML on purpose, bypass private paths and purge on change. Treat VCL as production code. If you want help improving site performance architecture without guessing at layers, see Turn visitors into customers.
