INP (Interaction to Next Paint) — задержка от жеста пользователя до следующего отрисованного кадра. В метрику входят клик мышью, тап по экрану и нажатие клавиши — не скролл, не hover и не pinch-zoom. Это не FID (только первая задержка до старта обработчика) и не кабинетный отчёт «Основные интернет-показатели». Как Search Console клеит группы URL и красит статус по худшей из трёх — Core Web Vitals. Загрузка героя — соседний LCP, сдвиг вёрстки — CLS. Хаб — техническое SEO.
12 марта 2024 INP стал стабильным Core Web Vital и заменил FID. 9 сентября 2024 Chrome убрал FID из PageSpeed Insights, CrUX API и расширения Web Vitals; запись first-input в PerformanceObserver ещё жива, но в KPI 2026 её не кладут. Справка Search Console / web.dev на 75-м процентиле, мобильные отдельно от компьютера: ≤200 мс — «хорошо», ≤500 мс — «нужно увеличить скорость», >500 мс — «плохо». Порог не средний и не ваш инкогнито. Яндекс INP в Вебмастере не считает.
Что именно меряют
INP смотрит все подходящие взаимодействия за жизнь вкладки и отдаёт одно число: почти всегда самое медленное. Если жестов больше 50, из расчёта выкидывают по одному худшему на каждые 50 — иначе случайный фриз на длинной сессии портит иначе отзывчивую страницу. 75-й процентиль полевых визитов потом ещё раз срезает выбросы. Значение фиксируют, когда пользователь уходит со страницы (и при уходе вкладки в фон: вкладку могут не закрыть неделями, а мобильный браузер часто не зовёт unload).
Жест — группа событий одного логического действия. Тап даёт pointerdown, pointerup и click; клавиша — keydown / keyup. В задержку идёт самое длинное событие группы: от начала жеста до момента, когда браузер может нарисовать следующий кадр. Сеть и поздние async-обновления после этого кадра в INP не входят: метрика ловит блокировку визуальной обратной связи, не полный бизнес-эффект клика. Жесты внутри iframe входят в метрику страницы (пользователь не делит документ на фреймы); RUM на своей JS часто их не видит — расхождение с CrUX здесь штатное.
| Кусок задержки | От | До | Типичный виновник |
|---|---|---|---|
| Input delay | жест начался | первый обработчик стартовал | длинная задача на главном потоке: парсинг скрипта, чужой таймер, очередь предыдущих кликов |
| Processing duration | обработчики пошли | все колбэки этого кадра закончились | тяжёлый click: синхронный layout, большой JSON, forced reflow |
| Presentation delay | колбэки отработали | следующий кадр на экране | огромный DOM, HTML, собранный в JS, content-visibility не режет вне экрана |
Сумма трёх кусков — латентность жеста. INP не среднее по жестам и не «время до интерактива» (TTI). Если на странице не было клика, тапа и клавиши — значения нет: бот без сценария клика, человек только полистал, мало полевых взаимодействий в CrUX. Пустой INP в PSI — не «зелёный», это «нет выборки».
Поле важнее лаборатории
Поле: отчёт Core Web Vitals в Search Console и верх PSI (CrUX, ~28 дней). Нет данных по URL — PSI показывает origin, это не та же цифра. CrUX скажет, что группа красная; какой жест и на каком шаге — нет. Для этого свой RUM: onINP из web-vitals. Сырой Event Timing по умолчанию не шлёт события короче 104 мс; чтобы короткие жесты не пропадали, библиотека ещё смотрит first-input. После восстановления из bfcache INP надо обнулять: для человека это новый визит.
Лаборатория (Lighthouse без сценария кликов) INP часто не считает: она грузит документ и уходит. TBT (Total Blocking Time) — грубый прокси длинных задач на загрузке, не замена INP. Чтобы воспроизвести полевой фриз, кликают по тому же контролу во время загрузки, когда главный поток занят парсингом бандла, и прогоняют денежный сценарий (меню, фильтр, «в корзину», поле поиска). Медленный 4G сам по себе INP почти не двигает: узкое место — устройство и главный поток, не канал.
Типичный шаблон витрины. Кнопка «купить» висит в первом HTML, но обработчик навешивается после гидрации: до этого клик либо мёртвый, либо копится и потом стреляет пачкой — соседние CSR и SSR. Тот же фильтр, который после клика синхронно пересобирает всю сетку в JS, бьёт processing + presentation. Origin-контракт для роботов — соседний JavaScript SEO: INP измеряет человека в Chrome, не очередь WRS и не тумблер рендеринга Яндекса.
INP в норме, когда 75% полевых визитов шаблона отвечают на жест кадром ≤200 мс. Зелёный TBT на пустом кэше этого не доказывает.
На денежных URL сначала называют жест из RUM, потом смотрят, в каком куске сидит задержка. Если обработчик не в первом HTML или клик ждёт гидрации — это дыра доступа плюс отзывчивость, постановка SEO-аудита сайта, не «ещё один CDN». Шире, чем три метрики (HTTPS, мобильная страница) — Page Experience.
Ограничение. Нет доли сайтов РФ с INP >500 мс — не выдумываем. Нет формулы «минус N позиций за 501 мс». Не складывайте индекс скорости Яндекса (открытия в Яндекс Браузере с мобильной выдачи) с 200 мс Google. FID из старых выгрузок GSC с текущим кабинетом не сравнивают: ряд сняли в марте 2024.
Частые вопросы
INP и FID — это одно и то же?
Нет. FID мерил только input delay первого жеста. INP смотрит все клики, тапы и клавиши за жизнь страницы и включает обработку плюс ожидание кадра. С 12 марта 2024 FID не Core Web Vital; с сентября 2024 его нет в PSI и CrUX.
Почему в Lighthouse нет INP, а в Search Console группа красная?
Лаборатория без сценария кликов метрику часто не считает: она только грузит страницу. Console — 75-й процентиль живых Chrome по группе URL. Смотрят поле. Лаборатория нужна, чтобы повторить конкретный жест, не чтобы закрыть KPI.
Скролл и наведение портят INP?
Нет. В метрику входят клик, тап и клавиша. Колесо, трекпад, hover и масштаб — нет. Если жест масштаба или скролла внутри себя содержит тап, этот тап уже может попасть.
Яндекс смотрит INP?
В Вебмастере нет отчёта Core Web Vitals. Есть достижение «скорость сайта» по открытиям в Яндекс Браузере с мобильного поиска — другая величина и другая выборка. Пороги 200 / 500 мс относятся к Google CrUX, их нельзя переносить на шкалу Яндекса.