Можно ли оптимизировать Битрикс без смены хостинга?

В 90% случаев — да. Типичный Битрикс-хостинг держит нормальную нагрузку, проблема в JS на клиенте и неоптимизированных шаблонах. Смена хостинга помогает, когда TTFB > 600 мс — это уже серверная история.

Влияет ли INP на позиции в Яндексе?

Яндекс отдельно INP не использует, но учитывает похожие поведенческие: отказы, возвраты в SERP. На сайте с плохим INP пользователи чаще возвращаются — Яндекс это видит. Косвенно — да, INP влияет и на Яндекс.

Нужно ли полностью отказываться от jQuery?

Не обязательно. Достаточно убрать его из критичного пути загрузки и подгружать только там, где он реально нужен компонентами Битрикса. Ядро Битрикса до сих пор зависит от jQuery — полный отказ потребует переписывания большого количества функционала.

Как часто нужно мерить Core Web Vitals?

Раз в 2 недели — через Search Console и PageSpeed. Раз в квартал — полный аудит. Crux-данные обновляются раз в месяц, поэтому эффект от правок виден с задержкой 2–6 недель.

Что если заказчик не согласен на переработку шаблона?

Даже без переработки можно добиться улучшения INP на 30–50% только за счёт оптимизации подключений: defer, async, удаление дубликатов, lazy-load сторонних виджетов. Серьёзные улучшения требуют работы с шаблонами, но есть большой запас без этого.

Core Web Vitals в 2026: INP заменил FID и что это значит для Битрикса

С марта 2024 Google окончательно заменил FID (First Input Delay) на INP (Interaction to Next Paint) в Core Web Vitals. Что это значит на практике: если ваш сайт на Битриксе проходил по FID — теперь он, скорее всего, не проходит. Ниже — разбор, почему и что с этим делать.

Что такое INP и чем он отличается от FID

FID измерял только задержку первого взаимодействия — клика, тапа, нажатия клавиши. Это игрушечная метрика: достаточно было загрузить сайт так, чтобы первый клик был быстрым, а дальше можно было тормозить сколько угодно.

INP честнее. Он измеряет время отклика на каждое взаимодействие пользователя за всю сессию и показывает худшее. Это значит, что если через 30 секунд после загрузки вы кликнули по «показать ещё» и страница зависла на 800 мс — у вас плохой INP.

Пороги в 2026:

INP ≤ 200 мс — Good (зелёный).
200–500 мс — Needs improvement.
> 500 мс — Poor.

Почему Битрикс часто проваливает INP

Короткий ответ: JavaScript-мусор.

Стандартный Битрикс-сайт — это: jQuery + ядро Битрикса + 10–20 сторонних скриптов (счётчики, чаты, онлайн-консультанты, пиксели) + JS-код компонентов (свайперы, слайдеры, формы, AJAX-фильтры). В сумме — 500 КБ–2 МБ минифицированного JS, который выполняется в main thread и блокирует все взаимодействия.

Когда пользователь кликает по фильтру или кнопке «в корзину», браузер сначала должен доделать текущий long task (любой скрипт длиннее 50 мс), только потом обрабатывает клик. Отсюда — 300–800 мс INP.

Как чинить INP на Битриксе

1. Убрать неиспользуемые модули

На 80% проектов, которые мы брали в оптимизацию, в шаблоне были подключены: чаты, которые не используются; форматы cookies, которые устарели; dev-инструменты вроде assert.js. Первый шаг — аудит bitrix/templates/.default/header.php и шаблона компонентов.

2. Lazy loading сторонних скриптов

Яндекс Метрика, Google Analytics, Jivo, Битрикс24-виджет, пиксели соцсетей — всё это должно подключаться не в <head>, а после события DOMContentLoaded или по взаимодействию пользователя. Использовать атрибуты defer/async на сторонних <script>, ленивую инициализацию.

Наш типичный выигрыш от одной только переноски сторонних скриптов в defer — от 150 до 400 мс по INP.

