Пользователь нажимает фильтр и не понимает, произошло ли что-нибудь. Команда ускоряет сервер, уменьшает картинки, но ощущение зависания остаётся. Возможно, задержка находится в работе браузера между действием и следующим кадром. Для её диагностики нужен разбор конкретного взаимодействия, а не общий балл скорости страницы.
Что измеряет INP и где заканчивается его ответственность
INP оценивает отзывчивость по взаимодействиям во время посещения страницы. Ориентир хорошего значения — не более 200 миллисекунд; оценку обычно рассматривают на 75-м процентиле посещений с разделением мобильных и настольных устройств. При расчёте предусмотрено исключение отдельных крайних взаимодействий в длинных сессиях. Источник: описание метрики и её границ.
Метрика относится к возможности показать следующий кадр после взаимодействия. Она не обязана включать весь последующий сетевой запрос и завершение бизнес-операции. Кнопка может быстро показать индикатор ожидания, а результат поиска появится значительно позже. Для посетителя важны оба момента, поэтому измеряйте их раздельно.
Одна задержка состоит из трёх разных задач
Руководство по оптимизации взаимодействий разделяет ожидание начала обработки, выполнение обработчиков и задержку представления следующего кадра. Приоритет исправления зависит от того, какая часть занимает время. Один и тот же итоговый показатель может скрывать разные причины.
В учебном примере нажатие ждёт, пока браузер завершит тяжёлую фоновую работу. В другом сценарии сам обработчик перебирает большой набор данных. В третьем вычисления уже закончились, но изменение интерфейса требует трудоёмкой отрисовки. Совет «ускорить кнопку» не помогает разработчику выбрать между этими случаями.
Начните с взаимодействия реального пользователя
Для медленного события соберите тип страницы, элемент, характер действия, фазу загрузки и версию выпуска. Добавьте категорию устройства. Не записывайте содержимое полей ввода: для поиска технической причины обычно достаточно обезличенного контекста взаимодействия.
Затем воспроизведите именно этот путь: открытие меню после согласия на обработку данных, применение нескольких фильтров подряд или переключение вкладки после долгого чтения. Тест только первого экрана может никогда не запустить тяжёлую часть интерфейса. Сравнение с мощным рабочим компьютером также не заменяет условия слабого телефона.
Проверяйте распределение, а не среднее улучшение
Среднее по сайту способно измениться из-за состава посещений. Если после рекламной кампании выросла доля простых страниц, агрегированный показатель может улучшиться без исправления проблемного шаблона. Сопоставляйте одинаковые типы страниц, устройства и периоды, отмечая объём наблюдений.
Разделяйте холодный запуск и последующие действия. Повторное открытие компонента иногда использует уже подготовленные данные; первое — ещё загружает и вычисляет их. Отчёт, в котором эти сценарии смешаны, затрудняет воспроизведение. Полезно прямо указать, какой шаг был первым и сколько действий выполнено до него.
Быстрая реакция не должна подменять готовый результат
Мгновенный индикатор ожидания полезен, когда честно сообщает о процессе. Он не должен выглядеть как подтверждение завершения. Проверяйте отдельно время до визуальной реакции и время до фактического результата: применения фильтра, сохранения настройки или принятия обращения.
Для форм эту границу дополняет проверка доставки заявки. Для тяжёлых издательских страниц исследуйте также нагрузку рекламных компонентов. Хорошая метрика одного действия не отменяет других препятствий на пути пользователя.
Как поставить задачу и принять исправление
В задаче укажите точный сценарий, устройство, замедленную фазу и исходный результат. После изменения повторите сценарий, затем проверьте сопоставимые полевые наблюдения. Не обещайте рост позиций на основании одного лабораторного измерения: улучшение отзывчивости и изменение поискового спроса относятся к разным уровням анализа.
Технический аудит используйте для общего состояния страниц, а подробную запись взаимодействия — для поиска причины задержки. В отчёте для клиента отделяйте исправленный дефект, изменение пользовательской метрики и последующую динамику поиска. Это делает результат проверяемым и защищает от ложного объяснения любого роста одной доработкой.