INP: что такое Interaction to Next Paint и как его улучшить

INP: что такое Interaction to Next Paint

Страница может загружаться быстро и при этом ощущаться медленной. Вы нажимаете на меню, кнопку «Добавить в корзину» или начинаете вводить текст в поиске, но интерфейс реагирует с заметной задержкой. Interaction to Next Paint (INP) измеряет именно такую отзывчивость.

INP — один из трёх показателей Core Web Vitals наряду с Largest Contentful Paint (LCP) и Cumulative Layout Shift (CLS). Он оценивает взаимодействия пользователя на протяжении всего посещения страницы, а не только первую реакцию интерфейса. 12 марта 2024 года INP официально заменил First Input Delay (FID) в составе Core Web Vitals. (developers.google.com)

Что такое INP?

Interaction to Next Paint измеряет, сколько времени странице требуется, чтобы показать следующий визуальный кадр после действия пользователя.

INP учитывает подходящие взаимодействия, например:

клики мышью;
касания на сенсорном экране;
нажатия клавиш.

Для каждого взаимодействия INP измеряет время от начала действия пользователя до момента, когда браузер способен отобразить следующий кадр. Поэтому эта метрика измеряет не только выполнение JavaScript. (web.dev)

Прокрутка, наведение курсора и масштабирование напрямую в INP не учитываются. (web.dev)

Низкий INP означает, что страница стабильно быстро реагирует на действия пользователя. Высокий INP обычно указывает на то, что некоторые важные взаимодействия задерживаются из-за нагрузки на main thread, дорогих event handler’ов, рендеринга или сочетания этих факторов.

Пороговые значения INP

Google и команда Chrome в настоящее время используют следующие пороги:

INP	Оценка
≤ 200 ms	Хорошо
> 200 ms до ≤ 500 ms	Требует улучшения
> 500 ms	Плохо

Рекомендуемая оценка проводится по 75-му перцентилю посещений страниц, отдельно для мобильных и десктопных пользователей. (web.dev)

Это важно. Взаимодействие за 150 ms на вашем рабочем ноутбуке ещё не означает, что пользователи получают хороший INP. У реальных посетителей могут быть более медленные CPU, другие условия работы браузера, фоновые процессы и иные сценарии взаимодействия.

Как работает INP

INP не рассчитывает среднее значение всех взаимодействий.

Chrome наблюдает за взаимодействиями на протяжении всего времени жизни страницы и выбирает значение, представляющее одно из самых медленных взаимодействий. Для большинства посещений кандидатом на INP становится худшее взаимодействие. На страницах с очень большим числом взаимодействий алгоритм уменьшает влияние редких выбросов: на каждые 50 взаимодействий одно самое медленное не учитывается. (web.dev)

Такая модель отвечает на важный вопрос:

Оставалась ли страница стабильно отзывчивой, даже когда пользователь выполнял множество разных действий?

Представим страницу товара:

Открытие навигации занимает 70 ms.
Выбор варианта товара — 110 ms.
Открытие списка размеров — 90 ms.
Нажатие «Добавить в корзину» — 620 ms.

Большую часть времени страница может ощущаться быстрой, но важное действие с корзиной явно работает плохо. Среднее значение могло бы скрыть эту проблему. INP специально сделан более чувствительным к таким медленным взаимодействиям.

Три части INP

Взаимодействие можно разделить на три основные фазы:

Input delay → Processing duration → Presentation delay

Вместе они формируют общую задержку взаимодействия. (web.dev)

Input Delay

Input delay — это время между началом действия пользователя и моментом, когда браузер начинает выполнять связанные с ним event callback’и.

Представим, что пользователь нажимает кнопку, пока main thread браузера уже занят выполнением большой JavaScript-задачи. Клик уже произошёл, но браузер не может сразу его обработать.

Взаимодействие ждёт.

Большие скрипты, long-running tasks, таймеры, парсинг и выполнение JavaScript могут увеличивать эту задержку. (web.dev)

Processing Duration

Processing duration — время, которое уходит на выполнение callback’ов, связанных с взаимодействием.

Например:

button.addEventListener('click', () => {
    calculateLargeDataset();
    updateApplicationState();
    renderResults();
});

Если эти операции синхронно занимают сотни миллисекунд, браузер не сможет быстро показать визуальную реакцию.

Сокращение лишней работы и разбиение крупных задач на более мелкие может помочь main thread быстрее освобождаться. (web.dev)

Presentation Delay

Даже после завершения event handler’ов браузеру может потребоваться вычислить стили, выполнить layout, paint и подготовить следующий кадр.

Это время и называется presentation delay.

Поэтому очень большой DOM, дорогой style recalculation, сложный rendering или чрезмерное количество синхронных обновлений UI могут ухудшать INP, даже если сам event handler работает относительно быстро.

