INP измеряет, сколько проходит времени от взаимодействия пользователя (клик, тап, набор текста) до того, как страница покажет результат. Заменила метрику FID в 2024 году как часть Core Web Vitals. Хороший INP — до 200 мс, плохой больше 500 мс.
Чаще всего страдает из-за тяжёлых JS-обработчиков, блокирующих главный поток. Решения: дробить большие задачи через requestIdleCallback, использовать web workers для тяжёлых вычислений, лениво подгружать виджеты, минимизировать количество слушателей.
Клик по кнопке «Добавить в корзину» вызывает тяжёлый JS — 380 мс до реакции. Пользователь успевает кликнуть ещё раз и добавляется 2 товара. INP плохой, конверсия страдает.
Бенчмарк
INP — это перцентиль 75 по всем взаимодействиям за визит, а не по одному клику, поэтому одна тяжёлая реакция при загрузке портит оценку всей сессии. Учитываются три фазы задержки: input delay (главный поток занят), processing time (выполнение обработчика) и presentation delay (отрисовка кадра). Диагностировать узкое место удобно во вкладке Performance в DevTools и по полевым данным CrUX, которые подтягиваются в PageSpeed Insights, — лабораторные тесты часто занижают проблему, потому что не воспроизводят реальные клики пользователя.
Метрика входит в Core Web Vitals и влияет на ранжирование в Google как часть сигналов page experience; Яндекс отдельного аналога INP не публикует, но «отзывчивость» косвенно ловит через поведенческие факторы и Вебмастер. На практике INP чаще всего убивают сторонние скрипты — чаты, аналитика, виджеты А/Б-тестов, которые навешивают слушатели на весь документ. Хром-ловушка: CLS и LCP можно вытянуть оптимизацией картинок, а INP лечится только разгрузкой JS, поэтому его правят в последнюю очередь и он же дольше всех держится «красным».
Время от клика, тапа или ввода до видимого изменения на экране, по 75-му перцентилю за визит.
Складывается из ожидания свободного потока, работы JS-обработчика и отрисовки следующего кадра.
Дробить длинные задачи, выносить вычисления в web worker и убирать лишние сторонние скрипты и слушатели.