Accelerating 1C-Bitrix: Composite Cache Setup for TTFB Under 50ms

Your 1C-Bitrix site is slow: TTFB 800ms, server struggling under load, hosting budget climbing? Composite cache solves this radically — the first request to a page runs fully (PHP + DB), the result is saved as static HTML in /bitrix/cache/html/, and subsequent requests are served directly from the file via nginx. PHP doesn't even start. Composite cache is the most effective way to speed up page loading without server upgrades. TTFB drops from 800ms to 20–50ms, PHP-FPM load reduces by 90% or more. Dynamic blocks (cart, username, stock) are replaced by AJAX requests after page load.

Over 5 years, we have completed more than 50 successful composite cache implementations on projects of various scales — from online stores to news portals with 100,000+ unique visitors daily. Composite cache speeds up TTFB by 10-20x compared to ordinary caching without static HTML. Below we explain how it works and what pitfalls to watch out for.

What Are the Server and License Requirements?

For composite to work, you need:

• License 'Business' or higher (not available in 'Start' and 'Standard')
• Module bitrix.composite (installed from Marketplace; built-in in older versions)
• Correct nginx configuration to serve HTML cache without PHP

The nginx configuration is critical. Without it, composite works 'halfway': HTML is saved, but PHP still runs to check the cache. You need to add a condition in the server block that checks for the cache file and serves it directly:

set $composite_cache "";
if (!-f $document_root/bitrix/cache/html/$host$request_uri/index.html) {
    set $composite_cache "no";
}
if ($composite_cache = "") {
    rewrite ^ /bitrix/cache/html/$host$request_uri/index.html last;
}

The exact configuration depends on the Bitrix version and site structure — the official documentation contains several variants for different URL schemes. Learn more about web caching on Wikipedia, and the official Bitrix documentation on composite mode is at helpdesk.bitrix24.ru.

How to Properly Mark Dynamic Zones?

The main problem with composite is incorrect markup of dynamic zones. Everything that should not go into the static cache is wrapped in the bitrix:nocache tag:

<?$APPLICATION->IncludeComponent("bitrix:sale.basket.basket", ".default",
    array("CACHE_TYPE" => "N"), false);?>

In modern projects, dynamic zones are moved to separate AJAX endpoints and loaded via BX.ajax after page load. Typical blocks requiring nocache: cart and item counter, login block, comparison widgets, personalized recommendations, frequently changing stock.

Why Doesn't Composite Work for Authorized Users?

By default, composite serves static HTML only to anonymous users. For authorized users, the full PHP cycle always runs to correctly display personalized content. There is an async personalization mode via bitrix:composite.async, but it requires separate development and careful markup. Pages with POST parameters and those in the exclusion list (/personal/, /order/) are also not cached.

How Does Composite Cache Affect SEO?

Google and Yandex use page load time as a ranking factor. TTFB under 200ms is considered excellent, and composite delivers 20–50ms. Also, static HTML is indexed faster, improving crawl speed. For search engines, this signals a quality site. Ensure that all SEO elements (meta tags, headings) are correctly output in the cached HTML — with proper markup, this is not an issue.

Case Study from Our Practice

A news portal with 40,000 unique visitors per day, mostly anonymous. TTFB on articles was 650–900ms, server overloaded during peak hours. After configuring composite for article pages (only the 'latest comments' block remained dynamic via AJAX), TTFB dropped to 15–30ms. PHP-FPM load decreased so much that we had to reduce the number of workers — they were idle. Resource savings amounted to tens of thousands of rubles per month by eliminating the need for additional servers. Contact us for a similar audit of your project.

What's Included in Composite Cache Setup

1. Audit all components on the page: identify dynamic zones that need markup.
2. nginx configuration: add rules to serve static cache.
3. Markup of nocache zones: wrap cart, authorization, comparison, and other blocks.
4. Move some dynamic blocks to AJAX loading for even more speed.
5. Test under different scenarios: anonymous, authorized, mobile.
6. Monitoring: check response headers and TTFB via DevTools.

Before and After Comparison

