The Problem of Render-Blocking Scripts on Bitrix
Configuring asynchronous JS loading for 1C-Bitrix is a key task in performance optimization. Without it, the site suffers from render-blocking resources. A typical symptom: Lighthouse shows "Eliminate render-blocking resources", listing jQuery, Swiper, and component scripts. The browser parses HTML, meets <script src="..."> without attributes, and halts rendering until the file is downloaded and executed. On a typical Bitrix site, there are 5–10 such blocking scripts. This increases Total Blocking Time to 2–3 seconds on average configurations, directly reducing conversion rates and search rankings. As developers, we encounter this daily and know how to solve it without breaking functionality. Additionally, according to Wikipedia, high TBT directly correlates with poor user experience.
Why Standard JS Loading Slows Down the Site
Bitrix registers scripts via CMain::AddHeadScript() and Asset::getInstance()->addJs(). The ShowHead() method outputs them in <head> without defer/async. Components add scripts via $APPLICATION->AddHeadScript() — the same. Overriding this behavior is only possible at the template level or through buffer post-processing. Without intervention, every script becomes blocking.
How We Configure Asynchronous Loading on Bitrix
Our process consists of several steps:
- Analysis — collect a loading profile via PageSpeed Insights and Lighthouse, record all blocking scripts.
- Strategy — determine which scripts can be deferred (defer/async) and which must remain synchronous (jQuery, core.js).
- Implementation — deploy the chosen solution (OnEndBufferContent or Asset Manager).
- Testing — verify all components work correctly, compare metrics before and after.
- Deployment — commit changes and document.
One effective method is using the OnEndBufferContent event for post-processing the final HTML:
// local/php_interface/init.php
AddEventHandler('main', 'OnEndBufferContent', 'deferScripts');
function deferScripts(string &$content): void
{
// Add defer to all external scripts except explicitly excluded ones
$exclude = ['jquery.min.js', '/bitrix/js/main/core/core.js'];
$content = preg_replace_callback(
'/<script\s([^>]*src=["\'][^"\']+["\'][^>]*)>/i',
function (array $m) use ($exclude): string {
foreach ($exclude as $ex) {
if (str_contains($m[0], $ex)) {
return $m[0];
}
}
if (str_contains($m[1], 'defer') || str_contains($m[1], 'async')) {
return $m[0];
}
return '<script ' . $m[1] . ' defer>';
},
$content
);
}
jQuery and Bitrix's core.js are excluded from defer — component initialization depends on them. Everything else gets defer.
Asset Manager and Dependency Groups
In Bitrix 14+ there is \Bitrix\Main\Page\Asset. Scripts can be registered with a position:
\Bitrix\Main\Page\Asset::getInstance()->addJs(
'/local/js/mymodule.js',
false, // do not combine
\Bitrix\Main\Page\Asset::POS_AFTER // after </body>
);
POS_AFTER places the script before </body> — effectively an analog of defer for independent modules. For scripts needed at DOM-ready, this is preferable to async.
When Defer Doesn't Work
Scripts that cannot be deferred without consequences:
- jQuery, if other scripts in the page body call
$() inline
- Bitrix's core.js and ajax.js — BX core
- Analytics counters, if they measure time to interactivity
- A/B testing scripts (they modify DOM before rendering)
For these, we use <link rel="preload" as="script"> — the browser downloads the file with high priority, but execution order is controlled by the developer. Another option is async, but only for independent scripts (counters, widgets).
Let's compare approaches in the table. defer reduces TBT 7 times better than synchronous loading (1,840 ms → 240 ms).
| Method |
When to Use |
Impact on Parsing |
Execution Order |
<script defer> |
Scripts needed after DOM parsing |
Does not block |
Order preserved |
<script async> |
Independent counters, widgets |
Does not block |
Not guaranteed |
<link preload> |
Critical scripts (jQuery) |
Does not block, but earlier loading |
Manually controlled |
POS_AFTER |
Scripts before </body> |
Does not block |
Order preserved |
Case Study: Travel Agency Website
A travel agency approached us: a Bitrix "Start" site with a search form on the homepage. TBT in Lighthouse was 1,840 ms. Cause: 12 scripts in <head>, including Swiper 8.1 (120 KB), Fancybox (80 KB), and a Yandex Map (async API, but initialization was blocking). After adding defer via OnEndBufferContent and moving the map to deferred initialization via IntersectionObserver, the results were:
| Metric |
Before |
After |
| TBT |
1,840 ms |
240 ms |
| TTI |
6.1 s |
2.8 s |
| Performance Score |
34 |
78 |
Load time decreased by 2.3 seconds. The client saw a 15% increase in conversions due to speed, leading to significant ad budget savings and revenue growth. We guarantee similar results on every project — our experience spans over 5 years in Bitrix site optimization.
What's Included in the Asynchronous Loading Setup?
We provide a full turnkey cycle:
- Analysis of current loading profile — via PageSpeed Insights, Lighthouse, WebPageTest. Identify all blocking scripts.
- Strategy design — determine which scripts can be deferred and which must remain synchronous. Account for component dependencies.
- Implementation — deploy defer/async via OnEndBufferContent or Asset Manager, move scripts to footer, set up preload for critical ones.
- Testing — verify functionality (interactivity, animations, forms) after changes. Compare before/after metrics.
- Deployment and documentation — commit changes, hand over access, train your team.
Timeline: from 1 day for a typical site to 5 days if component refactoring is needed. Cost is calculated individually after an audit — contact us for a free assessment of your project. Order a performance audit today and get a precise optimization plan.
Why Trust This Work to Professionals?
We are a team with 10+ years of experience in 1C-Bitrix development. We have completed over 50 performance optimization projects, including complex catalogs and online stores. We guarantee no conflicts after changes — every script is manually checked. We use certified approaches and official documentation from Bitrix and MDN Web Docs. Order asynchronous loading setup — get a quick consultation and a precise work plan.
Get a free consultation and a precise work plan by contacting us.
According to MDN Web Docs, the defer attribute guarantees script execution in order of appearance after HTML parsing, confirming the correctness of the chosen approach.
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
| Metric |
Before |
After |
| TTFB |
800–2000 ms |
50–200 ms |
| Full load |
4–8 sec |
1.5–2.5 sec |
| PageSpeed (mobile) |
30–50 |
80–95 |
| Concurrent users |
50–100 |
500–2000+ |
What is included in the work?
-
Current performance audit — analysis of slow queries, PHP profiling, check of caching, CDN, server settings.
-
Server configuration — Nginx, PHP-FPM, MySQL, Redis/Memcached, OPcache.
-
Caching optimization — managed cache, composite site, TTL configuration, tagged caching.
-
Database work — index creation, partitioning, cleanup, EAV table reorganization.
-
Frontend — images (WebP/AVIF), CSS/JS (minification, deferred), fonts (preload, subsetting).
-
CDN — connection, caching rule setup.
-
Load testing — real user scenarios, metric report.
-
Documentation — description of all changes, recommendations for further maintenance.
-
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
| Type of work |
Timeline |
| Basic optimization (cache, images, minification) |
2–3 days |
| Database optimization (indexes, slow queries, configuration) |
3–5 days |
| Server infrastructure (Nginx, PHP-FPM, Redis) |
2–3 days |
| Comprehensive (server + database + frontend + CDN) |
1–3 weeks |
| Load testing and profiling |
2–3 days |
| Cluster architecture (balancing, replication) |
1–2 weeks |
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.
