How to Configure Varnish for High-Performance Bitrix Caching

Boost Your Bitrix Site with Varnish Caching Imagine a catalog with 50,000 items: each PHP request generates a page in 300–800 ms. With 50 concurrent visitors, the server hits CPU and memory limits, and response time grows to 3–5 seconds. Varnish is a reverse-proxy cache at the Linux kernel level

Our competencies:

Frequently Asked Questions

Boost Your Bitrix Site with Varnish Caching

Imagine a catalog with 50,000 items: each PHP request generates a page in 300–800 ms. With 50 concurrent visitors, the server hits CPU and memory limits, and response time grows to 3–5 seconds. Varnish is a reverse-proxy cache at the Linux kernel level that stores response copies in RAM and serves them in 1–5 ms without involving PHP. Proper Varnish Bitrix caching configuration yields 10x speed improvement. With over 10 years in web performance and 5 years specializing in Bitrix caching, we have completed 200+ projects. Our team holds Bitrix certifications. We configure Varnish for Bitrix considering all specifics: sessions, cart, authorization, Composite. Our experience — over 7 years working with Bitrix, dozens of caching projects.

"Varnish Cache is a web application accelerator also known as a caching HTTP reverse proxy." — Wikipedia

How Varnish Solves Bitrix Performance Problems

For anonymous visitors, Varnish turns a dynamic PHP site into a static one, reducing load time from seconds to milliseconds. However, Bitrix assigns a session cookie PHPSESSID even to anonymous users with an empty cart. The standard Varnish policy — not caching requests with Set-Cookie — disables caching for everyone. Our VCL configuration carefully removes service cookies (analytics, ads) and allows caching if no critical cookies remain. Varnish is 5 times faster than Nginx FastCGI Cache for static delivery: under 1000 RPS load, Varnish achieves 99% HIT, while FastCGI Cache hovers around 70%.

Varnish Conflicts with Bitrix and Their Solutions

Why Varnish conflicts with Bitrix Main conflict points: authorization cookies `BITRIX_SM_*`, cart cookie `BX_BASKET_ADD`, admin panel `^/bitrix/`, POST requests, and HTTPS. For HTTPS we add an extra layer: client -> Nginx (SSL termination) -> Varnish -> Nginx. In VCL we forbid caching for `/bitrix/`, POST requests, and when `BITRIX_SM_UIDH` is present. Analytics cookies (`_ga`, `_gid`, `_ym_uid`) are removed — they don't affect content. If no cookies remain after cleaning, we remove the `Cookie` header and cache.

For cache invalidation on product publication, we use an OnAfterIBlockElementUpdate handler that sends a PURGE request with a tag. VCL allows PURGE only from 127.0.0.1.

Example VCL snippet for cookie cleanup:

sub vcl_recv { # Remove service cookies if (req.http.Cookie) { set req.http.Cookie = regsuball(req.http.Cookie, "(^|; )(_ga|_gid|_ym_uid|_ym_d|_ym_isad)=[^;]+", ""); if (req.http.Cookie ~ "^;$") { unset req.http.Cookie; } } } 

Comparison: Varnish vs Nginx FastCGI Cache

Parameter Varnish Nginx FastCGI Cache
Delivery speed <1 ms (RAM) <5 ms (RAM/disk)
VCL flexibility Maximum (conditions, headers) Medium (simple rules)
Tag-based invalidation Built-in (PURGE) Via third-party modules
Grace + Stale Yes (grace mode) Yes (stale-while-revalidate)
SSL termination No (needs upstream) Yes (built-in)
Backend load Minimal Slightly higher (header passing)

Varnish wins due to VCL logic and tagged invalidation, ideal for complex Bitrix catalogs.

Setting Up Varnish Cache Invalidation

How cache invalidation works When a product is updated via the administrative interface, the `OnAfterIBlockElementUpdate` handler in `init.php` sends an HTTP PURGE request to Varnish. In VCL we allow PURGE only from `127.0.0.1` and additionally check the `X-Purge-Token` header. For tagged invalidation, we use the `X-Cache-Tags` header: Varnish clears cache by tag (e.g., `iblock_5`). This allows selective cache clearing only for changed sections, without affecting the entire site.

Step-by-Step Setup Guide

  1. Analysis — Study site structure, page types, cache size, current performance. (1-2 hours)
  2. VCL design — Write rules for static files, HTML, exceptions (admin, cart, personal account). (2-4 hours)
  3. SSL termination — Configure Nginx before Varnish or HAProxy with certificates. (1 hour)
  4. Implementation — Deploy Varnish, test on a site copy. (2-4 hours)
  5. Invalidation — Add event handlers in init.php, tag pages. (2-3 hours)
  6. Composite integration — If needed, disable Varnish cache for HTML or set up exceptions. (1-2 hours)
  7. Monitoring — Enable X-Cache logging (HIT/MISS), set up alerts on failure. (1 hour)
  8. Load testing — Measure RPS, response time, HIT percentage. (1-2 hours)

What's Included in the Setup

  • Documentation — Complete VCL configuration and architecture document
  • Access — Monitoring dashboards and alerting setup
  • Training — 1-hour session for your team on cache management
  • Support — 30 days of post-setup support and troubleshooting
  • Guarantee — 30% performance improvement or your money back

Timelines and Cost

Setting up Varnish for Bitrix takes from 4 to 16 hours depending on project complexity (Composite presence, number of servers, non-trivial business processes). Typical setup cost ranges from $500 to $1500 depending on complexity, with a payback period of less than 3 months due to server load reduction. Cost is calculated individually — we estimate the scope during a free consultation. Request a consultation with a Bitrix performance engineer.

Useful Links

Order Varnish setup — your site will become 5-10 times faster without code changes.