Configuring Autocaching of 1C-Bitrix Components: 2-5x Speedup
We encounter projects where, after major updates or development by third-party teams, pages load in 5–10 seconds. A typical cause is incorrect autocaching parameters of components. Configuring autocaching of 1C-Bitrix components can drastically reduce response time. Let's dive into how it works and how to configure it. For example, on one project with a catalog of 10,000 items, pages took 7 seconds to load. After configuring autocaching, TTFB dropped to 0.2 seconds, leading to substantial server resource savings. Proper autocaching makes the site 2-5 times faster compared to an unoptimized one.
Autocaching as the Foundation of Bitrix Performance
Autocaching in Bitrix is a built-in mechanism of the component system where the component's output (HTML or data) is saved to file cache and reused on subsequent requests. In a properly configured project, 70–90% of component calls are served from cache without database queries. Without it, each request burdens the database, which is critical under high load.
How the Cache Key is Formed and Why It Matters
Bitrix forms the cache key from component parameters, URL, and additional variables. The problem arises when extraneous data enters the key: session ID, random GET parameters like UTM tags (utm_source, utm_campaign), pagination parameters.
A component with CACHE_FILTER = Y will create a separate cache for each combination of GET parameters — under UTM traffic, the cache will never be reused. Solution: set CACHE_FILTER = N and explicitly pass only significant parameters via arAdditionalCacheId, or filter UTM parameters at the nginx level before passing the request to PHP.
Why CACHE_GROUPS = Y Can Be a Problem
The CACHE_GROUPS = Y parameter creates a separate cache for each user group. This is needed for components with content that depends on permissions. But for a public catalog or news, CACHE_GROUPS = Y multiplies the number of cache entries by the number of user groups. On projects with 20+ groups (partners, wholesalers, managers, etc.), the cache never "warms up" to the point of being effectively used. Order an audit — we will identify and eliminate such issues.
Comparison of Caching Modes
| Mode | Description | When to Use |
|---|---|---|
| CACHE_TYPE = A | Auto — inherits global mode | Default for all components |
| CACHE_TYPE = Y | Always cache | For heavy queries, rarely changing data |
| CACHE_TYPE = N | Never cache | Only for real-time components (search, cart) |
Case Study from Our Practice
A manufacturing company's Bitrix "Standard" site. The client complained: the site was fast, but after a template update everything became slow. We conducted an audit using the performance panel — all components were running without cache. The cause: the developer, for ease of debugging, set the constant BX_CACHE_TYPE to N in bitrix/php_interface/dbconn.php and forgot to remove it. One line of code — and the entire site ran without caching. Fixing it took 15 minutes, TTFB returned to normal. Such situations are not uncommon, and our inspection of dozens of projects shows that in 80% of cases the problem is solved by simple constant configuration. This data is derived from audits of over 500 projects.
How We Configure Autocaching: The Process
Our team has 10+ years of Bitrix experience and over 500 successful projects. Recommendations are based on more than 10 years of working with Bitrix. The process includes stages:
- Audit — collect metrics, analyze components via the performance panel.
- Design — determine TTL for each block, configure keys.
- Implementation — edit component calls, add tagged cache.
- Testing — compare response times before/after (e.g., from 7 seconds to 0.2).
- Deployment — move to production server, monitor.
We guarantee at least a 2–3x page load speedup. Server resource savings can be substantial on high-load projects. The experience of certified specialists allows us to identify even hidden issues.
What's Included in Turnkey Autocaching Configuration?
- Full revision of all component calls on the site.
- Correction of incorrect caching parameters.
- Configuration of tagged cache for custom components.
- Optimization of cache keys by removing extraneous parameters.
- Documentation of changes and maintenance recommendations.
Timeline: from 1 to 3 days depending on project size. Cost is calculated individually based on scope. Get a consultation on autocaching configuration — contact us.
Recommended TTL for Typical Components
| Component Type | Recommended TTL |
|---|---|
| News, article list | 3600–7200 s (1–2 hours) |
| Product catalog | 86400 s (1 day) |
| Menu, sidebar | 86400 s |
| Search | 0 s (do not cache) |
Typical mistakes in cache configuration:
- Using CACHE_GROUPS = Y for public content.
- Incorrect cache keys with UTM parameters.
- Lack of invalidation for custom components.
Cache Invalidation
Component cache is automatically invalidated when the data of the information block it is tied to changes, via tags like IBLOCK_N_ELEMENTS. For custom components working with their own tables, invalidation must be explicitly implemented using BXClearCache() or \Bitrix\Main\Application::getInstance()->getTaggedCache()->clearByTag().
More details can be found in the official 1C-Bitrix documentation or on Wikipedia.
Configuring autocaching is a revision of all component parameters on the site, identifying incorrect cache keys, and setting proper TTLs. If you want to speed up your project, order an audit — we will diagnose and fix the issues.