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
- Audit all components on the page: identify dynamic zones that need markup.
- nginx configuration: add rules to serve static cache.
- Markup of
nocachezones: wrap cart, authorization, comparison, and other blocks. - Move some dynamic blocks to AJAX loading for even more speed.
- Test under different scenarios: anonymous, authorized, mobile.
- Monitoring: check response headers and TTFB via DevTools.
Before and After Comparison
| Parameter | Before Composite | After Composite |
|---|---|---|
| TTFB | 600–900 ms | 15–50 ms |
| CPU Load (PHP-FPM) | 70-90% | 5-15% |
| Page load time (anon) | 2-4 s | 0.3-0.8 s |
| Concurrent requests | 30-50 | 200+ |
Typical Setup Timelines for Composite Cache
| Project Complexity | Timeline |
|---|---|
| Simple online store (standard template) | 1–2 days |
| Complex catalog with many dynamic blocks | 2–4 days |
| Portal with custom logic | 4–6 days |
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.