Configuring Component Auto-Caching in 1C-Bitrix
Auto-caching in Bitrix is the built-in mechanism of the component system, whereby the output of a component (HTML or data) is saved to file cache and reused on subsequent requests. In a correctly configured project, 70–90% of component calls are served from cache without any database queries. In a typical legacy project with no attention paid to caching, the picture is the opposite.
Component Caching Parameters
Each component in Bitrix accepts cache parameters through the settings array:
$APPLICATION->IncludeComponent(
"bitrix:news.list",
".default",
[
"CACHE_TYPE" => "A", // A - auto, N - none, Y - always
"CACHE_TIME" => 3600, // TTL in seconds
"CACHE_FILTER" => "N", // include filter parameters in cache key
"CACHE_GROUPS" => "N", // include user groups in cache key
]
);
CACHE_TYPE = A ("auto") means using the site's global cache setting. If the global setting enables "no cache" mode (e.g. for debugging purposes), all components with CACHE_TYPE = A stop caching their output. This is the first thing to check in a performance audit.
Cache Key and Its Composition
Bitrix builds the cache key from component parameters, the URL, and additional variables. Problems arise when unnecessary data ends up in the key: session identifiers, random GET parameters from UTM tags (utm_source, utm_campaign), pagination parameters.
A component with CACHE_FILTER = Y will create a separate cache entry for every combination of GET parameters — with UTM traffic the cache will never be reused. Solution: set CACHE_FILTER = N and pass only meaningful parameters explicitly via arAdditionalCacheId, or filter UTM parameters at the nginx level before the request reaches PHP.
User Group Cache
The CACHE_GROUPS = Y parameter creates a separate cache entry for each user group. This is needed for components with access-controlled content. But for a public catalogue or news feed, 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 where it is actually being used.
Case Study: Caching Disabled in Production
A manufacturing company website on Bitrix "Standard". Complaint: the site was fast, then everything slowed down after a template update. Audit via the performance panel revealed: all components running without cache. Cause — the developer had set the constant BX_CACHE_TYPE to N in bitrix/php_interface/dbconn.php for debugging convenience and forgotten to remove it. One line of code — and the entire site runs without caching. The fix took 15 minutes, and TTFB returned to normal.
Component Cache Invalidation
Component cache is automatically invalidated when the data in the infoblock it is linked to changes, via tags of the form IBLOCK_N_ELEMENTS. For custom components working with their own tables, invalidation must be implemented explicitly via BXClearCache() or \Bitrix\Main\Application::getInstance()->getTaggedCache()->clearByTag().
Configuring auto-caching involves reviewing the parameters of all components on the site, identifying incorrect cache keys, and setting appropriate TTLs. Duration: 1–2 days for a medium-sized project (20–50 components across pages).