INTERNAL LINK: Browser Rendering Pipeline Explained

INP и FID

INP заменил First Input Delay, потому что эти метрики оценивают отзывчивость по-разному.

FID измерял только input delay первого взаимодействия.

INP оценивает взаимодействия на протяжении всего посещения страницы и включает путь от пользовательского ввода через обработку событий до следующего визуального кадра. (web.dev)

Из-за этого страница могла исторически иметь хороший FID, но всё равно становиться неудобной позже.

Например, первый клик по меню может обрабатываться мгновенно, обеспечивая хороший FID. Но через десять секунд сложный фильтр может реагировать 700 ms. FID никогда не зафиксировал бы вторую проблему. INP способен это сделать.

Google заменил FID на INP в Core Web Vitals 12 марта 2024 года. (developers.google.com)

Как измерять INP

Есть два основных подхода: field data и lab testing.

Field Data

Field data поступают от реальных пользователей и являются самым важным источником для оценки INP.

PageSpeed Insights может показывать данные Chrome User Experience Report (CrUX), если их достаточно. Search Console также предоставляет отчёты Core Web Vitals. (web.dev)

CrUX помогает ответить на вопрос:

Есть ли у реальных пользователей проблема с INP?

Но агрегированные данные CrUX часто не показывают, какая именно кнопка, компонент, скрипт или интеракция вызвали проблему.

Здесь полезнее становится Real User Monitoring.

Библиотека Google web-vitals позволяет собирать INP непосредственно в поддерживаемых браузерах:

import {onINP} from 'web-vitals';

onINP(({value, rating}) => {
    console.log(value, rating);
});

У библиотеки также есть attribution-сборка, которая может предоставить диагностический контекст для проблемных взаимодействий. (web.dev)

import {onINP} from 'web-vitals/attribution';

onINP(({value, rating, attribution}) => {
    console.log({
        value,
        rating,
        target: attribution.interactionTarget,
    });
});

В production такие данные обычно следует отправлять в систему аналитики или observability, а не только выводить в консоль.

Lab Testing

Lab testing помогает воспроизводить и исследовать медленные взаимодействия после их обнаружения.

Проверяйте реальные пользовательские действия:

открытие навигации;
изменение фильтров;
раскрытие accordion-компонентов;
ввод в поиск;
отправку форм;
переключение вкладок;
добавление товара в корзину.

Полезно также тестировать взаимодействия во время загрузки страницы, потому что парсинг, компиляция и выполнение JavaScript могут особенно сильно нагружать main thread в этот момент. (web.dev)

Однако лабораторный результат INP зависит от того, какие именно взаимодействия вы выполняете. Если тест не запускает проблемное действие, реальная проблема может остаться незамеченной.

Как улучшить INP

Сначала найдите медленное взаимодействие, затем определите, какая часть задержки создаёт проблему.

Полезная схема диагностики:

Slow INP → identify interaction → inspect phase → confirm cause → optimize → measure again

Если высок input delay, ищите long tasks и чрезмерное количество JavaScript, которое выполняется до того, как event handler получает возможность запуститься.

Если высок processing duration, изучите сам callback. Уберите лишнюю синхронную работу, упростите вычисления и по возможности разбивайте длинные операции на части.

Если высок presentation delay, исследуйте стоимость рендеринга: style recalculation, layout, сложность DOM и дорогие визуальные обновления.

Не начинайте с случайного удаления JavaScript или изменения конфигурации framework’а. INP является результатом нескольких фаз, поэтому оптимизировать нужно именно ту фазу, которая действительно медленная. (web.dev)

INTERNAL LINK: Long Tasks and Main Thread Performance

INTERNAL LINK: How DOM Size Affects Web Performance

Типичные ошибки с INP

Одна из распространённых ошибок — тестировать только загрузку страницы. INP измеряет отзывчивость на протяжении всего посещения, поэтому страница может отлично загружаться и при этом медленно реагировать позже.

Другая ошибка — воспринимать Total Blocking Time как INP. TBT может быть полезен для поиска блокировок main thread в лабораторных тестах, но web.dev прямо описывает его как возможный proxy в некоторых ситуациях, а не как замену реальному измерению INP. (web.dev)

Ещё одна ошибка — считать, что каждое медленное взаимодействие связано с сетью. INP в первую очередь измеряет период до момента, когда может быть показан следующий кадр. Последующий асинхронный API response не обязательно входит в длительность исходного взаимодействия INP. (web.dev)

Наконец, хороший локальный результат не гарантирует хороший field result. Production-пользователи используют сайт на гораздо более широком наборе устройств и в разных условиях.

INP и SEO

INP входит в Core Web Vitals, а Google Search Central указывает, что Core Web Vitals измеряют реальные показатели загрузки, интерактивности и визуальной стабильности. Google рекомендует добиваться хороших Core Web Vitals как ради пользовательского опыта, так и для успеха в Search. (developers.google.com)