Typical Setup Timelines for Composite Cache

Typical Mistakes When Setting Up Composite Cache

Composite does not work for authorized users by default — they always run the full PHP cycle. A common mistake is enabling composite globally without wrapping nocache around the necessary blocks. Result: one user's data gets into the cache and is shown to another. This is not discovered immediately and can create serious security issues. Another mistake is ignoring tagged caching, which leads to excessive cache invalidation on minor changes.

Checking Composite Cache Operation

Open the page in incognito mode and look at response headers. If the response contains X-Bitrix-Composite: Cache or the source code includes the comment <!-- Composite mode: cache -->, the cache is active. TTFB under 50ms is a reliable sign of correct operation. We also recommend checking that dynamic blocks (cart, authorization) update via AJAX after page load.

Ready to speed up your site? Order a composite cache audit and get a consultation. We guarantee 10x acceleration. Contact us for a preliminary assessment of your project.

80% of Bitrix sites slow down due to one table

b_iblock_element_property is an EAV structure where each row stores one value of one property of one element. A catalog of 50,000 products with 30 properties yields 1.5 million rows. The smart filter performs a JOIN of this table with b_iblock_element on five properties, and MySQL performs a full table scan for 3–5 seconds. Our experience shows that without intervention in this table, site acceleration is impossible. We take on projects where load time has dropped to 8–10 seconds and bring TTFB back to <200 ms within 1–2 weeks. Site speed optimization begins with an audit of slow queries and ends with a comprehensive turnkey infrastructure overhaul.

Contact us for an audit — we will identify bottlenecks within 2 hours and propose a concrete plan.

How to achieve TTFB below 200 ms?

Server optimization is the first step. Nginx configuration goes beyond simple gzip. Specifically:

• gzip_comp_level 4-5 — higher is pointless, CPU consumes more than it saves bandwidth.
• brotli on with brotli_static on for precompressed files.
• HTTP/2 with http2_max_concurrent_streams 128.
• fastcgi_cache for PHP responses — caching at Nginx level, bypassing PHP-FPM entirely.
• worker_processes auto, worker_connections according to the number of simultaneous connections.

PHP-FPM tuning: choose between pm = dynamic and pm = static. Static mode works best for dedicated servers with predictable load because it avoids forking overhead. Dynamic saves RAM under low traffic. Calculate pm.max_children as (available RAM - RAM for MySQL/Redis) / average process consumption. For OPcache set memory_consumption=256, max_accelerated_files=20000, and validate_timestamps=0 in production (restart PHP-FPM on deploy).

MySQL/MariaDB: the main bottleneck is almost always the database. Enable slow_query_log with a threshold of 0.5 sec and analyze every query via EXPLAIN. Set innodb_buffer_pool_size to 70–80% of available RAM on a dedicated server. Create composite indexes for faceted search: (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) on b_iblock_element_property. Run OPTIMIZE TABLE b_iblock_element_property after mass operations.

How to configure three-level caching?

Managed component cache. Set TTL individually for each component. Catalog — 3600 sec, news feed — 300 sec, banners — 86400. The same TTL everywhere guarantees either outdated data or useless cache.

Composite cache. The bitrix:composite technology lets Nginx serve ready HTML from a file; PHP is not executed. Dynamic zones (cart, authorization) are loaded via AJAX request through CBitrixComponent::setFrameMode(true). TTFB drops below 50 ms. However, not all components are compatible; $APPLICATION->ShowPanel() and direct output via echo break the composite. We check every page through the panel 'Performance → Composite Site'. According to Bitrix official documentation on composite cache, this is the most effective caching method for high‑load projects.

Comparison: composite cache is 10–20 times faster than managed cache in time to first byte.

Memcached / Redis. Transfer cache from the file system: sessions go to Redis (session.save_handler = redis) — 10–50 times faster than files, plus cluster support. Component cache goes to Memcached via .settings.php: 'cache' => ['type' => 'memcache']. Also enable ORM query cache so identical GetList() calls don't hit MySQL on every request.

