Оптимізація FID (First Input Delay) для 1С-Бітрікс
У цій статті ми розповімо про оптимізацію FID/INP для 1С-Бітрікс. Ми стикалися з проектами, де INP досягав 1500 мс на типовому Бітрікс-магазині. Клік по кнопці «Купити» — і користувач чекає більше секунди. Кожні 100 мс затримки знижують конверсію на 7%. Це прямо втрачає прибуток. Наш досвід показує: правильно налаштована оптимізація FID/INP дає INP < 200 мс за 5–10 днів під ключ. Середня вартість проекту — $1000-2000. Оцінимо ваш проект безкоштовно.
FID (First Input Delay) — час від першої взаємодії до реакції браузера, описаний у стандартах веб-продуктивності (див. Wikipedia). Google замінив FID на INP (Interaction to Next Paint), який вимірює всі взаємодії. Поріг: FID < 100 мс, INP < 200 мс. На важких Бітрікс-сайтах INP може досягати 500–1500 мс. Оптимізація в 2.5 рази знижує затримку при впровадженні code splitting.
Чому INP важливий для бізнесу
Кожна зайва мілісекунда затримки — це втрата клієнта. Дослідження Google показують: якщо INP перевищує 200 мс, ймовірність відмов зростає на 32%. Для інтернет-магазину на Бітрікс це означає десятки втрачених замовлень на день. На одному з наших проектів ми знизили INP з 800 до 150 мс — конверсія зросла на 15%. Інвестиції в оптимізацію окупаються за 2-3 місяці.
Чому браузер не реагує на клік
Браузер однопоточний: поки головний потік (main thread) зайнятий виконанням JavaScript, він не може обробляти події введення. Користувач натискає кнопку — клік стає в чергу і чекає, поки JS завершить поточне завдання. Long Tasks тривалістю > 50 мс — головна причина високого INP. Блокування головного потоку (main thread blocking) є ключовою проблемою.
Джерела довгих завдань у Бітрікс:
- Завантаження та парсінг великих JS-бандлів: jQuery + плагіни + компоненти = 500 КБ — 1 МБ
- Ініціалізація слайдерів, маск-полів, карт, віджетів при
DOMContentLoaded - Важкі обробники подій: фільтр каталогу, перерахунок кошика
- Синхронні AJAX-запити (блокують потік)
Як діагностувати Long Tasks?
- Відкрийте Chrome DevTools (F12) і перейдіть на вкладку Performance.
- Натисніть кнопку Record (круглий значок).
- Взаємодійте зі сторінкою: прокрутіть, клікніть по кнопці.
- Зупиніть запис і знайдіть червоні смуги над шкалою часу — це Long Tasks > 50 мс.
- Клікніть на задачу, щоб побачити стек викликів: який скрипт зайняв головний потік.
Для INP увімкніть в DevTools «Web Vitals» і повторіть взаємодію. Також можна використовувати консольний моніторинг:
const observer = new PerformanceObserver((list) => { for (const entry of list.getEntries()) { if (entry.duration > 50) { console.warn('Long task:', entry.duration.toFixed(1) + 'ms', entry); } } }); observer.observe({ type: 'longtask', buffered: true }); // Приклад лінивого завантаження слайдера if (document.querySelector('.main-slider')) { import('./swiper.min.js').then(({ default: Swiper }) => { new Swiper('.main-slider', { /* ... */ }); }); } Що таке code splitting?
Стандартний Бітрікс завантажує весь JS на кожній сторінці: jQuery, плагіни каталогу, скрипти кошика, слайдери, карти — все одразу. Сторінка з 1 МБ JS виконує його цілком при завантаженні. Code splitting зменшує INP до 200 мс порівняно з 500+ мс без нього — тобто в 2.5 рази швидше. Це один із найефективніших методів оптимізації FID/INP для Бітрікс.
У контексті Бітрікс — через \Bitrix\Main\Page\Asset::addJs() в конкретних шаблонах компонентів, а не в header.php.
Defer і async для скриптів
<!-- Синхронний — блокує парсінг HTML --> <script src="/bitrix/js/plugin.js"></script> <!-- defer — завантажується паралельно, виконується після парсінгу HTML --> <script src="/bitrix/js/plugin.js" defer></script> <!-- async — завантажується і виконується якомога раніше --> <script src="/bitrix/js/analytics.js" async></script> defer — для скриптів, яким потрібен DOM (ініціалізація компонентів). async — для незалежних скриптів (аналітика, рекламні теги). У Бітрікс JS-файли, додані через \Bitrix\Main\Page\Asset::addJs(), виводяться без defer. Для додавання атрибута — кастомна реалізація через хук OnEndBufferContent або перевизначення шаблону виведення скриптів.
Як оптимізувати обробники подій?
Обробник кліка, який робить синхронний перерахунок DOM на 200 елементів, блокує потік на час цього перерахунку. INP буде дорівнювати часу обробника. Приріст продуктивності від debounce може досягати 300 мс.
Паттерни покращення: Debounce для частих подій (введення в пошуку, зміна фільтра):
let debounceTimer; searchInput.addEventListener('input', function() { clearTimeout(debounceTimer); debounceTimer = setTimeout(() => { doSearch(this.value); }, 300); }); Розбиття важких операцій через setTimeout або scheduler.postTask (асинхронне розбиття):
async function processLargeList(items) { for (let i = 0; i < items.length; i += 50) { const chunk = items.slice(i, i + 50); processChunk(chunk); await new Promise(resolve => setTimeout(resolve, 0)); } } Web Workers для обчислень: якщо в обробнику події потрібні важкі обчислення (сортування, фільтрація великого масиву даних) — винесіть у Web Worker. Працює в окремому потоці, не блокує UI.
Сторонні скрипти
JivoSite, MetrikaTag, Google Analytics, пікселі соцмереж — кожен додає JS, який виконується в головному потоці. При 5–10 сторонніх скриптах сумарне навантаження на старт може становити 200–500 мс Long Tasks.
Стратегія:
- Завантажувати сторонні скрипти через
asyncабо післяload-події - Використовувати
requestIdleCallbackдля некритичних скриптів - Перевірити, чи потрібні всі підключені віджети — часто залишаються невикористані
// Завантажити аналітику після idle window.addEventListener('load', () => { requestIdleCallback(() => { const script = document.createElement('script'); script.src = 'https://analytics-provider.com/tag.js'; script.async = true; document.head.appendChild(script); }); }); Типові помилки при оптимізації INP
- Робити code splitting, але залишати синхронні скрипти шаблону — ефект втрачається.
- Завантажувати всі скрипти async — порядок виконання не гарантований, можливі баги.
- Не перевіряти після оптимізації: INP може зрости через нові віджети.
- Забувати про серверний рендеринг (TTFB) — якщо сервер повільний, JS оптимізація не врятує.
Що входить у роботу з оптимізації
| Deliverable | Опис |
|---|---|
| Аудит Long Tasks | Повний аналіз Performance, список винуватців |
| Code splitting | Розділення бандлу, ліниве завантаження |
| Переведення на defer/async | Налаштування атрибутів для всіх скриптів |
| Debounce/refactoring | Оптимізація обробників подій |
| Відкладання сторонніх | Перенесення некритичних скриптів |
| Документація та навчання | Інструкція з підтримки |
Терміни та вартість оптимізації
| Задача | Термін | Вартість (USD) | Ефект |
|---|---|---|---|
| Аудит Long Tasks через DevTools | 0.5 дня | $200 | Розуміння проблеми |
| Переведення скриптів на defer | 1 день | $400 | INP −50–200 мс |
| Відкладання сторонніх скриптів | 0.5 дня | $200 | INP −100–300 мс |
| Debounce на пошук і фільтри | 1 день | $400 | INP фільтра −200–500 мс |
| Code splitting для важких компонентів | 3–5 днів | $800–1500 | INP на сторінках каталогу −200–500 мс |
| Рефакторинг важких обробників подій | 2–5 днів | $600–1200 | INP < 200 мс |
Хорошим результатом для Бітрікс-магазину вважається INP < 200 мс. Цього досягають при сумарному бандлі JS < 200 КБ (after parse) і відсутності Long Tasks > 100 мс при взаємодії.
Ми — команда з 10+ роками досвіду в Бітрікс, сертифіковані спеціалісти. Виконали 50+ проектів з оптимізації швидкості. Гарантуємо досягнення INP < 200 мс або доопрацювання за наш рахунок. Надаємо чек-лист і моніторинг після впровадження.
Зв'яжіться з нами для безкоштовної оцінки вашого проекту. Замовте аудит продуктивності вже сьогодні та отримайте консультацію з оптимізації FID/INP для вашого Бітрікс-сайту.