Оптимизация FID (First Input Delay) для 1С-Битрикс
Мы сталкивались с проектами, где INP достигал 1500 мс на типовом Битрикс-магазине. Клик по кнопке «Купить» — и пользователь ждёт больше секунды. Каждые 100 мс задержки снижают конверсию на 7%. Это прямо теряет прибыль. Наш опыт показывает: правильно настроенная оптимизация FID/INP даёт INP < 200 мс за 5–10 дней под ключ. Оценим ваш проект бесплатно.
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 месяца.
Почему браузер не реагирует на клик
Браузер однопоточный: пока главный поток занят выполнением JavaScript, он не может обрабатывать события ввода. Пользователь нажимает кнопку — клик ставится в очередь и ждёт, пока JS завершит текущую задачу. Long Tasks длительностью > 50 мс — главная причина высокого INP.
Источники длинных задач в Битрикс:
- Загрузка и парсинг больших 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 раза быстрее.
В контексте Битрикс — через \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 | Оптимизация обработчиков событий |
| Откладывание сторонних | Перенос некритичных скриптов |
| Документация и обучение | Инструкция по поддержке |
Сроки оптимизации
| Задача | Срок | Эффект |
|---|---|---|
| Аудит Long Tasks через DevTools | 0.5 дня | Понимание проблемы |
| Перевод скриптов на defer | 1 день | INP −50–200 мс |
| Откладывание сторонних скриптов | 0.5 дня | INP −100–300 мс |
| Debounce на поиск и фильтры | 1 день | INP фильтра −200–500 мс |
| Code splitting для тяжёлых компонентов | 3–5 дней | INP на страницах каталога −200–500 мс |
| Рефакторинг тяжёлых обработчиков событий | 2–5 дней | INP < 200 мс |
Хорошим результатом для Битрикс-магазина считается INP < 200 мс. Этого достигают при суммарном бандле JS < 200 КБ (after parse) и отсутствии Long Tasks > 100 мс при взаимодействии.
Мы — команда с 10+ годами опыта в Битрикс, сертифицированные специалисты. Выполнили 50+ проектов по оптимизации скорости. Гарантируем достижение INP < 200 мс или доработку за наш счёт. Предоставляем чек-лист и мониторинг после внедрения.
Свяжитесь с нами для бесплатной оценки вашего проекта. Закажите аудит производительности уже сегодня и получите консультацию по оптимизации FID/INP для вашего Битрикс-сайта.







