Налаштування асинхронного завантаження JS для 1С-Бітрікс

Наша компанія займається розробкою, підтримкою та обслуговуванням рішень на Бітрікс та Бітрікс24 будь-якої складності. Від простих односторінкових сайтів до складних інтернет-магазинів, CRM систем з інтеграцією 1С та телефонії. Досвід розробників підтверджено сертифікатами від вендора.
8+Років на ринку900+Реалізованих проектів100+Розробників у штаті19+Партнерів
Послуги, які ми пропонуємо
Показано 1 з 1Усі 1626 послуг
Налаштування асинхронного завантаження JS для 1С-Бітрікс
Простий
~1 день
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1360
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    947
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Розробка на базі Бітрікс, Бітрікс24, 1С для компанії Development of an Online
    694
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Розробка на базі 1С Підприємство для компанії МИРСАНБЕЛ
    832
  • image_crm_dolbimby_434_0.webp
    Розробка сайту на CRM Бітрікс24 для компанії DOLBIMBY
    732
  • image_crm_technotorgcomplex_453_0.webp
    Розробка на базі Бітрікс24 для компанії ТЕХНОТОРГКОМПЛЕКС
    1075
Показати більше робіт

Проблема 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() — те саме. Перевизначити поведінку можна лише на рівні шаблону або через постобробку буфера. Якщо не втрутитися, кожен скрипт стає блокуючим.

Як ми налаштовуємо асинхронне завантаження на Бітріксі?

Наш процес складається з кількох кроків:

  1. Аналіз — збираємо профіль завантаження через PageSpeed Insights та Lighthouse, фіксуємо всі блокуючі скрипти.
  2. Стратегія — визначаємо, які скрипти можна відкласти (defer/async), а які залишити синхронними (jQuery, core.js).
  3. Реалізація — впроваджуємо обране рішення (OnEndBufferContent або Asset Manager).
  4. Тестування — перевіряємо працездатність усіх компонентів, порівнюємо метрики до та після.
  5. Деплой — фіксуємо зміни та документуємо.

Один із ефективних методів — використання події 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, що підтверджує правильність обраного підходу.

80% сайтів на Бітрікс гальмують через одну таблицю

b_iblock_element_property — EAV-структура. Кожен рядок зберігає одне значення однієї властивості одного елемента. Каталог у 50 000 товарів з 30 властивостями дає 1,5 млн рядків. Коли розумний фільтр робить JOIN цієї таблиці з b_iblock_element за п'ятьма властивостями, MySQL іде в full table scan на 3–5 секунд.

Наш досвід показує: без втручання в цю таблицю прискорення неможливе. Ми беремося за проекти, де швидкість завантаження впала до 8–10 секунд, і повертаємо TTFB < 200 мс за 1–2 тижні. Оптимізація швидкості сайту починається з аудиту slow-запитів і закінчується комплексною перебудовою інфраструктури під ключ. У нашому портфоліо — понад 200 успішних проєктів. Ми — команда сертифікованих фахівців з 10‑річним досвідом роботи в Бітрікс.

Серверна оптимізація

Nginx. Не просто «увімкнули gzip». Конкретно:

  • gzip_comp_level 4-5 — вище безглуздо, CPU з'їдає більше, ніж економить трафік;
  • brotli on з brotli_static on — для попередньо стиснутих файлів (Brotli стискає на 20–30% краще за gzip);
  • HTTP/2 з http2_max_concurrent_streams 128;
  • fastcgi_cache для PHP-відповідей — кешування на рівні Nginx, минаючи PHP-FPM;
  • worker_processes auto, worker_connections під кількість одночасних з'єднань.

PHP-FPM. Вибір між pm = dynamic і pm = static — не академічний:

  • Static: фіксована кількість воркерів, без overhead на форк — для виділених серверів з передбачуваним навантаженням.
  • Dynamic: економить RAM при низькому трафіку. pm.max_children рахуємо як (доступна RAM − RAM для MySQL/Redis) / середня витрата на процес.
  • OPcache: opcache.memory_consumption=256, opcache.max_accelerated_files=20000, opcache.validate_timestamps=0 на продакшені (перезавантаження PHP-FPM при деплої).

