Why 1C-Bitrix Slows Down Without Proper Cloudflare Caching
Dynamic pages in 1C-Bitrix are assembled on every request: components, authorization, cart, personalized blocks.
Until a page is served from cache, the server goes through the chain "routing → database query → template assembly" every time, and server response time grows linearly with the number of concurrent visitors.
The bottleneck in Bitrix is not the code itself but the database: the catalog, prices, stock, product properties, and sections pull dozens of related queries per page.
Cloudflare caching removes this load before the request even reaches the server.
Static assets and "guest" versions of pages are served from the nearest node, and only those requests that genuinely require personalization go to the backend: authorization, cart, checkout.
The load on the database drops severalfold, because the same HTML stops being reassembled for every visitor.
A separate problem is traffic spikes. Advertising, email campaigns, or media coverage bring hundreds of concurrent sessions, and the server starts responding more slowly at exactly the moment when the audience is most willing to pay.
Edge caching absorbs the peak: nodes take the traffic on themselves, and the database receives a steady stream instead of an avalanche.
There are also subtleties that make "just enabling cache" fail. Dynamic pages with personalization cannot be cached blindly — otherwise a visitor will see someone else's cart or an outdated price.
You need cache bypass rules, correct handling of cookies and sessions, separate cache for authorized users and guests, and careful invalidation when the catalog is updated. Without this, the site either serves incorrect data or the cache does not work at all.
Let's break down how this is addressed: which requests can be served from the edge, how to configure bypass for personalized scenarios, and how to tie cache purging to content updates in 1C-Bitrix.
What Proper Edge Cache Configuration Delivers
Reduced Server Load
Edge caching offloads repetitive requests from the infrastructure: static assets, catalog pages, and section pages served from cache never reach the web server or the database.
On a typical 1C-Bitrix project, this eliminates the majority of PHP and MySQL hits — the server stops rebuilding the same page for every visitor.
The load drops so significantly that the freed-up resources go toward dynamic content: the shopping cart, checkout, and user account area.
Page Delivery Speed
Serving from the node closest to the user reduces response time: the browser receives ready-made HTML and static assets without waiting for the backend.
Properly configured cache headers and the separation of "cacheable" from "personalized" content deliver consistent response times across all pages except those where data depends on the session. For a catalog with hundreds of items, this is the difference between waiting and instant rendering.
Peak Resilience and Fault Tolerance
During sudden traffic spikes — a promotion, a newsletter, a publication — requests are absorbed at the edge rather than crashing into the origin.
If the web server or database becomes unavailable, cached pages continue to be served, and the visitor sees content instead of an error.
This reduces the class of failures caused by origin unavailability: the site survives short outages and maintenance windows without a full shutdown.
Predictability Under Load
A properly configured edge removes dependence on one-off server optimizations: behavior under load becomes manageable rather than a matter of luck. Let's break down how this is configured for a specific project.
Caching modes and static content delivery options
Perimeter caching is not a matter of "flipping a switch" but a set of rules that determine what can be served from cache at all and what must go to the server.
In Bitrix, the same URL serves different content for a guest, an authenticated user, and an administrator, so caching rules are built around request attributes: session cookies, authorization headers, query parameters, and content type. Below are working options and their applicability boundaries.
| Option | When it fits | Limitations |
|---|---|---|
| Full-page cache | Catalog, articles, landing pages, pages without personalization | Responses with Set-Cookie and the cart cannot be cached; a bypass for authenticated users is mandatory |
| Static content cache | JS, CSS, fonts, images, media | Requires file name versioning, otherwise updates do not reach the client |
| API response cache | Reference data, catalog, filters, public methods | Only idempotent GET; POST and cart operations cannot be cached |
| Cache bypass | Personal account, checkout, admin panel, AJAX components | Bypass rules must trigger before caching rules, otherwise another user's content leaks |
Caching rules are defined in order of priority: first, exclusions for authenticated users and service paths, then targeted rules for static content and the API, and only after that a general rule for pages.
This order eliminates the situation where a guest copy of a page is served to a user with an active session.
Cache invalidation is configured separately: when a material is published or a product is changed, the cache is invalidated by tag or path rather than entirely — otherwise every content release resets the entire perimeter and the server takes a peak load.
How we implement Cloudflare caching for Bitrix
Cache implementation starts with an audit of the current configuration: we look at how the project is structured, which pages are dynamic, where authorization and the cart live, how response headers and object lifetimes are configured.
At this stage we determine what can be cached at the edge at all and what must go to the application server — otherwise the cache will start serving personalized data to other users.
Next we design the scheme: we split content into static and dynamic, define rules by request types, cookies and URL parameters, and set cache bypass for authorized sessions and service sections.
The scheme becomes a set of rules and policies that are then transferred into the edge configuration.
- Configuration audit — analysis of the site structure, personalization points, current headers and application server behavior.
- Cache scheme design — a map of static and dynamic zones, bypass rules, object lifetimes.
- Edge rule setup — separation by content types, cookies and parameters, separate policies for the admin panel and API.
- Application integration — correct response headers, cache purge on publication and catalog changes.
- Correctness verification — running scenarios: guest, authorized user, cart, checkout, search.
- Load testing — comparison of response time and the share of requests reaching the application server, before and after.
- Handover of the regulation — cache update rules, incident response procedures, control points for the team.
Each stage ends with an artifact: a zone map, a set of rules, a checklist of checks. Correctness verification is a mandatory gate: until the authorization and order scenarios run without leaks or data substitution, the scheme does not go into the production environment.
Caching policies and exclusions for dynamic sections
Caching at the Cloudflare level works by rules, not "across the whole site": a page gets cached only if the request matched a policy condition.
For 1C-Bitrix this is critical — the catalog, static pages, and news sections are served from cache, while the cart, checkout, personal account, and any URLs with a session always go to the server.
What we cache and what we exclude
The basic rule is to cache GET requests to public sections and not touch anything that changes from user to user. Exclusions are set by paths (/personal/, /basket/, /order/, /auth/), by parameters (?sessid=, ?login=, ?logout=), and by authorization cookies. Separately, we close off the admin panel and service scripts for exchange with 1C.
Authorized users and personal data
The main risk is serving a cached page with someone else's name, price, or product stock.
That is why requests with an authorization cookie are marked as bypassing the cache, and dynamic blocks (cart, favorites, personal prices) are assembled separately and do not end up in the shared cache. Responses with a Set-Cookie header and private data are not stored.
Managing lifetime and reset
For the catalog and static content, the lifetime is set with a margin, while for sections with frequent updates it is shorter, with a forced reset by event: if a product or price was changed, the rule resets the cache of the specific URL, not the whole site. This way the visitor sees up-to-date data, while the load on the server remains low.
What the client receives after cache setup
After cache setup, the client receives not an "enabled cache," but a set of artifacts by which the system lives and is maintained going forward without us. Each item is a working document or configuration, not a description of "what we did."
- Cache rule configuration — a set of rules broken down by content type: static assets, catalog pages, API responses, dynamic blocks. For each rule, the cache lifetime and invalidation conditions are recorded.
- Request flow diagram — a diagram showing the path of a request from the browser to the application server: what is served from cache, what passes through directly, where purging is triggered. With it, a new engineer understands the architecture in an hour, not a week of digging.
- Exclusion policies — a list of paths and parameters that must not be cached: cart, checkout, authenticated sessions, personalized pages. Without this list, the cache starts serving someone else's data — the most expensive class of errors.
- Cache purge procedure — the sequence of actions when updating content, deploying a release, and editing templates: what is purged selectively, what is purged fully, and in what order, so as not to serve a stale version of a page.
- Configuration documentation — where the rules are stored, how to change them, which parameters are critical, and what will happen if there is an error in each of them. With comments on non-obvious spots.
- Maintenance procedure — the frequency of checks, the set of metrics for monitoring (cache hit ratio, response time, error rate), and the thresholds at which intervention is required.
- Rollback plan — how to restore the previous behavior if, after changing the rules, serving breaks or conversion drops. The rollback is tested before handover, rather than written "just in case."
These artifacts are handed over along with access credentials and a short walkthrough for your team. After that, rule edits and routine maintenance are handled by your own team — our support is needed only for architecture changes.
How does edge caching differ from application server caching?
Edge caching is a copy of the response served by the network node closest to the user, without reaching your server.
Application server caching lives inside Bitrix itself: it is a managed cache of components, information blocks, and templates, which is formed after the request has reached the application and the business logic, access permissions, and personalization have run.
The difference is fundamental: the edge stores the finished response as a whole and does not know what it is assembled from, while the server cache knows the data structure and can rebuild only the fragment that has changed.
They are also updated differently. The edge relies on time-to-live headers and rules by file type: static assets and public pages live long, while dynamic content lives for seconds or is not cached at all.
The server cache is invalidated by events — editing an information block element, changing settings, updating the catalog.
This gives rise to different classes of requests: the edge confidently serves anonymous visitors and repeat visits to the same addresses, while the server cache handles the load from authorized scenarios, the shopping cart, and the personal account, where the response depends on the specific user.
That is exactly why caching levels do not replace but complement each other.
If you put everything on the edge indiscriminately, users will start seeing other people's carts and outdated prices; if you limit yourself to server caching only, every anonymous visit will still reach the application and hit its resources.
Combining them is built on a clear separation: the edge takes public traffic and static assets, while the server handles personalized and data-dependent pages.
The key risk is invalidation. The edge does not see edits in the database, so after publishing a product or changing a price, you need to explicitly purge the cache for the relevant address, otherwise the visitor will get the old version.
We configure cache-bypass rules for service and admin sections, tie purging to publishing events, and keep a short time-to-live for pages that change frequently.
Then both levels work in concert: the edge removes the main share of the load, server caching speeds up the assembly of dynamic content, and data desynchronization does not reach the user.
Case study: how edge caching accelerated an online store
A store on 1C-Bitrix with a catalog of several tens of thousands of items: the catalog page took 1.8–2.4 seconds to render, a product page took up to 3 seconds, and almost every request hit the database because the component cache was invalidated whenever prices and stock were updated.
During a sale, the server hit its ceiling: response time grew to 8–12 seconds, some carts and checkouts dropped off due to timeouts, and the database fell into a read queue.
We moved caching to the edge via Cloudflare: static assets and media were put under a long cache, catalog and product page HTML under a managed cache with proper tag-based invalidation, while dynamic content (cart, checkout, account area, authenticated sessions) was fully excluded from the cache.
The key point was the cache-bypass rules for requests carrying the auth cookie and for the service paths used for 1C exchange, so that prices and stock would not "stick" at stale values.
Metrics before and after
| Metric | Before | After |
|---|---|---|
| Catalog response time | 1.8–2.4 s | 0.3–0.5 s |
| Product page response time | up to 3 s | 0.4–0.6 s |
| Share of requests served from cache | ~0% | 78–85% |
| Database load at peak | 100%, read queue | 20–30% |
| Behavior during a sale | response time grows to 8–12 s, carts drop off | response is stable, no failures |
We also set up invalidation separately: when a product or price changes, the cache is purged in a targeted way by tag rather than entirely, so a catalog update does not "wash away" the whole cache and does not bring the site down during a rebuild.
The store now handles peak load without scaling the server — the edge absorbs the bulk of the traffic.
Technical doubts about cache configuration
Caching a dynamic site on 1C-Bitrix almost always runs into the same issues: a page is seen by both a guest and an authorized user, each with their own cart and their own blocks. Below is an analysis of typical doubts that come up before enabling caching on the perimeter.
How do you cache pages for authorized users?
We don't serve the full cache to them — otherwise one visitor would see another's data. The scheme is this: a guest receives a cached response, while a request with an active session bypasses the cache, and the page is assembled on the application side.
The compromise is to cache shared blocks (catalog, categories, static content) and load personal ones (name, balance, recommendations) via a separate request after the page has been served. This way the main load is removed, and personalization stays correct.
What happens with the cart and checkout?
The cart is session state; it must not be placed in the shared cache under any settings. Requests to the cart, adding a product, and checkout are marked as non-cacheable and always passed through to the application.
Only pages without user data are cached: product page, list, informational sections. Checkout and payment bypass the cache entirely.
How do you refresh the cache after content edits?
Two mechanisms together. The first is event-based invalidation: when an element, section, or product is saved, the application reports a reset, and related pages are reassembled.
The second is a short time-to-live for frequently changing blocks, so an edit gets through even without an explicit event. For images and static content we use versioning in the file name: once updated, the address changes, and the old cache no longer gets in the way.
How do you avoid breaking personalization and regional versions?
Personalization is built on separation: the shared part of the page is cached, the personal part is injected on the client or via a separate request. Regional versions and different currencies are separated by cache key, so a visitor from one city doesn't get another's terms.
After enabling, we run through the scenarios: guest, authorized, adding to cart, checkout — and verify that no one else's data leaks anywhere.
If any of the points still leave doubts for your project — describe the task, and we'll come back with an estimate and a configuration plan.
Let's discuss your caching task
To come back with an estimate and an implementation plan rather than generalities, we need a snapshot of your current configuration.
Describe how the cache is set up now: what the application server serves, what Cloudflare caches, which pages and sections are cached, how bypass rules are configured for authorized users and the cart.
Separately — where exactly the problem shows up: a drop in response time under load, stale content after edits in the admin panel, cache reset on every publish, or growing database load during peak hours.
It helps to attach whatever you already have on hand: the configuration of caching and bypass rules, TTL settings for static and dynamic content, current response headers, slow query logs, screenshots of metrics from the Cloudflare dashboard for a representative period.
If some of this hasn't been collected — no problem, we'll reconstruct part of the picture ourselves during the caching audit.
What we do next:
- review the current caching scheme and find where control is being lost;
- compare Cloudflare rules against 1C-Bitrix logic: components, composite mode, event-driven reset;
- check how the cache behaves during authorization, adding to cart, and checkout;
- assess the impact on the application server and database load;
- prepare an implementation plan: stages, order of changes, rollback points;
- agree on priorities and the order of work with you.
The response format is an estimate of the work and an implementation plan with clear stages, not an abstract "we need to optimize." If risks to the current release come up during the review, we'll state them directly before any changes begin.
Describe the task in your own words: what the project is, what the load is, what you've already tried, and what result you need.
If necessary, we'll bring in an engineer who handles caching and will examine the nuances of your configuration in detail — we'll discuss the task and come back with an estimate and a work plan.