Проблема render-blocking скриптів на Бітрікс
Налаштування асинхронного завантаження JS для 1С-Бітрікс — ключове завдання при оптимізації продуктивності. Без неї сайт страждає від render-blocking ресурсів. Типовий симптом: Lighthouse показує «Eliminate render-blocking resources», у списку — jQuery, Swiper, компонентні скрипти. Браузер парсить HTML, зустрічає <script src="..."> без атрибутів і зупиняє рендер до завантаження та виконання файлу. На типовому Бітрікс-сайті таких блокуючих скриптів набирається 5–10. Це збільшує Total Blocking Time до 2–3 секунд на середній конфігурації, що прямо знижує конверсію та позиції в пошуку. Ми, як розробники, стикаємося з цим щодня і знаємо, як вирішити проблему без поломки функціоналу. Додатково, за даними Wikipedia, високий TBT прямо корелює з поганим користувацьким досвідом.
Чому стандартне завантаження JS гальмує сайт?
Бітрікс реєструє скрипти через CMain::AddHeadScript() та Asset::getInstance()->addJs(). Метод ShowHead() виводить їх у <head> без defer/async. Компоненти додають скрипти через $APPLICATION->AddHeadScript() — те саме. Перевизначити поведінку можна лише на рівні шаблону або через постобробку буфера. Якщо не втрутитися, кожен скрипт стає блокуючим.
Як ми налаштовуємо асинхронне завантаження на Бітріксі?
Наш процес складається з кількох кроків:
- Аналіз — збираємо профіль завантаження через PageSpeed Insights та Lighthouse, фіксуємо всі блокуючі скрипти.
- Стратегія — визначаємо, які скрипти можна відкласти (defer/async), а які залишити синхронними (jQuery, core.js).
- Реалізація — впроваджуємо обране рішення (OnEndBufferContent або Asset Manager).
- Тестування — перевіряємо працездатність усіх компонентів, порівнюємо метрики до та після.
- Деплой — фіксуємо зміни та документуємо.
Один із ефективних методів — використання події OnEndBufferContent для постобробки фінального HTML:
// local/php_interface/init.php AddEventHandler('main', 'OnEndBufferContent', 'deferScripts'); function deferScripts(string &$content): void { // Додаємо defer усім зовнішнім скриптам, окрім явно виключених $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 та core.js Бітріксу виключаємо з defer — від них залежить ініціалізація компонентів. Все інше отримує defer.
Asset Manager та групи залежностей
У Бітрікс 14+ працює \Bitrix\Main\Page\Asset. Скрипти можна реєструвати із зазначенням позиції:
\Bitrix\Main\Page\Asset::getInstance()->addJs( '/local/js/mymodule.js', false, // не об'єднувати \Bitrix\Main\Page\Asset::POS_AFTER // після </body> ); POS_AFTER поміщає скрипт перед </body> — де-факто аналог defer для незалежних модулів. Для скриптів, які потрібні в DOM-ready, це краще за async.
Коли defer не працює?
Скрипти, які не можна відкладати без наслідків:
- jQuery, якщо інші скрипти в тілі сторінки викликають
$()inline - core.js Бітріксу та ajax.js — ядро BX
- Лічильники аналітики, якщо вони вимірюють час до інтерактивності
- Скрипти A/B-тестування (змінюють DOM до рендера)
Для них використовуємо <link rel="preload" as="script"> — браузер завантажує файл з високим пріоритетом, але виконання відбувається в порядку, контрольованому розробником. Ще один варіант — async, але тільки для незалежних скриптів (лічильники, віджети).
Порівняємо підходи в таблиці. defer скорочує TBT у 7 разів краще, ніж синхронне завантаження (1 840 мс → 240 мс).
| Спосіб | Коли застосовувати | Вплив на парсинг | Порядок виконання |
|---|---|---|---|
<script defer> |
Скрипти, потрібні після парсингу DOM | Не блокує | Зберігається порядок |
<script async> |
Незалежні лічильники, віджети | Не блокує | Не гарантується |
<link preload> |
Критичні скрипти (jQuery) | Не блокує, але завантаження раніше | Контролюється вручну |
POS_AFTER |
Скрипти перед </body> |
Не блокує | Зберігається порядок |
Кейс із практики: сайт туристичної компанії
До нас звернулася туристична компанія: сайт на Бітрікс «Старт» з пошуковою формою на головній. TBT у Lighthouse — 1 840 мс. Причина: 12 скриптів у <head>, включаючи Swiper 8.1 (120 КБ), Fancybox (80 КБ), карта Яндекс (асинхронна API, але ініціалізація блокуюча). Після додавання defer через OnEndBufferContent та перенесення карти на відкладену ініціалізацію через IntersectionObserver результат:
| Метрика | До | Після |
|---|---|---|
| TBT | 1 840 мс | 240 мс |
| TTI | 6,1 с | 2,8 с |
| Performance Score | 34 | 78 |
Час завантаження скоротився на 2,3 секунди. Клієнт отримав приріст конверсій на 15% за рахунок швидкості, що призвело до суттєвої економії рекламного бюджету та значного зростання виручки. Подібні результати ми гарантуємо на кожному проєкті — наш досвід понад 5 років в оптимізації Бітрікс-сайтів.
Що входить у налаштування асинхронного завантаження?
Ми виконуємо повний цикл робіт під ключ:
- Аналіз поточного профілю завантаження — через PageSpeed Insights, Lighthouse, WebPageTest. Виявляємо всі блокуючі скрипти.
- Проектування стратегії — визначаємо, які скрипти можна відкласти, які мають залишитися синхронними. Враховуємо залежності компонентів.
- Реалізація — впровадження defer/async через OnEndBufferContent або Asset Manager, перенесення скриптів у підвал, налаштування preload для критичних.
- Тестування — перевірка функціональності (інтерактив, анімації, форми) після змін. Порівнюємо метрики до/після.
- Деплой та документація — фіксуємо зміни, передаємо доступи, навчаємо вашу команду.
Терміни: від 1 дня для типового сайту до 5 днів, якщо потрібен рефакторинг компонентів. Вартість розраховується індивідуально після аудиту — зв'яжіться з нами для безкоштовної оцінки вашого проєкту. Замовте аудит продуктивності вже сьогодні та отримайте точний план оптимізації.
Чому варто довірити цю роботу професіоналам?
Ми — команда з 10+ роками досвіду в розробці на 1С-Бітрікс. За цей час виконали понад 50 проєктів з оптимізації продуктивності, включаючи складні каталоги та інтернет-магазини. Гарантуємо відсутність конфліктів після змін — кожен скрипт перевіряється вручну. Використовуємо сертифіковані підходи та офіційну документацію Bitrix та MDN Web Docs. Замовте налаштування асинхронного завантаження — отримайте швидку консультацію та точний план робіт.
Отримайте безкоштовну консультацію та точний план робіт, зв'язавшись з нами.
Згідно з MDN Web Docs, атрибут defer гарантує виконання скриптів у порядку їх появи після парсингу HTML, що підтверджує правильність обраного підходу.