MySQL/MariaDB. Головне вузьке місце майже завжди:

  • slow_query_log з порогом 0.5 сек — кожен запит розбираємо через EXPLAIN.
  • innodb_buffer_pool_size = 70–80% доступної RAM на виділеному сервері.
  • Складені індекси для фасетного пошуку: (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) на b_iblock_element_property.
  • OPTIMIZE TABLE b_iblock_element_property після масових операцій.

Як налаштувати кешування на три рівні?

Керований кеш компонентів. TTL налаштовуємо для кожного компонента окремо. Каталог — 3600 сек, новинна стрічка — 300 сек, банери — 86400. Однаковий TTL всюди — гарантія або застарілих даних, або марного кешу.

Композитний кеш. Технологія bitrix:composite — Nginx віддає готовий HTML із файлу, PHP не запускається. Динамічні зони (кошик, авторизація) підвантажуються AJAX-запитом через CBitrixComponent::setFrameMode(true). TTFB < 50 мс. Але не всі компоненти сумісні: $APPLICATION->ShowPanel() і прямий вивід через echo ламають композит. Перевіряємо кожну сторінку через панель «Продуктивність → Композитний сайт».

Порівняння: композитний кеш швидший за керований у 10–20 разів за часом першого байта. Офіційна документація Бітрікс з композитного кешу — Bitrix Composite.

Memcached / Redis. Переносимо кеш із файлової системи:

  • Сесії → Redis (session.save_handler = redis) — швидше за файли в 10–50×, плюс робота в кластері.
  • Кеш компонентів → Memcached через .settings.php: 'cache' => ['type' => 'memcache'].
  • Кеш ORM-запитів — однакові GetList() не навантажують MySQL на кожному хіті.

Чому стандартних налаштувань MySQL недостатньо?

Індекси. Складені для фасетного пошуку. Покриваючі — для частих вибірок MySQL відповідає з індексу, не звертаючись до даних. Часткові індекси (MariaDB) для фільтрації за ACTIVE = 'Y'. Аудит невикористовуваних індексів — кожен сповільнює INSERT/UPDATE.

Партиціонування. Для таблиць з мільйонами рядків: b_stat_session, b_search_content_stem, Highload-блоки з історією. Партиція за датою — запит «замовлення за місяць» не сканує дані за три роки.

Реальний кейс: каталог 200 000 товарів, 50 властивостей. Фільтр за 10 властивостями займав 12 секунд. Після створення складених індексів за (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) та партиціонування b_iblock_element_property за IBLOCK_ID час виконання впав до 0,3 секунди. Навантаження на MySQL знизилося в 40 разів. Це дозволило скоротити витрати на сервер до 40% без втрати продуктивності.

Очищення. У будь-якій базі за рік-два накопичується: застарілий пошуковий індекс, прострочені записи в b_cache_tag, історія b_iblock_element_prop_s*, логи в b_event_log на гігабайти. Налаштовуємо регулярне очищення через агенти.

Партиціонування також вирішує проблему з паралельними запитами при обміні з 1С через CommerceML. Докладніше: MySQL Partitioning Documentation.

Після аудиту вашого проекту ми визначимо вузькі місця за 2 години та запропонуємо конкретний план прискорення. Замовте безкоштовний аудит швидкості — заповніть форму на сайті.

Фронтенд

Зображення — 60–80% ваги сторінки:

  • WebP через CFile::ResizeImageGet() з BX_RESIZE_IMAGE_PROPORTIONAL + конвертація;
  • srcset + sizes — не завантажуємо 3000px картинку в блок 400px;
  • loading="lazy" для всього нижче першого екрану;
  • AVIF — ще 20–30% економії порівняно з WebP.