3. Разбить Long Tasks

Любой скрипт длиннее 50 мс — это long task, который блокирует отклик. Типичные виновники в Битриксе:

Инициализация AJAX-фильтра со всем списком свойств.
Рендер карточек товаров на клиенте.
Обработчики document.ready с десятками действий подряд.

Решение — разбивать через scheduler.yield() (новый API, поддерживается Chrome 129+), setTimeout(0) или Intersection Observer (инициализировать только то, что попало в вьюпорт).

4. Убрать jQuery там, где он не нужен

Битрикс исторически тащит jQuery 3.x — и 90% шаблонов используют его для тривиальных задач, которые современный JS делает нативно. Это +80 КБ и +20–40 мс на парсинг на среднем мобильном.

Что мы делаем: переписываем кастомные скрипты на нативном JS, а jQuery подгружаем только там, где он реально используется компонентами Битрикса.

5. Заменить тяжёлые библиотеки

Типичные «тяжеловесы» в Битрикс-шаблонах: Slick.js (44 КБ), fancybox (30+ КБ), Select2 (60+ КБ), Moment.js (230 КБ!). Современные лёгкие альтернативы: Swiper (20 КБ), GLightbox (10 КБ), Choices.js (18 КБ), day.js (2 КБ).

LCP: правила 2026

LCP (Largest Contentful Paint) остаётся ключевой метрикой. Для Битрикс-сайтов топ-3 причины плохого LCP:

Огромные баннеры в Hero. Исправляем: <picture> с webp/avif, адаптивные источники, fetchpriority="high", preload для hero-изображения в <head>.
Внешние шрифты. Google Fonts в 2026 — уже плохая идея. Храним шрифты на своём CDN (Yandex Cloud CDN), подключаем через font-display: swap, preload критичного веса.
Рендер-блокирующий CSS. Инлайнить критичный CSS (первый экран) в <head>, остальное грузить асинхронно. Для Битрикса это — кастомный сборщик или плагин вроде Critters.

CLS: что чаще всего ломает

CLS (Cumulative Layout Shift) на Битриксе плывёт из-за:

Отсутствия width/height у картинок. В 2026 это недопустимо — резервируйте место заранее, браузер рассчитает aspect-ratio.
Баннеров, которые подгружаются с задержкой и смещают контент.
Попапов согласия с cookies без фиксированного оверлея.
AJAX-фильтров, которые меняют высоту карточек после загрузки.

Простое правило: любой элемент, который появляется после первой отрисовки, должен занимать заранее зарезервированное место через min-height или aspect-ratio.

Реальные цифры: до и после

Пример из нашего кейса — интернет-магазин на Битриксе (350k посещений в мес).

До оптимизации:

LCP 3,8 с
INP 640 мс
CLS 0,21
Core Web Vitals pass rate (CrUX): 14%

После 4 недель работы:

LCP 1,9 с
INP 180 мс
CLS 0,04
Core Web Vitals pass rate: 84%

Параллельно: позиции по средне-частотным ключам выросли на 12–18%, конверсия с мобильных — на 9%.

Как мы делаем оптимизацию

Наш процесс:

Аудит (3–5 дней). Измеряем текущие метрики через PageSpeed Insights, WebPageTest, реальные данные из CrUX. Определяем топ-3 проблемы, потенциал улучшений.
Приоритизация. Сначала — быстрые победы (lazy-load скриптов, preload hero-изображения). Потом — системные (переход на webp/avif, рефакторинг компонентов, замена библиотек).
Итеративная оптимизация. 1–2 недели — релиз, замеры, следующий шаг. Не «большая переделка», а последовательные улучшения с подтверждёнными метриками.

Стоимость: от 80 000 ₽ за аудит с планом, от 180 000 ₽ за полную оптимизацию до «зелёных» метрик. В большинстве случаев работа окупается за 1–3 месяца за счёт роста органики и конверсии.