Покупатель нажимает «Добавить в корзину», а кнопка отзывается через полсекунды — за это время он успевает нажать ещё раз, подумать, что сайт завис, и начать раздражаться. Такие микрозадержки на каждом клике незаметны в отчётах о загрузке, но именно они формируют ощущение «тормозного» магазина. Метрика INP как раз измеряет эту сторону скорости — не «как быстро загрузилось», а «как быстро реагирует».
В этой статье разберём Interaction to Next Paint (INP): что это за метрика, почему она заменила FID в Core Web Vitals, какие значения считать хорошими и как улучшить отзывчивость интерфейса интернет-магазина на 1С-Битрикс. Тема тесно связана с качеством фронтенда, поэтому её удобно решать в рамках готового быстрого решения — разработки на Aspro Next, где производительность заложена в шаблон.
Коротко
- INP измеряет отзывчивость на взаимодействия (клики, тапы, ввод), а не скорость загрузки страницы.
- С 2024 года INP заменил FID в Core Web Vitals как более честная метрика: он учитывает все взаимодействия, а не только первое.
- Хорошо — до 200 мс, требует улучшения — 200–500 мс, плохо — выше 500 мс по 75-му перцентилю.
- Главная причина плохого INP — длинные задачи JavaScript и сторонние скрипты, блокирующие основной поток.
Что такое INP и зачем он магазину
INP расшифровывается как Interaction to Next Paint — «взаимодействие до следующей отрисовки». Метрика измеряет, сколько времени проходит между действием пользователя (клик, тап, нажатие клавиши) и моментом, когда браузер визуально отражает результат этого действия на экране. По сути это мера того, насколько живо интерфейс реагирует на человека.
Для интернет-магазина отзывчивость — это деньги. Каждое взаимодействие на пути к покупке — добавление в корзину, применение фильтра, переключение варианта, оформление — должно отзываться мгновенно. Задержки на этих шагах повышают отказы и снижают конверсию: покупатель, которому кажется, что сайт «залипает», уходит к конкуренту. INP делает эту невидимую проблему измеримой, а значит — управляемой.
Чем INP отличается от FID
До INP отзывчивость в Core Web Vitals измеряла метрика FID (First Input Delay). Разница между ними принципиальна и объясняет, почему произошла замена.
| Критерий | FID (старая) | INP (новая) |
|---|---|---|
| Что измеряет | Задержку только первого взаимодействия | Отзывчивость всех взаимодействий за визит |
| Что учитывает | Только входную задержку до обработки | Полный путь до отрисовки отклика |
| Картина | Оптимистичная, по одному клику | Реалистичная, по худшим взаимодействиям |
| Статус | Устарела | Действующая метрика Core Web Vitals |
FID смотрел только на первый клик и только на задержку до начала обработки — это давало слишком радужную картину. Первое взаимодействие могло быть быстрым, а весь остальной сеанс — тормозным, и FID этого не замечал. INP охватывает все взаимодействия за визит и меряет полный путь до отрисовки, поэтому честнее отражает реальный опыт. Именно поэтому с 2024 года INP официально заменил FID.
Пороговые значения метрики
Чтобы понимать, где вы находитесь, нужны ориентиры. Для INP приняты такие пороги:
- До 200 мс — хорошо. Интерфейс ощущается отзывчивым.
- 200–500 мс — требует улучшения. Задержки уже заметны части пользователей.
- Выше 500 мс — плохо. Сайт ощущается тормозящим на взаимодействиях.
Важно, что оценка берётся по 75-му перцентилю реальных пользователей. Это значит, что метрика учитывает не идеальные условия разработчика с мощным ноутбуком, а типичный опыт, включая недорогие смартфоны и слабые сети. Для магазина это критично: большая доля покупателей заходит именно с бюджетных телефонов, где тяжёлый JavaScript особенно сильно бьёт по отзывчивости. Ориентироваться нужно на этот реальный опыт, а не на замеры на «идеальном» устройстве.
Почему магазины тормозят на кликах
Интернет-магазины особенно подвержены проблемам с INP, и причина в природе торговой витрины. В ней очень много интерактива, и за каждым элементом стоит JavaScript.
- Корзина. Добавление, изменение количества, пересчёт — часто с обращением к серверу и перерисовкой.
- Умный фильтр. Каждый выбор пересчитывает выдачу и обновляет счётчики.
- Варианты товара. Переключение цвета/размера меняет цену, наличие, картинки.
- Всплывающие окна. Быстрый просмотр, формы, уведомления добавляют обработчиков.
Когда всего этого много, а код написан неаккуратно, каждое взаимодействие вынуждено ждать освобождения основного потока браузера. На каталогах с фильтром и корзиной нагрузка на главный поток особенно велика, поэтому INP там регулярно выходит за границы нормы. Хорошая новость: это чинится адресно, потому что проблемные взаимодействия почти всегда локализованы в нескольких местах.
Длинные задачи и основной поток
Чтобы понять, как улучшать INP, надо знать, как устроен браузер. JavaScript выполняется в одном основном потоке, и в нём же браузер обрабатывает взаимодействия и отрисовывает кадры. Пока в потоке идёт длинная задача, всё остальное ждёт.
Представим: пользователь кликает по фильтру, а в этот момент выполняется обработчик, который работает 300 миллисекунд без перерыва. Браузер не может ни обработать клик, ни отрисовать отклик, пока задача не завершится, — взаимодействие «повисает» на эти 300 мс. Отсюда главный принцип улучшения INP: не блокировать основной поток. Длинные задачи разбивают на короткие, уступают управление браузеру между кусками работы, тяжёлые вычисления выносят или откладывают. Тогда браузер успевает вклиниться и отрисовать отклик на действие пользователя быстро, даже если общей работы много.
Сторонние скрипты и виджеты
Отдельный и часто главный виновник плохого INP — сторонние скрипты. Счётчики аналитики, онлайн-чаты, виджеты отзывов, рекламные и маркетинговые теги выполняются в том же основном потоке и могут надолго его занимать, а магазин над ними почти не властен по коду.
Работа со сторонними скриптами обычно даёт самый лёгкий выигрыш:
- Отложенная загрузка. Не грузить всё сразу при открытии страницы, а подключать по мере необходимости.
- Загрузка после взаимодействия. Чат или тяжёлый виджет подгружать, когда пользователь к нему обратился.
- Ревизия набора. Убрать скрипты, которые давно не приносят пользы, но продолжают грузить поток.
- Приоритеты. Критичное для покупки — вперёд, второстепенное — потом.
Аудит сторонних скриптов почти всегда стоит первым в работе над отзывчивостью: часто именно чужой код, а не ваш, держит основной поток. Наладив загрузку внешних скриптов, можно улучшить INP, не трогая бизнес-логику.
Как улучшить INP на практике
Улучшение INP — это адресная работа по конкретным узким местам, а не абстрактная «оптимизация». Последовательность обычно такая:
- Измерьте реальные данные. Найдите взаимодействия с худшим откликом — обычно фильтр, корзина или конкретный виджет.
- Разберитесь в причине. Что блокирует поток: длинный обработчик, лишние перерисовки, сторонний скрипт.
- Отложите лишнее при загрузке. Второстепенные скрипты — после взаимодействия или по мере необходимости.
- Разбейте длинные задачи. Тяжёлые обработчики делите на части, уступая управление браузеру.
- Оптимизируйте обработчики. Уберите лишнюю работу на каждый клик, кэшируйте вычисления.
- Дайте мгновенный визуальный отклик. Показывайте реакцию сразу, а тяжёлое доделывайте следом.
- Проверьте на слабом устройстве. Замерьте результат на бюджетном смартфоне, а не только на мощной машине.
Мгновенный визуальный отклик — недооценённый приём: даже если полная обработка занимает время, показать пользователю, что клик принят (изменить состояние кнопки, показать индикатор), можно сразу. Это резко улучшает воспринимаемую отзывчивость. Общая инженерная культура фронтенда, при которой такие вещи делаются по умолчанию, обычно приходит вместе с качественной кодовой базой — об этом мы пишем в материале про D7 и ORM в Битрикс, где аккуратность на бэкенде поддерживает и фронтенд.
Особенности 1С-Битрикс
На 1С-Битрикс есть своя специфика работы с отзывчивостью. Стандартные компоненты каталога, фильтра и корзины несут собственный JavaScript, а типовые шаблоны нередко подключают много скриптов сразу. Отсюда несколько практических соображений:
- Композит помогает загрузке, но не INP напрямую. Композитный сайт ускоряет первую отрисовку, а отзывчивость — про JavaScript, поэтому композит её сам не чинит.
- Шаблон решает многое. Готовые тяжёлые шаблоны тянут лишний интерактив; лёгкий, продуманный фронтенд изначально отзывчивее.
- Ajax-обновления фильтра и корзины — типичное место длинных задач, их стоит проверять в первую очередь.
- Сторонние модули и виджеты из маркетплейса добавляют свой JS — их вклад в INP надо контролировать.
Часто самый устойчивый путь к хорошей отзывчивости на Битриксе — стартовать с решения, где производительность фронтенда уже заложена. Именно поэтому мы предлагаем разработку на Aspro Next: современный шаблон с аккуратным JavaScript даёт хорошую базу по Core Web Vitals, включая INP, без долгой борьбы с наследием тяжёлых типовых шаблонов.
Как измерять и следить
INP нельзя улучшить, не измеряя. При этом важно различать два вида данных:
- Лабораторные замеры. Инструменты разработчика и синтетические тесты помогают искать причины, но не отражают реальный опыт.
- Полевые данные. Метрики реальных пользователей показывают настоящий INP по 75-му перцентилю — именно на них ориентируется поиск.
Правильный процесс: собирать полевые данные, чтобы видеть реальную картину и находить худшие взаимодействия, и использовать лабораторные инструменты, чтобы докапываться до причин конкретной задержки. После каждой правки замер повторяют на слабом устройстве. INP — не разовая задача: новые виджеты, модули и фичи легко ухудшают отзывчивость, поэтому метрику держат под наблюдением постоянно, а не проверяют раз в год.
Частые ошибки
- Меряют только загрузку. Быстрый LCP при плохом INP — сайт грузится быстро, но тормозит на кликах.
- Тестируют на мощной машине. На бюджетном смартфоне INP совсем другой, а именно он попадает в оценку.
- Все сторонние скрипты сразу. Аналитика, чаты и виджеты грузятся при открытии и держат поток.
- Длинные обработчики. Тяжёлая логика на клик выполняется одним неразрывным куском.
- Нет визуального отклика. Пользователь не видит, что клик принят, и жмёт повторно.
- Ставка на композит. Ждут, что композитный сайт починит INP, хотя он про загрузку.
- Разовая проверка. Замерили один раз, а новые модули потом ухудшили метрику незаметно.
- Оптимизация вслепую. Правят всё подряд без измерения худших взаимодействий.
Чек-лист внедрения
- Полевые данные собираются, реальный INP по 75-му перцентилю виден.
- Худшие взаимодействия найдены — фильтр, корзина, конкретные виджеты.
- Сторонние скрипты отложены и подключаются по мере необходимости.
- Длинные задачи разбиты, тяжёлые обработчики уступают управление браузеру.
- Мгновенный визуальный отклик есть на всех ключевых действиях.
- Проверено на слабом устройстве, а не только на мощной машине.
- Шаблон и модули не тянут лишний интерактив.
- Метрика под наблюдением — INP проверяется после каждого релиза.
Вывод
INP измеряет то, что раньше ускользало от метрик загрузки, — насколько живо магазин реагирует на действия покупателя. Эта отзывчивость напрямую влияет на конверсию: задержки на добавлении в корзину, фильтре и оформлении отпугивают клиентов. Заменив FID, INP стал честной мерой реального опыта, включая слабые устройства, на которых сидит значимая часть аудитории.
Улучшается INP адресно: измерить реальные данные, найти взаимодействия с худшим откликом, освободить основной поток от длинных задач и лишних сторонних скриптов, дать мгновенный визуальный отклик. А самый устойчивый результат даёт качественный фронтенд с самого начала — когда производительность заложена в основу магазина, а не выпиливается потом из тяжёлого наследия.
