INP — новый Core Web Vital: как сделать сайт по-настоящему отзывчивым

Пользователь нажимает на кнопку меню, а оно открывается с задержкой в полсекунды — сайт ощущается «тормозным», хотя визуально загрузился быстро. Именно отзывчивость на действия пользователя измеряет новый показатель Interaction to Next Paint, который с марта 2024 года официально заменил FID в составе Core Web Vitals. INP стал одним из главных вызовов для современных сайтов, особенно для тех, что построены на тяжёлом JavaScript. В этой статье разберём, что такое INP, чем он лучше FID, из каких фаз состоит взаимодействие, какой главный враг отзывчивости и какими приёмами сделать сайт по-настоящему быстрым в ответ на действия пользователя.

Что такое Interaction to Next Paint

Interaction to Next Paint измеряет, сколько времени проходит от момента, когда пользователь совершил действие — клик, тап, нажатие клавиши, — до момента, когда браузер отрисовал визуальный ответ на это действие. Иными словами, INP отвечает на вопрос: «Насколько быстро сайт реагирует на то, что я делаю?». Это метрика отзывчивости, и она оценивает не загрузку, а интерактивность — то, как ощущается сайт уже после открытия.

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

Чем INP лучше FID

До марта 2024 года в Core Web Vitals за интерактивность отвечал First Input Delay. FID измерял задержку только первого взаимодействия и только её первую фазу — время до начала обработки. Это была очень узкая метрика: она не учитывала, сколько на самом деле длилась обработка и отрисовка ответа, и игнорировала все взаимодействия, кроме первого. В результате сайт мог иметь идеальный FID, но при этом жутко тормозить на каждом последующем клике.

• FID учитывал только первое взаимодействие — INP учитывает все за сессию.
• FID измерял лишь задержку до начала обработки — INP охватывает полный цикл до отрисовки.
• FID легко проходился даже у медленных сайтов — INP отражает реальную отзывчивость.
• FID не замечал тормозов в обработчиках событий — INP их фиксирует напрямую.

INP честнее: он показывает реальную картину отзывчивости на протяжении всей сессии. Многие сайты, которые спокойно проходили FID, после перехода на INP оказались в красной зоне — и это заставило команды всерьёз заняться оптимизацией JavaScript. Как INP встраивается в общую систему метрик, мы разбираем в обзоре про Core Web Vitals и скорость загрузки.

Пороги INP

Оценка	Значение INP	Ощущение пользователя
Хорошо	менее 200 мс	Сайт реагирует мгновенно
Нужно улучшить	200–500 мс	Заметная задержка отклика
Плохо	более 500 мс	Сайт ощущается тормозным

Порог в 200 мс не случаен: задержки до этой величины человек воспринимает как мгновенную реакцию. Всё, что выше, начинает ощущаться как лаг. Как и для остальных Core Web Vitals, оценивается 75-й перцентиль реальных взаимодействий. На мобильных устройствах достичь хорошего INP сложнее, потому что у них слабее процессоры, а JavaScript выполняется медленнее.

INP — это метрика честности перед пользователем. Можно красиво загрузиться за секунду, но если каждый клик отвечает через полсекунды, человек всё равно почувствует, что сайт медленный.

Три фазы взаимодействия

Чтобы оптимизировать INP, нужно понимать, что любое взаимодействие проходит три последовательные фазы. Зная, в какой фазе теряется время, вы бьёте точно в цель.

1. Input delay (задержка ввода) — время от действия пользователя до начала выполнения обработчика. Возникает, когда главный поток занят другой задачей.
2. Processing time (время обработки) — выполнение самих обработчиков события: ваших функций, реагирующих на клик.
3. Presentation delay (задержка отрисовки) — время от конца обработки до того, как браузер нарисовал следующий кадр с обновлением.

Чаще всего проблема в первой и второй фазах. Input delay растёт, когда в момент клика главный поток занят выполнением длинной задачи — например, инициализацией аналитики или рендерингом большого списка. Браузер не может начать обрабатывать клик, пока не освободится. Processing time раздувается, когда сам обработчик делает слишком много синхронной работы. Понимание этой разбивки превращает оптимизацию INP из гадания в инженерную задачу.

Главный враг — тяжёлый JavaScript и long tasks

Браузер выполняет JavaScript в одном главном потоке, и пока этот поток занят, он не может реагировать на действия пользователя. Длинные задачи (long tasks) — это куски работы, которые блокируют главный поток дольше 50 мс. Чем больше у вас тяжёлого JavaScript и чем длиннее задачи, тем выше шанс, что клик пользователя придётся на занятый поток и получит большую задержку.

Источники long tasks типичны: громоздкие фреймворки, тяжёлая гидратация в SPA, синхронная обработка больших массивов данных, сторонние скрипты аналитики и рекламы, неоптимальные обработчики событий, которые срабатывают на каждое движение. Именно поэтому INP стал болью для одностраничных приложений на React, Vue и Angular — там много клиентского JavaScript. Эту специфику мы детально разбираем в материале про JavaScript SEO и продвижение SPA на React.

Решения: как улучшить INP

Разбивка длинных задач

Самый эффективный приём — дробить длинные задачи на маленькие, отдавая управление браузеру между ними. Это называется yielding. Между кусками работы браузер успевает обработать накопившиеся взаимодействия. Современный способ — функция scheduler.yield(), которая корректно возвращает управление и продолжает задачу с приоритетом. Если она недоступна, используют приём с setTimeout или await на промисе, чтобы разорвать длинную задачу. Цель — чтобы ни один кусок не блокировал поток дольше 50 мс.