What is the fastest way to optimize Bitrix database?

Default MySQL settings are insufficient. Indexes — composite for faceted search, covering for frequent queries. MySQL responds from the index without accessing the data. Partial indexes (MariaDB) for filtering by ACTIVE = 'Y'. Audit unused indexes — each slows down INSERT/UPDATE.

Partitioning. For tables with millions of rows: b_stat_session, b_search_content_stem, and highload-blocks with history. Partition by date — a query for 'orders in a month' does not scan three years of data. Partitioning also solves the problem of concurrent queries during exchange with 1С via CommerceML.

Real case: a catalog of 200,000 products, 50 properties. Filtering by 10 properties took 12 seconds. After creating composite indexes on (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) and partitioning b_iblock_element_property by IBLOCK_ID, execution time dropped to 0.3 seconds. MySQL load decreased by 40 times.

Cleanup. Over a year or two, any database accumulates: outdated search index, expired records in b_cache_tag, history in b_iblock_element_prop_s*, logs in b_event_log taking gigabytes. We set up regular cleanup via agents.

Frontend and CDN

Images account for 60–80% of page weight. Convert to WebP via CFile::ResizeImageGet() with BX_RESIZE_IMAGE_PROPORTIONAL + conversion. Use srcset + sizes — never load a 3000px image into a 400px block. Add loading="lazy" for everything below the fold. AVIF offers another 20–30% savings vs WebP.

CSS/JS optimization: use the built-in Bitrix module to merge and minify via 'Settings → CSS/JS Optimization'. Apply PurgeCSS / UnCSS — in a typical Bitrix project, 60–70% of CSS is unused. Use defer / async for non‑critical JS and inline critical CSS in <head> for instant FCP.

Fonts: add <link rel="preload" as="font" crossorigin> for the main font. Set font-display: swap — text visible immediately. Subset via pyftsubset — keep only Cyrillic + Latin, file size reduces by 3–5 times.

CDN: Cloudflare, BunnyCDN, AWS CloudFront, or Russian providers (Selectel CDN, VK Cloud CDN). Serve static assets (CSS, JS, images, fonts) via CDN with Cache-Control: public, max-age=31536000, immutable for files with a hash. Use on‑the‑fly image optimization (imgproxy, Cloudflare Polish) without load on origin.

Why is load testing necessary?

Not synthetic benchmarks, but real scenarios: k6 / wrk to simulate routes — catalog → filtering → product card → cart → checkout. Measure RPS, response time (p50, p95, p99), error rate. Use Xdebug (callgrind) or Blackfire for PHP profiling to find bottlenecks. The test result gives an objective picture of where it actually slows down, not where it 'seems'. After optimization, run again to record improvements.

Results

What is included in the work?

1. Current performance audit — analysis of slow queries, PHP profiling, check of caching, CDN, server settings.
2. Server configuration — Nginx, PHP-FPM, MySQL, Redis/Memcached, OPcache.
3. Caching optimization — managed cache, composite site, TTL configuration, tagged caching.
4. Database work — index creation, partitioning, cleanup, EAV table reorganization.
5. Frontend — images (WebP/AVIF), CSS/JS (minification, deferred), fonts (preload, subsetting).
6. CDN — connection, caching rule setup.
7. Load testing — real user scenarios, metric report.
8. Documentation — description of all changes, recommendations for further maintenance.
9. Guarantee — support for 1 month after delivery, ensuring all optimizations are stable.

Monitoring

Without monitoring, everything degrades in six months. A new module, uncleared logs, a template change — and speed returns to original. Use web-vitals API for Real User Monitoring from actual visitors. Set up synthetic monitoring with Pingdom or UptimeRobot for regular checks from different locations. Configure alerts — TTFB > 500 ms or LCP > 3 sec triggers notification.

Timelines and cost

Cost is calculated individually after the audit. Get a consultation for your project — we will evaluate the current state and propose an acceleration plan with specific timelines and budget. We are a team with 12+ years of experience in Bitrix, having completed over 300 site speed optimization projects. Contact us to start the performance audit today.