Это не означает, что улучшение INP гарантирует рост позиций.

Google прямо описывает page experience как одну часть более широкой системы сигналов. Полезный и релевантный контент всё ещё может хорошо ранжироваться даже при неидеальном page experience, а хорошие Core Web Vitals сами по себе не гарантируют высоких позиций. (developers.google.com)

Более корректный практический вывод: улучшайте INP, потому что это повышает отзывчивость интерфейса для пользователей и потому что Core Web Vitals имеют значение для того, как Google оценивает page experience, — а не потому, что конкретное улучшение на определённое количество миллисекунд можно напрямую перевести в рост позиций.

Пограничные случаи INP

У страницы может вообще не быть значения INP, если посетитель ни разу не кликнул, не коснулся экрана и не нажал клавишу. Пользователи, которые только прокручивают страницу или наводят курсор, также могут не сгенерировать подходящего взаимодействия. (web.dev)

Встроенный контент создаёт ещё одну сложность измерения. INP на уровне страницы может включать взаимодействия внутри iframe, тогда как JavaScript в top-level document может не иметь доступа к timing этих взаимодействий в cross-origin frame. Это способно вызывать расхождения между данными CrUX и собственными RUM-измерениями. (web.dev)

У Event Timing API также есть детали реализации, которые важно учитывать разработчикам. Например, его стандартный buffering threshold составляет 104 ms, хотя observer может запросить более низкий порог в пределах ограничений API. (w3c.github.io)

Для большинства команд безопаснее использовать поддерживаемую реализацию web-vitals, чем самостоятельно воссоздавать полный алгоритм расчёта INP.

FAQ

Какой INP считается хорошим?

INP 200 ms или меньше считается хорошим. Значения от 200 до 500 ms требуют улучшения, а выше 500 ms считаются плохими. Для оценки сайта рекомендуется использовать 75-й перцентиль посещений страниц. (web.dev)

Измеряет ли INP скорость загрузки страницы?

Нет. INP измеряет отзывчивость на действия пользователя. LCP — Core Web Vital, который непосредственно относится к производительности загрузки. (developers.google.com)

Влияет ли прокрутка на INP?

Сама прокрутка не относится к типам взаимодействий, используемым для INP. Учитываются клики, касания и взаимодействия с клавиатурой. (web.dev)

Является ли INP фактором ранжирования Google?

INP входит в Core Web Vitals, а Core Web Vitals являются частью более широких сигналов page experience Google. Однако Google не документирует простого правила вроде «улучшение INP на X миллисекунд увеличивает позиции на Y». Хорошие Core Web Vitals также не гарантируют высокий рейтинг. (developers.google.com)

Почему PageSpeed Insights не показывает INP?

Для конкретного URL или origin может быть недостаточно данных о реальных пользовательских взаимодействиях. Кроме того, отдельное посещение страницы может не иметь INP, если пользователь не совершил ни одного подходящего взаимодействия. (web.dev)

Итог

INP отвечает на простой, но важный вопрос: когда пользователь пытается что-то сделать, насколько быстро страница показывает визуальную реакцию?

В отличие от FID, INP оценивает отзывчивость на протяжении всего посещения и отслеживает путь взаимодействия через input delay, обработку события и следующий paint браузера. Ориентир — 200 ms или меньше на 75-м перцентиле, но оптимизировать само число вслепую не стоит.

Найдите медленное взаимодействие, определите источник задержки, исправьте конкретное узкое место и затем снова измерьте результат на реальных пользователях.

Sources

web.dev — Jeremy Wagner and Barry Pollard, “Interaction to Next Paint (INP),” published May 6, 2022; updated September 2, 2025. (web.dev)
Interaction to Next Paint — web.dev
web.dev — Jeremy Wagner, Philip Walton and Barry Pollard, “Optimize Interaction to Next Paint,” published May 19, 2023; updated September 2, 2025. (web.dev)
Optimize Interaction to Next Paint — web.dev
Google Search Central — “Understanding Core Web Vitals and Google search results,” updated December 10, 2025. (developers.google.com)
Core Web Vitals and Google Search
Google Search Central — Martin Splitt, “Introducing INP to Core Web Vitals,” May 10, 2023; updated March 12, 2024. (developers.google.com)
Introducing INP to Core Web Vitals
W3C Web Performance Working Group — Event Timing API specification. (w3c.github.io)
Event Timing API specification
web.dev — “Find slow interactions in the field.” (web.dev)
Find slow interactions in the field
GoogleChrome — web-vitals JavaScript library and reference implementation. (github.com)
GoogleChrome web-vitals repository
web.dev — “Advancing Interaction to Next Paint.” (web.dev)
Advancing Interaction to Next Paint

INP: что такое Interaction to Next Paint и как его улучшить