# Высокий INP: как найти, почему кнопка отвечает с задержкой
Если кнопка, меню или поле формы реагирует не сразу, не начинайте с безадресного «ускорения JavaScript». Сначала найдите конкретное медленное действие и разделите его задержку на три части: ожидание свободного главного потока, выполнение обработчика и отрисовку результата.
Такой разбор показывает, где находится причина. Длинная задача до клика, тяжёлый обработчик и дорогая перерисовка выглядят для пользователя одинаково, но исправляются по-разному.
Что именно показывает INP
Interaction to Next Paint, или INP, измеряет время от клика, касания или нажатия клавиши до следующего кадра с визуальным откликом. Метрика оценивает взаимодействия за всё посещение страницы, а не только первый клик.
Для полевых данных ориентир хорошей отзывчивости — INP не более 200 мс на 75-м процентиле отдельно для мобильных и настольных устройств. Значение свыше 200 и до 500 мс требует улучшения, свыше 500 мс считается плохим. Это ориентиры для распределения реальных посещений, а не обещание, что один локальный замер будет таким же.
Отсутствие INP тоже не означает, что страница быстрая: возможно, посетители не совершали учитываемых действий или для URL недостаточно полевых данных.
Зафиксируйте медленный сценарий
До профилирования запишите четыре вещи:
- URL и состояние страницы: сразу после загрузки, после открытия модального окна, после заполнения формы.
- Действие: какая кнопка, ссылка или клавиша вызывает задержку.
- Среда: мобильное или настольное устройство, браузер, авторизованный или публичный режим.
- Ожидаемый отклик: смена состояния кнопки, открытие меню, появление сообщения или обновление части страницы.
Проверьте полевые данные в PageSpeed Insights, Search Console или своей системе RUM. Они отвечают на вопрос, есть ли проблема у реальных посетителей. Затем воспроизведите тот же сценарий локально — именно локальная запись поможет найти код и этап задержки.
Не смешивайте разные страницы и действия в один диагноз. Плохой INP карточки товара не доказывает, что причина та же, что у формы заказа.
Запишите взаимодействие в Chrome DevTools
Откройте страницу в чистом профиле браузера без лишних расширений, затем перейдите в панель Performance. В Live metrics выполните проблемное действие несколько раз. Если задержка повторяется, запишите трассировку:
- Запустите запись в Performance.
- Повторите только нужный сценарий.
- Остановите запись и найдите действие на дорожке Interactions.
- Откройте Summary и сравните input delay, processing duration и presentation delay.
- Посмотрите дорожку Main рядом с этим интервалом и дерево вызовов Bottom-Up.
Используйте замедление процессора, если проблема заметна главным образом на менее мощных устройствах. Но не подбирайте искусственные настройки ради плохого результата: цель — воспроизвести реальную среду, а не получить эффектный график.
Ветка 1. Большой input delay
Input delay — время между действием пользователя и запуском его обработчиков. Если эта часть самая длинная, главный поток уже был занят другой работой.
Смотрите на задачи непосредственно перед взаимодействием. Частые причины — разбор и выполнение большого JavaScript при загрузке, сторонний виджет, таймер, обработка большого массива или предыдущая операция, которая не уступает главный поток.
Порядок исправления:
- удалите код, который не нужен для текущего экрана;
- отложите необязательные и сторонние скрипты;
- разбейте длинную работу на отдельные задачи, чтобы браузер мог обработать ввод между ними;
- не запускайте тяжёлую фоновую операцию в момент, когда пользователь уже может нажать кнопку;
- для вычислений без доступа к DOM рассмотрите Web Worker.
Не ограничивайтесь обработчиком самой кнопки. Он может быть быстрым, а клик ждать завершения совсем другого скрипта.
Ветка 2. Долгий processing duration
Processing duration — выполнение обработчиков события. Здесь причина обычно находится внутри логики клика, ввода или нажатия клавиши.
В Bottom-Up найдите функции, которые заняли основное время. Проверьте, нет ли в обработчике полной фильтрации большого списка, синхронной сериализации, повторных вычислений, массового создания узлов или нескольких последовательных обновлений состояния.
Оставьте до следующего кадра только то, что нужно для понятного визуального ответа: показать нажатое состояние, открыть панель, вывести индикатор или применить введённый символ. Аналитику, автосохранение и вторичные расчёты можно выполнить позже, если это не нарушает целостность операции.
Простая задержка через debounce не всегда лечит INP. Она полезна для серии вводов, но может лишь перенести тяжёлую работу и не поможет одиночному клику. Сначала уменьшите сам объём синхронной работы.
Ветка 3. Большой presentation delay
Presentation delay начинается после обработчиков и заканчивается показом следующего кадра. Большое значение указывает на дорогие пересчёты стилей, layout, paint или слишком крупное обновление DOM.
Проверьте в трассировке события Recalculate Style, Layout и Paint. Особое внимание уделите коду, который сначала меняет стили, а затем в той же задаче читает размеры элемента: такая последовательность может принудительно запускать синхронный layout.
Практические меры:
- сгруппируйте чтения геометрии отдельно от изменений DOM;
- обновляйте небольшой контейнер, а не перестраивайте весь экран;
- уменьшите число узлов, затрагиваемых одним действием;
- проверьте дорогие селекторы, большие таблицы, списки и визуальные эффекты;
- не переносите тяжёлую работу в requestAnimationFrame как формальный «фикс»: код там всё ещё может заблокировать ближайшую отрисовку.
Если кнопка запускает запрос к серверу, покажите начальный безопасный отклик до ожидания ответа. INP оценивает ближайшую визуальную реакцию, а полное время операции нужно измерять отдельно по сети и серверным логам.
Как проверить исправление
Повторите тот же сценарий на той же странице и при тех же настройках. Сравнивайте не случайные общие баллы, а длительность конкретного взаимодействия и его доминирующую часть.
Исправление можно считать технически подтверждённым, когда:
- проблемное действие стабильно стало быстрее в нескольких записях;
- исчезла или сократилась исходная длинная фаза;
- результат остаётся корректным для мыши, касания и клавиатуры;
- ускорение не сломало сохранение данных, аналитику или доступность;
- после выкладки полевые данные постепенно подтверждают улучшение.
Полевые отчёты агрегируются и обновляются не мгновенно. Не откатывайте рабочее исправление только потому, что на следующий день в отчёте ещё виден прежний период.
Где заканчивается диагностика INP
INP не учитывает прокрутку и наведение без клика, касания или нажатия клавиши. Он также не заменяет измерение API, времени ответа сервера и успешности бизнес-операции. Быстрый первый кадр бесполезен, если заказ затем не сохранился; успешный ответ сервера не делает интерфейс отзывчивым автоматически.
Если задержка вызвана доступностью страницы или временем внешнего ответа, Web-Puls может регулярно контролировать публичный URL и сообщать о сбое. Но причину медленной кнопки всё равно нужно подтверждать полевыми данными и трассировкой браузера.
После исправления добавьте критичный публичный URL в мониторинг, чтобы отдельно контролировать доступность и время ответа, а INP продолжайте проверять через RUM и полевые отчёты.