Debounce и throttle

Обработчики, которые срабатывают часто — на прокрутку, ввод в поле, изменение размера окна, — могут перегружать поток. Приёмы debounce (откладывать выполнение до паузы в действиях) и throttle (ограничивать частоту выполнения) резко снижают нагрузку. Например, поиск по мере ввода стоит запускать не на каждое нажатие клавиши, а с задержкой в 200–300 мс после остановки. Это уменьшает количество работы и освобождает главный поток для отрисовки.

Code-splitting и ленивая инициализация

Не грузите и не выполняйте весь JavaScript сразу. Code-splitting разбивает бандл на части, которые подгружаются по мере необходимости. Ленивая инициализация откладывает запуск тяжёлых компонентов до момента, когда они реально нужны — например, виджет чата инициализируется только при клике, а не при загрузке страницы. Это снижает количество работы в главном потоке в первые секунды, когда пользователь как раз начинает взаимодействовать.

Web Workers и сокращение сторонних скриптов

Тяжёлые вычисления, не связанные с интерфейсом — обработку данных, парсинг, расчёты, — можно вынести в Web Worker. Воркер работает в отдельном потоке и не блокирует главный, поэтому интерфейс остаётся отзывчивым. Отдельная большая статья — сторонние скрипты. Каждый счётчик, пиксель, виджет и чат добавляет работу в главный поток. Проведите ревизию: уберите неиспользуемые, отложите загрузку некритичных, замените тяжёлые на лёгкие альтернативы. Часто именно сокращение сторонних скриптов даёт самый большой выигрыш в INP.

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

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

• Отчёт CrUX и Search Console — реальные значения INP у пользователей, по которым Google ранжирует.
• Библиотека web-vitals.js — собирает INP прямо на вашем сайте и шлёт в аналитику.
• Chrome DevTools — вкладка Performance с записью взаимодействий показывает разбивку по фазам и виновные long tasks.
• Яндекс Вебмастер — дополнительный контроль скоростных показателей для российской аудитории.

Практический подход: соберите полевые данные через Search Console, найдите страницы с плохим INP, затем в DevTools воспроизведите проблемные взаимодействия и посмотрите разбивку по фазам. Так вы точно увидите, где теряется время — в задержке ввода, обработке или отрисовке, — и примените нужное решение. Если у вашего сайта системные проблемы с отзывчивостью, имеет смысл заказать комплексный SEO аудит с разбором производительности.

INP и SPA: особый случай

Одностраничные приложения на React, Vue и Angular страдают от плохого INP чаще всего, потому что весь интерфейс управляется клиентским JavaScript. Каждый клик может запускать перерендеринг компонентов, обновление состояния и пересчёт виртуального DOM. Если эти операции не оптимизированы, главный поток забивается, и отзывчивость падает.

Для SPA особенно важны мемоизация компонентов, чтобы избегать лишних перерисовок, виртуализация длинных списков, чтобы не рендерить тысячи элементов сразу, и перенос вычислений из обработчиков. Также критична оптимизация под мобильные, где железо слабее, — подробнее в гайде про мобильную оптимизацию сайта. Хорошая отзывчивость — часть удобства, поэтому INP тесно связан с общим UX, о чём мы пишем в материале про улучшение юзабилити и UX-аудит.

Чек-лист улучшения INP

1. Соберите полевые данные INP через Search Console и web-vitals.js.
2. Найдите long tasks в DevTools и разбейте их через scheduler.yield.
3. Примените debounce и throttle к частым обработчикам событий.
4. Внедрите code-splitting, чтобы не грузить весь JavaScript сразу.
5. Используйте ленивую инициализацию тяжёлых компонентов.
6. Вынесите тяжёлые вычисления в Web Workers.
7. Проведите ревизию и сократите сторонние скрипты.
8. Для SPA добавьте мемоизацию и виртуализацию списков.
9. Проверяйте результат по 75-му перцентилю полевых данных.

INP — самый требовательный из Core Web Vitals, но и самый честный: он показывает, как ваш сайт ощущается на самом деле. Сделав сайт отзывчивым, вы улучшаете и позиции, и удовлетворённость пользователей, и конверсию. Если вы хотите, чтобы вашей производительностью и продвижением занимались эксперты, закажите SEO-продвижение сайта или начните с SEO-консультации, где мы разберём узкие места и составим план оптимизации.

Услуги LSI Продвижение

Наша команда предлагает полный спектр услуг по SEO-продвижению и технической доработке сайтов. Мы работаем только белыми методами, ориентируемся на реальный бизнес-результат — трафик, заявки и продажи, а не только позиции в отчёте, — и выстраиваем продвижение системно, под конкретные задачи и нишу вашего проекта. Начать можно с бесплатной диагностики, чтобы понять текущее состояние сайта и точки роста, а затем перейти к комплексной работе. Выберите подходящую услугу из списка ниже:

• Бесплатный SEO аудит сайта — автоматическая проверка на 50+ параметров за 2 минуты
• Комплексный SEO аудит — глубокий ручной анализ с рекомендациями от эксперта
• Продвижение сайтов — вывод в ТОП Яндекса и Google по целевым запросам
• SEO консультация — разбор вашего сайта с конкретными рекомендациями
• LSI тексты — экспертный контент, оптимизированный для поисковых систем
• Доработка сайта — техническая оптимизация и исправление ошибок
• Создание сайта под ключ — разработка с нуля с SEO-оптимизацией
• Стоимость продвижения — прозрачные тарифы и условия
• Портфолио и кейсы — реальные результаты наших клиентов