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.