INP
INP (Interaction to Next Paint) — метрика Core Web Vitals, заменила FID в марте 2024. Время отклика на клик. Бенчмарк ≤200 мс.
Определение INP
INP (Interaction to Next Paint) — метрика из набора Core Web Vitals, которая измеряет задержку между действием пользователя и следующим перерисовкой страницы в браузере. Браузер фиксирует каждый клик, тап и нажатие клавиши за время сессии, затем берёт 98-й перцентиль всех измеренных задержек — это и есть значение INP для конкретного посещения.
Google использует INP как сигнал ранжирования в разделе «Удобство страниц». Технически метрика охватывает три фазы обработки события: input delay (время до начала обработки в event loop), processing time (исполнение обработчиков) и presentation delay (рендеринг и отрисовка следующего кадра). Чем короче сумма этих фаз, тем отзывчивее интерфейс.
Для страниц QR-генератора INP особенно критичен: генерация кода через Canvas или SVG выполняется в main thread и напрямую удлиняет processing time. Пользователь нажал «Скачать» — генератор должен ответить мгновенно, иначе браузер зафиксирует высокий INP и Google это учтёт при ранжировании.
INP vs FID — зачем понадобилась замена
С 12 марта 2024 года INP официально заменил FID (First Input Delay) в наборе Core Web Vitals. FID измерял задержку только первого взаимодействия — щелчка или тапа сразу после загрузки страницы. Это делало метрику уязвимой: сайт мог отлично справляться с первым кликом, но подтормаживать при последующих действиях (фильтрация, поиск, анимации интерфейса). FID также не учитывал время рендеринга после обработки события.
INP закрывает оба пробела. Во-первых, он оценивает всю сессию пользователя через 98-й перцентиль, а не только первое взаимодействие. Во-вторых, он включает фазу presentation delay — время от конца обработчика до момента, когда браузер фактически отрисовал следующий кадр. Это ближе к реальному ощущению «реакции» интерфейса.
Если у сайта был хороший FID (≤100 мс), это не гарантирует хорошего INP: страница могла застревать при каждом последующем клике из-за тяжёлых вычислений. Для QR-генераторов и аналогичных инструментов с интенсивным JS это особенно актуально.
Бенчмарки и оптимизация
Google установил три пороговых значения INP:
| Значение | Оценка |
|---|---|
| ≤ 200 мс | Good — хорошо |
| 200–500 мс | Needs Improvement — требует улучшения |
| > 500 мс | Poor — плохо |
Основные причины высокого INP и способы их устранения:
- Длинные задачи в main thread. Любая задача длиннее 50 мс блокирует event loop и увеличивает input delay. Решение — разбивать тяжёлые вычисления на чанки через
scheduler.yield()илиsetTimeout(fn, 0). - Генерация QR через Canvas. Синхронная отрисовка QR-матрицы в main thread — типичная причина INP >300 мс на генераторах. Переносите генерацию в Web Worker: worker вычисляет матрицу, передаёт данные обратно через
postMessage, main thread только рисует. - Дорогие event listener-ы. Debouncing ввода снижает частоту вызовов: при генерации QR «на лету» достаточно запускать пересчёт через 200–300 мс после последнего keystroke вместо реакции на каждый символ.
- Большой DOM. Чем больше узлов, тем дольше presentation delay после изменения стилей. Виртуализируйте длинные списки, избегайте принудительного synchronous layout (не читайте
offsetWidthсразу после записи стилей). - requestIdleCallback для некритичных задач. Аналитика, предзагрузка ресурсов, логирование — откладывайте через
requestIdleCallback, чтобы не конкурировать с обработчиками пользовательских событий.
Хотите проверить INP своего QR-кода? Попробуйте возможности QRkoder — генератор построен на Web Workers и даёт INP <150 мс. Для бизнес-кампаний удобны динамические QR-коды: URL можно менять без перепечатки, а статистику сканирований отслеживать в личном кабинете.
Частые вопросы
Как INP влияет на позиции в поиске?
INP входит в Core Web Vitals и является прямым сигналом ранжирования Google с марта 2024 года. Страницы со значением INP >500 мс («Poor») получают штраф в «Page Experience» сигнале. Яндекс официально не включил INP в алгоритм, но использует собственные метрики скорости отклика интерфейса, которые коррелируют с INP. На практике высокий INP также снижает конверсию: если генератор QR реагирует с задержкой больше 300 мс, часть пользователей уходит до получения результата. Улучшение INP — это одновременно SEO и рост конверсии.
Как измерить INP своего сайта?
Есть три подхода. Первый — лабораторный: Chrome DevTools → Performance → записать сессию, найти задачи с флагом «Long Task» и оценить задержки. Второй — синтетический: PageSpeed Insights или Lighthouse дают оценочные значения INP для конкретного URL, но не учитывают реальное поведение пользователей. Третий — полевой (CrUX): Google Search Console → «Основные веб-показатели» показывает реальный INP на основе Chrome User Experience Report за 28 дней. Именно это значение Google использует для ранжирования. Дополнительно можно использовать библиотеку web-vitals (npm) для сбора INP прямо в вашем приложении.
Почему INP высокий, если страница грузится быстро?
LCP (загрузка) и INP (интерактивность) — разные аспекты. Страница может полностью загрузиться за 1.5 секунды (отличный LCP), но если при каждом клике запускается тяжёлая JS-логика, INP будет плохим. Типичные виновники: обработчики событий с синхронными вычислениями (генерация QR, обработка SVG, парсинг данных), тяжёлые CSS-анимации, вызывающие layout thrashing, и сторонние скрипты (чаты, аналитика), которые занимают main thread в момент клика пользователя.
Что такое 98-й перцентиль в INP?
Google не берёт среднее или максимальное значение всех взаимодействий за сессию — берётся 98-й перцентиль. Это означает: если пользователь сделал 100 кликов, 2 самых медленных отбрасываются, а 98-я по скорости реакция становится INP сессии. Такой подход защищает от единичных аномалий (случайный фриз ОС, фоновая загрузка), но учитывает систематически медленные взаимодействия. На сайтах с генераторами и формами типичная сессия насчитывает 10–30 взаимодействий, так что 98-й перцентиль примерно равен второму-третьему наихудшему клику.
Чем scheduler.yield() лучше setTimeout?
scheduler.yield() — современный API (Chrome 115+, Edge 115+), который явно возвращает управление браузеру и ставит продолжение задачи в начало очереди с высоким приоритетом. В отличие от setTimeout(fn, 0), который помещает задачу в конец macro-task queue, scheduler.yield() гарантирует, что пользовательское событие (клик, тап) будет обработано до возобновления вашей задачи. Для QR-генераторов это означает: разбиваем вычисление матрицы на чанки через await scheduler.yield(), и браузер успевает реагировать на нажатия кнопок между чанками. Для браузеров без поддержки — полифил через setTimeout(resolve, 0) внутри Promise.