Оптимизация FID/INP для 1С-Битрикс: ускоряем отклик сайта

Оптимизация 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: пошаговая инструкция

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 раза быстрее.

В контексте Битрикс — через \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-запросов и заканчивается комплексной перестройкой инфраструктуры под ключ.

[Свяжитесь с нами для аудита] — мы определим узкие места за 2 часа и предложим конкретный план.

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

Nginx. Не просто «включили gzip». Конкретно:

• gzip_comp_level 4-5 — выше бессмысленно, CPU сжирает больше, чем экономит трафик;
• brotli on с brotli_static on — для предварительно сжатых файлов;
• 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 раз.

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

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

Фронтенд

Изображения — 60–80% веса страницы:

• WebP через CFile::ResizeImageGet() с BX_RESIZE_IMAGE_PROPORTIONAL + конвертация;
• srcset + sizes — не грузим 3000px картинку в блок 400px;
• loading="lazy" для всего ниже первого экрана;
• AVIF — ещё 20–30% экономии vs WebP (подробнее: 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 проектов по оптимизации скорости сайта.