Varnish for Bitrix: where the catalog loses speed
A catalog on Bitrix is assembled anew on every request: product properties, trade offers, prices with discounts, warehouse stock, sections, and smart filter.
The built-in cache helps partially — on URLs with filter parameters, pagination, and discount recalculation, it either does not trigger or is reset. The generation time of a catalog page on such URLs is measured in seconds, and every new visitor starts assembly from scratch.
At peak — newsletter, advertising, sale — this turns into a queue. The load on the catalog server grows non-linearly: database queries line up, some wait for connections to be released, and the application is busy assembling the same pages for different people.
The first sign is timeouts under peak load: some requests fail, the visitor sees an empty page and leaves.
Simply enabling cache does not solve the problem. An authorized visitor, shopping cart, personal prices, and current stock make the page unique, so the cache is reset on any product change, and nightly exports clear it entirely.
This is where Varnish comes in — a layer in front of the application that serves an already assembled page and lets a request inside only when the data is truly missing.
Next, we break down how this is addressed: which catalog sections can be served from cache, how to set up event-based invalidation so prices and stock do not become stale, and how to relieve the database load at peak.
What Varnish gives on Bitrix: response and resilience
Varnish is placed in front of the web server and serves assembled pages from memory — the application and database do not participate in such a request.
For a catalog, this is a key scenario: listings, product pages, filters, and sections are generated anew on every view, although they change rarely.
Page response time on repeated requests drops by 10–20 times: instead of full assembly with a database query, the client gets a ready response immediately.
The server can handle the same multiple of concurrent visitors — both the buyer and the search engine robot benefit from catalog acceleration.
Caching a Bitrix catalog reduces the database load many times over: one listing view means dozens of queries for properties, prices, stock, discounts, and trade offers, and when the cache is hit, they are not repeated. The freed-up resource goes to search, order placement, and exchange with 1C.
Resilience under load is the third effect. The class of failures "traffic spike → database overload → increased response time → errors instead of pages" goes away: the cache serves content while the application recovers. Price and stock updates remain manageable — reset by catalog events, not on a schedule.
Caching modes: page, block, server
Caching layers solve different tasks, and enabling them "all at once" is a sure way to get a catalog with outdated prices and stock. Below are the conditions of use and limitations of each mode, so you can choose it for the structure of a specific catalog.
| Option | When it fits | Limitations |
|---|---|---|
| Page cache | Catalog without personalization, same output for guests | Personal blocks and cart require exceptions; frequent edits rebuild the page entirely |
| Component block cache | Heterogeneous structure: listings, filters, detail pages | Correct dependencies are needed, otherwise the block gets stuck after a price change |
| Server cache (Varnish) | Reference pages, static content, high share of guest traffic | Requires tag-based purge rules and separation by user groups |
| User group-aware cache | Wholesale and retail prices, different conditions by roles | Number of variants and storage volume grow with the number of groups |
The choice of mode is determined by the catalog structure, not by default settings. In 1C-Bitrix, page and block cache work at the same level, so their lifetimes need to be separated: otherwise one layer overwrites the other and edits become visible at random intervals.
The main criterion is cache invalidation. If the 1C export is tied to the tags of information blocks and sections, a price change updates one product page, not the entire listing; we leave a full reset for rare operations such as rebuilding the catalog structure.
Setup sequence: from audit to handover of regulations
The work sequence is structured so that every change is based on measurement, not assumption. First we record the current state of the catalog, then design the caching scheme, after that configure the server and verify the result under load close to real.
We finish by handing over the regulations — so that further catalog edits do not break what has already been configured.
- Performance audit. We measure the response time of heavy catalog pages, calculate the share of requests going to the database, and find places where the cache does not trigger: filters, pagination, search, cart.
- Caching scheme. We mark out what is cached entirely, what is cached in fragments, what retention period we set, and by which events we reset. Blocks with personal data are taken out of cache.
- Server configuration for the catalog. We place Varnish in front of the web server, describe rules for static content, compression, and cookies, define a separate route for authorized users and the admin panel, and align behavior with the platform's built-in caching.
- Load testing. We run scenarios with parallel requests to catalog sections, compare response time and cache hit rate before and after, and verify that purging does not bring pages down.
- Handover of regulations. We provide the scheme, purge rules after catalog and price edits, instructions for content managers and on-duty engineers, and a checklist for changes in templates.
After that, the catalog withstands an influx of visitors and promotions without degradation, and the team knows what to update and when.
Set of configurations and documentation after implementation
After implementation, your team is left not with a "set of files from a contractor" but with a working kit that lets you read and edit the configuration without us: where the catalog is cached, where it intentionally is not, what to do when updating the CMS, and how to restore the previous mode with a single action if site behavior changes.
- Cache configuration — working rule files with comments: which branches are responsible for the catalog and categories, how long each cache lives, and how it is purged when a product is edited.
- Architecture scheme — request flow from the load balancer to the application: who serves the response from cache, where cache is bypassed, at which points it is purged, and what happens when the backend is unavailable.
- Exception rules — list of paths, cookies, and parameters that are not cached: authorization, cart, checkout, forms, personal prices. Each item has a reason, so that a new exception is added by example, not at random.
- Cache purge regulation — when and how invalidation is performed: pointwise by URL, as a list during a mass catalog import, full purge when the template changes. With an indication of who on the team initiates it.
- Maintenance documentation — what to check after a CMS update, how to add a new exception, how to verify from response headers that a page is served from cache and not rebuilt.
- Set of acceptance checks — requests that confirm an authorized buyer never receives someone else's cache, and the catalog for a guest is served instantly.
- Rollback instruction — how to return the scheme to its previous state with a single switch if behavior after edits raises questions.
We hand over the kit in your repository and with access that does not tie you to us: configurations and regulations can be developed by your own team.
Case study: catalog under load before and after configuration
Before: peak traffic broke the catalog
The catalog was assembled anew on every request: filters, sorting, and pagination repeatedly queried the database, so at peak — sale, newsletter, season — the section's response time grew tens of times, and some requests ended with a server error response.
The share of such responses reached several percent of the total: with thousands of concurrent visitors, the catalog simply looked unavailable. The hardware was not exhausted — the bottleneck was that the same page was recalculated many times.
What we changed
In front of the 1C-Bitrix platform, we placed a caching layer: ready catalog pages and static content are served by cache, and only what truly cannot be replaced goes to the application server.
Invalidation rules were tied to events — editing a price, stock, or publishing a product purges the cache pointwise, not entirely, so after a catalog update, warming takes minutes, not hours of manual work.
What changed with the same traffic
- catalog response time at peak — 6–8 times shorter, section median — four times shorter;
- share of server error responses — from percent levels to tenths of a percent;
- CPU load — almost halved, memory stopped hitting the limit on every peak;
- catalog conversion grew by about a quarter — pages stopped "hanging" on user wait.
We sustain peak traffic without boosting hardware and without cutting filters: the catalog remains complete, and rollback to previous rules takes a single restart if behavior under load turns out unexpected.
How does server cache differ from browser cache?
A copy of the page lives either on the server or in the visitor's browser — these are two different control loops. Server cache is filled once and served to everyone: Varnish keeps ready HTML in memory and relieves the database and PHP on repeated catalog requests.
Browser cache lies on a specific person's device and obeys only the caching headers that come with the response.
| Layer | Where stored | Who manages | Data freshness |
|---|---|---|---|
| Server cache | server memory | TTL, Cookie parsing, tag invalidation | reset at the moment a product or price is edited |
| Browser cache | visitor's device | Cache-Control, Expires, ETag headers | cannot be reset — wait for expiration or change the resource URL |
| System composite cache | server, layer above the database | information block settings and tags | updated when an element is saved, lives for minutes |
Caching headers are the only lever for the browser: Cache-Control sets the lifetime, ETag allows returning 304 instead of the body, Vary: Cookie separates guests from authorized users so that the cart is not served from a shared copy.
For Varnish, the same headers set the object's TTL and the set of parameters by which a request is considered unique.
Data freshness in cache is handled by invalidation: editing a product page purges related objects by tag, not the entire cache. Caching layers are arranged by increasing difficulty of purging — composite, server, browser — so short lifetimes are set where data changes frequently.
Common technical questions about catalog caching
When agreeing on a caching scheme, questions repeat: will the buyer see someone else's cart, what will authorized users see, how quickly prices and stock update after exchange with 1C, can all this be enabled on a live site. Below are short answers; details are expanded under the heading.
Will the buyer see someone else's cart?
The cart is tied to the buyer's session, so pages with its contents bypass the cache, and the block itself is loaded by a separate request after the catalog is served.
Cache for authorized users
Requests with an authorization flag are assembled separately: common blocks — catalog, product page, menu — are taken from cache, while personal prices and discounts are inserted by the application.
How do you avoid serving outdated prices and stock?
Data is kept in cache for a limited time, and when a product changes, only its fragment is purged — by section tag, not the entire catalog. The product page with the new stock is updated after the export.
Cache purge during 1C export
When the exchange completes, purging is called by the tags of changed products and sections. A full purge is not needed: it would zero out the accumulated cache and force the site to rebuild pages.
Can caching be configured without taking the site down?
Yes. Rules are assembled and tested on a copy, then enabled in stages — on a catalog section or a portion of visitors. Switching happens without restarting the service, and the storefront remains available.
Let's discuss the task: what is needed for an accurate estimate
To discuss the task specifically rather than in general terms, we need to understand how your catalog is structured and how visitors see it.
The caching scheme is built around specific routes: what we serve from cache, what depends on session and cart, and where prices and stock change most often.
Describe the task — we will clarify the details ourselves. At the start, the following help:
- which section hurts more: listing, product page, or filters;
- current configuration — web server, where Varnish is installed, how many sites and catalogs it serves;
- how content is updated: 1C exports, their frequency and volume;
- pages that must remain personal and are not cached;
- load peaks and complaints: at what point the site starts slowing down and what the buyer sees;
- access to the test environment and web server logs for the peak load period.
After the conversation, we send an estimate and work plan: the order of stages, what we do on the copy, how we test cache purge rules, and when we move to the production environment.
The project starts through the test environment — the live storefront does not change until the results are confirmed.
We fix responsibility for the result before starting: the metrics that we consider met, and the points where your approval is needed.
If bottlenecks outside caching come to light along the way, we will say so directly and propose a separate stage rather than stretching the timeline.