Як прискорити відгук сайту на 1С-Бітрікс? Оптимізація FID та INP

Оптимізація 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?

1. Відкрийте Chrome DevTools (F12) і перейдіть на вкладку Performance.
2. Натисніть кнопку Record (круглий значок).
3. Взаємодійте зі сторінкою: прокрутіть, клікніть по кнопці.
4. Зупиніть запис і знайдіть червоні смуги над шкалою часу — це Long Tasks > 50 мс.
5. Клікніть на задачу, щоб побачити стек викликів: який скрипт зайняв головний потік.

Для 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.

Стратегія:

1. Завантажувати сторонні скрипти через async або після load-події
2. Використовувати requestIdleCallback для некритичних скриптів
3. Перевірити, чи потрібні всі підключені віджети — часто залишаються невикористані

// Завантажити аналітику після 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 < 200 мс. Цього досягають при сумарному бандлі JS < 200 КБ (after parse) і відсутності Long Tasks > 100 мс при взаємодії.

Ми — команда з 10+ роками досвіду в Бітрікс, сертифіковані спеціалісти. Виконали 50+ проектів з оптимізації швидкості. Гарантуємо досягнення INP < 200 мс або доопрацювання за наш рахунок. Надаємо чек-лист і моніторинг після впровадження.

Зв'яжіться з нами для безкоштовної оцінки вашого проекту. Замовте аудит продуктивності вже сьогодні та отримайте консультацію з оптимізації FID/INP для вашого Бітрікс-сайту.

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, пошук вузьких місць.

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

Результати

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

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 сек → сповіщення.

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

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