INP (Interaction to Next Paint, взаимодействие с последующей отрисовкой) — метрика, фиксирующая время, необходимое браузеру для вывода следующего кадра после пользовательского действия. Самые частые сценарии такого взаимодействия — клики, тапы и ввод с клавиатуры. Чтобы установить, насколько быстро ресурс реагирует на действия, применяются специальные тесты. Более быстрый отклик означает удобный и отзывчивый интерфейс. В марте 2024 года INP полностью заменил FID в Core Web Vitals, став официальным фактором ранжирования.
Простыми словами, показатель INP Google — критичный параметр для оценки производительности коммерческого проекта. Медленная реакция снижает позиции в поисковой выдаче независимо от других технических характеристик. Даже быстро загружающийся визуально сайт получает штраф, если долго обрабатывает клики. В контексте ИИ-поиска проекты с плохой отзывчивостью получают худшие поведенческие сигналы и теряют доверие алгоритмов.
- INP: что это и какие значения считаются хорошими
- Что такое интеракция: как это устроено
- Какое время INP хорошее и какое плохое
- Почему медленный INP опасен для бизнеса
- Где найти причину и как улучшить
- Бонус: топ 4 популярных вопроса об INP
- Коротко о главном
INP: что это и какие значения считаются хорошими
INP — метрика Core Web Vitals, показывающая полный визуальный отклик интерфейса на интеракцию до следующего кадра. Оценка строится по 75‑му перцентилю полевых данных (отчет Chrome User Experience Report — CrUX) и отчётов Google Search Console отдельно по типам устройств (мобильный, десктоп). Алгоритм выбирает наихудшее взаимодействие при менее чем 50 действиях на странице за сессию.
Ориентир: держать значение на уровне ≤200 миллисекунд; 200–500 мс — требуется улучшение; >500 мс — плохо. Показатель отвечает на вопрос «как быстро интерфейс реагирует на действие». Чем ниже задержка, тем лучше UX и конверсия. Если ищете, что такое метрика INP и как улучшить INP — ориентируйтесь на реальный опыт аудитории, а не только на лабораторные замеры.
Что такое интеракция: как это устроено
Интеракция — контакт с элементом веб-страницы, например, нажатие на кнопку формы. Процесс не происходит мгновенно: задержка ввода (Input Delay) возникает до старта обработчиков событий. Главная причина — продолжительное выполнение задач в основном потоке. Запускаются скрипты, возникает пауза перед тем, как макет будет перерисован.
Алгоритм измеряет интервал между действием и моментом, когда браузер завершает рендеринг в ответ на этот контакт.
Официально учитываются три типа взаимодействия:
- Щелчок мышью (нажатие левой кнопки на элементе).
- Тап по сенсорному экрану (включая события pointerdown, pointerup и click).
- Нажатие клавиши на физической или экранной клавиатуре.
Наведение курсора (hover) и прокрутка колесом мыши (scroll) обрабатываются нативно. Они исключены из расчетов, так как представляют собой низкоуровневые операции, не блокирующие основной поток JavaScript. Каждая интеракция состоит из нескольких событий, система фиксирует наибольшую продолжительность.
Схема ниже демонстрирует этапы, предшествующие финальной отрисовке:
Длительное выполнение задач в основном потоке — лишь одна из причин. После запускаются обработчики, затем вновь возникает ожидание перед выводом последующего кадра.
%201.png)
%201.png)
%201.png)
%201.png)
%201.png)
В ходе теста происходит замер четырех этапов:
- Взаимодействие с пользователем (клики, тапы, ввод).
- Потеря действительности макета. Возникает после изменения стилей или DOM-дерева. Неизбежно провоцирует перерисовку.
- Завершение рисования. Окончание рендера в результате внесенных изменений.
- Время между контактом и отрисовкой. Демонстрирует период, потребовавшийся на вывод результата на экран.
INP vs FID: в чём разница
Метрика First Input Delay (FID) имела критические ограничения: учитывала только первое взаимодействие, измеряла исключительно начало обработки (без отрисовки) и пропускала некачественный опыт на протяжении всей сессии. Новый стандарт решает эти проблемы.
| Метрика | Что измеряет | Когда | Ограничения | Почему важно |
|---|---|---|---|---|
| FID | Задержку до начала обработки первой интеракции | Только первая интеракция | Не учитывает обработку и отрисовку; пропускает последующие действия | Часто не коррелирует с реальным UX |
| INP | Полный отклик: от интеракции до следующего визуального кадра | Все интеракции в сессии; берётся наихудшая (или близкая к 75‑му перцентилю) | Зависит от устройства и шаблона страницы | Точно отражает отзывчивость интерфейса и влияет на SEO-оценку качества |
Три фазы задержки INP
- Input Delay — ожидание до старта обработчика. Главная причина — Long Tasks в основном потоке, блокирующие реакцию на действие.
- Processing Time — выполнение кода в ответ на взаимодействие. Составляет наибольшую долю общей задержки: от пары миллисекунд при простых изменениях до сотен миллисекунд при перерисовке сложных приложений с большим объемом данных.
- Presentation Delay — обновление DOM, пересчёт стилей, корректировка лейаута и вывод следующего кадра. На сайтах с тысячами элементов со сложной стилистикой эта фаза заметно растёт.
Диагностика: фиксируйте проблемные интеракции во вкладке Performance в Chrome DevTools, ищите Long Tasks и узкие места в рендеринге.
Какое время INP хорошее и какое плохое
Для понимания нормативов изучите следующую градацию:
| Статус | Значение, мс | Оценка пользовательского опыта |
|---|---|---|
| Хорошо | ≤ 200 | Быстрый отклик, интерфейс отзывчив |
| Требуется улучшение | 200–500 | Заметная задержка при взаимодействиях |
| Плохо | > 500 | Раздражающая медлительность, высокий риск отказа |
Ориентир: по данным Google, «зелёная» зона — ≤200 мс по 75‑му перцентилю. Задержки становятся заметны после ~250–300 мс. 100 мс — амбициозная продуктовая цель, а не официальный норматив.
Почему медленный INP опасен для бизнеса
Плохой показатель означает недостаточно проработанное юзабилити. Пример: человек нажал на кнопку, ждет несколько секунд, но ничего не происходит. Или ситуация с меню-аккордеоном:
Слева длинные задачи блокируют раскрытие списка. Посетитель не знает об этом и продолжает кликать. Когда основной поток завершает вычисления, происходит обработка отложенного ввода — аккордеон хаотично открывается и закрывается.
Аудитория по умолчанию ожидает мгновенной реакции. Если ресурс задумывается и игнорирует клики, происходит резкий рост отказов.
Страницы, зависающие при взаимодействии, теряют конверсию и доверие целевой аудитории.
В итоге посетители тратят меньше времени и выполняют минимум целевых действий. Ухудшение юзабилити проявляется в прямом снижении продаж: добавить товар в корзину, заполнить форму или оплатить заказ становится сложно. Исследования показывают, что коэффициент конверсии (CR) резко падает уже после первой секунды ожидания. Негативное впечатление напрямую влияет на восприятие бренда.
Инструменты Lighthouse, PageSpeed Insights и Google Search Console оценивают INP как часть Core Web Vitals и маркируют проблемные URL в отчётах, что напрямую сказывается на продвижении.
Где найти причину и как улучшить
Для ранжирования важны именно полевые данные: ориентируйтесь на 75‑й перцентиль в отчётах Google Search Console и в полевом блоке PageSpeed Insights (CrUX). Изучайте срезы по типам устройств (мобильные сети часто дают просадки) и группам URL. Ключевая сущность для анализа — распределение задержек. Один медленный клик (800 мс) при остальных нормальных портит статистику всей сессии. Лабораторные замеры используйте исключительно для диагностики причин.
Оценить технические проблемы проще всего с помощью вкладки Performance в Chrome DevTools. Процедура анализа:
- Откройте вкладку Performance и нажмите кнопку записи.
- Воспроизведите взаимодействие (клик, тап), остановите запись.
- Анализируйте ленту Main — ищите красные полосы (блокирующие Long Tasks). Наведение курсора покажет функцию, создавшую проблему.
- Изучите полосу Interaction Events — она демонстрирует интервал до следующего фрейма.
Увидеть предварительную оценку можно в расширении Web Vitals для браузера Chrome:
Факторы, влияющие на результат, разнообразны: сложность макета, частые пересчёты стилей, избыточный объем JavaScript, тяжёлые изображения.
Конкретные шаги для оптимизации
Выполнение базовых рекомендаций позволит уменьшить задержку минимум в два раза. Чек-лист действий:
- Отложите загрузку некритичного JS с помощью атрибутов
asyncилиdefer. - Минимизируйте блокировку выполнения скриптов в основном потоке.
- Оптимизируйте код. Инструменты
minifyиtree-shakingimports помогут удалить неиспользуемые фрагменты. - Разделите CSS. Внедряйте критический CSS (inline в
<head>), остальное загружайте отложенно. Блокирующие внешние стили предотвращают рендеринг до полного анализа файлов. - Упростите селекторы. Снижение количества сложных связей минимизирует время перерисовки (осторожно используйте свойство
will-change). - Внедрите асинхронную загрузку изображений, чтобы рендеринг не блокировался тяжелым медиа-контентом.
- Заблаговременно отмечайте приоритетные ресурсы для браузера.
- Для низкоприоритетных задач применяйте метод API
requestIdleCallback. Он ставит в очередь функцию для вызова во время простоя, не блокируя вывод страницы. - Используйте современные архитектуры (
PWAилиPRPL) для оптимизации отложенных компонентов. - Кэшируйте часто используемые DOM-свойства. Многократное синхронное чтение layout-свойств (layout thrashing) вызывает принудительный пересчет геometrии элементов, блокируя систему.
Настройте CDN для быстрой доставки контента. Кэширование помогает ускорить загрузку тяжелых файлов при повторных визитах.
%201.png)
Обязательно делайте компрессию каждого изображения. Для наилучших результатов внедрите ленивую загрузку (lazy load).
Чего нужно избегать:
- тяжёлых скриптов, разбирающих DOM при клике;
- сложных пересчётов CSS в момент взаимодействия;
- блокирующих внешних стилей без встроенного критического CSS;
- бесконечных синхронных вычислений макета в обработчиках;
- многократных чтений layout-свойств (layout thrashing) — объединяйте изменения и используйте DocumentFragment.
Учитывайте влияние кумулятивного смещения макета (CLS), которое также ухудшает измеряемую производительность и показатель LCP.
Бонус: топ 4 популярных вопроса об INP
Ответы на частые вопросы специалистов, работающих над техническим SEO и юзабилити.
1. Почему INP важен? Можно ли игнорировать метрику?
Игнорировать нельзя. Высокое значение означает, что проект тормозит, а функциональность работает с лагами. Посетителям кажется, что интерфейс сломан. Это приводит к негативному опыту, который выступает одним из главных факторов ранжирования. Google Search Central настоятельно рекомендует следить за Core Web Vitals для сохранения видимости в поиске.
2. Что вызывает перерисовку на веб-странице?
Изменения макета (размера содержимого), модификации DOM-дерева, обновление стилей. Любое программное действие, влияющее на визуальную часть экрана.
3. Какие проблемные события возникают чаще всего?
События на экранах загрузки, в полях ввода данных, выпадающих окнах и сложных фильтрах. Всё, что требует мгновенной реакции системы на команду.
4. Почему низкий INP — ключ к отзывчивому сайту?
Аудитория привыкла к мгновенному отклику. Ожидание дольше 100 мс уже вызывает подсознательный дискомфорт, а при превышении 300 мс лаги становятся очевидными. Медленная работа расстраивает людей на психологическом уровне. Регулярная проверка в Lighthouse и анализ полевых отчетов помогут выявить узкие места и повысить качество продукта.
Коротко о главном
- INP — ключевая метрика Core Web Vitals. С марта 2024 года она заменила FID и стала прямым сигналом ранжирования. Измерение позволяет определить приоритеты технической оптимизации.
- Оценка строится по 75‑му перцентилю полевых данных CrUX — отдельно по устройствам и группам URL.
- Задержка складывается из трёх фаз: Input Delay, Processing Time и Presentation Delay.
- Клик, тап, нажатие клавиши запускают цепочку обработки и рендеринга. Алгоритм фиксирует полное время до визуального отклика.
- Посетители крайне негативно воспринимают медлительность, что напрямую бьет по конверсии и бизнес-показателям.
.png)
.png)
.png)
Комментарии (3)
Оставить комментарий