CSS/JS:

  • Вбудований модуль Бітрікс: об'єднання та мініфікація через «Налаштування → Оптимізація CSS/JS»;
  • PurgeCSS / UnCSS — на типовому Бітрікс-проекті 60–70% CSS не використовуються;
  • defer / async для некритичного JS;
  • Critical CSS інлайном у <head> для миттєвого FCP.

Шрифти:

  • <link rel="preload" as="font" crossorigin> для основного шрифту;
  • font-display: swap — текст видно одразу;
  • Subsetting через pyftsubset — вирізаємо кирилицю + латиницю, файл зменшується в 3–5 разів.

CDN

Cloudflare, BunnyCDN, AWS CloudFront або локальні (Selectel CDN, VK Cloud CDN).

  • Статика (CSS, JS, зображення, шрифти) — через CDN.
  • Правила кешування: Cache-Control: public, max-age=31536000, immutable для файлів з хешем.
  • Оптимізація зображень на льоту (imgproxy, Cloudflare Polish) без навантаження на origin.

Навіщо потрібне навантажувальне тестування?

Не синтетичні бенчмарки, а реальні сценарії:

  • k6 / wrk — імітація маршрутів: каталог → фільтрація → картка → кошик → оформлення.
  • Метрики: RPS, час відповіді (p50, p95, p99), відсоток помилок.
  • Xdebug (callgrind) або Blackfire — профілювання PHP, пошук вузьких місць.

Результат тестування — об'єктивна картина, де реально гальмує. Після оптимізації проганяємо повторно — фіксуємо покращення.

Результати

Метрика До Після
TTFB 800–2000 мс 50–200 мс
Повне завантаження 4–8 сек 1.5–2.5 сек
PageSpeed (мобільний) 30–50 80–95
Одночасні користувачі 50–100 500–2000+

Що входить у роботу?

  1. Аудит поточної продуктивності — аналіз slow-запитів, профілювання PHP, перевірка кешування, CDN, серверних налаштувань.
  2. Налаштування серверної частини — Nginx, PHP-FPM, MySQL, Redis/Memcached, OPcache.
  3. Оптимізація кешування — керований кеш, композитний сайт, налаштування TTL, теговане кешування.
  4. Робота з БД — створення індексів, партиціонування, очищення, реорганізація EAV-таблиць.
  5. Фронтенд — зображення (WebP/AVIF), CSS/JS (мініфікація, deferred), шрифти (preload, subsetting).
  6. CDN — підключення, налаштування правил кешування.
  7. Навантажувальне тестування — сценарії реальних користувачів, звіт за метриками.
  8. Документація — опис усіх змін, рекомендації щодо подальшого обслуговування.
  9. Гарантія — підтримка протягом 1 місяця після здачі.

Моніторинг

Без моніторингу через півроку все деградує. Новий модуль, неочищені логи, зміна в шаблоні — і швидкість повернулася до початкової.

  • web-vitals API — Real User Monitoring від реальних відвідувачів.
  • Synthetic monitoring — Pingdom, UptimeRobot, регулярні перевірки з різних локацій.
  • Алерти — TTFB > 500 мс або LCP > 3 сек → сповіщення.

Терміни та вартість

Тип робіт Терміни
Базова оптимізація (кеш, зображення, мініфікація) 2–3 дні
Оптимізація БД (індекси, slow queries, налаштування) 3–5 днів
Серверна інфраструктура (Nginx, PHP-FPM, Redis) 2–3 дні
Комплексна (сервер + БД + фронтенд + CDN) 1–3 тижні
Навантажувальне тестування та профілювання 2–3 дні
Кластерна архітектура (балансування, реплікація) 1–2 тижні

Вартість розраховується індивідуально після аудиту. Отримайте консультацію щодо вашого проекту — оцінимо поточний стан і запропонуємо план прискорення з конкретними термінами та бюджетом. Ми — команда з 10+ роками досвіду в Бітрікс, виконали понад 200 проектів з оптимізації швидкості сайту. Замовте безкоштовний аудит швидкості — зв'яжіться з нами просто зараз.

1С Бітрікс презентація1С Бітрікс24 презентація1С Підприємство презентація