Страница быстро открылась, изображение появилось, тест загрузки выглядит хорошо. Но при вводе в поиск буквы запаздывают, а раскрытие меню ощущается вязким. Скорость первого экрана и скорость реакции на действия пользователя измеряют разные части опыта.
Interaction to Next Paint оценивает отзывчивость взаимодействий. В рекомендациях web.dev для полевых данных хороший уровень — до 200 мс включительно, плохой — больше 500 мс; оценку рассматривают на 75-м процентиле посещений отдельно для мобильных и настольных устройств. Одно измерение на мощном компьютере не характеризует всю аудиторию. web.dev: INP
Разобрать одно действие
Возьмём учебный каталог из нескольких тысяч строк. При каждом вводе символа приложение фильтрует данные, пересоздаёт результаты и пересчитывает несколько счётчиков. Пользователь замечает задержку, но причина не обязана находиться только в функции фильтрации.
Время взаимодействия можно разделить на ожидание начала обработчика, выполнение обработчиков и задержку представления следующего кадра. Такой разбор помогает выбрать правильное место оптимизации. web.dev: optimize INP
Пусть в вымышленной трассе эти части составляют 180, 20 и 20 мс. Сократить двадцатимиллисекундный обработчик вдвое полезно, но большая часть задержки останется до его запуска. Сначала нужно найти работу, которая в это время занимала основной поток.
Видимый отклик и тяжёлая работа
Для поиска по каталогу можно разделить состояние введённого текста и обновление результатов. Поле должно сразу показывать ввод. Дальнейший расчёт ограничивают последним актуальным запросом, а устаревший ответ не должен затереть новый.
Debounce уменьшает число запусков, но добавляет собственную паузу. Его выбирают по сценарию, а не потому, что это привычный рецепт для любого торможения. Если задержка вызвана огромной перерисовкой после расчёта, одна пауза перед тем же расчётом проблему не решит.
Для тяжёлого чистого вычисления можно рассмотреть worker. Для слишком большого DOM — уменьшение одновременно отображаемой части списка. Но у таких решений есть стоимость: передача данных между потоками, логика доступности, поиск браузера по странице. Изменение должно отвечать найденной причине.
Анимация тоже расходует бюджет
Красивое раскрытие результатов не должно заставлять браузер заново вычислять раскладку тысяч элементов на каждом кадре. Полезно проверить, какие свойства анимируются и сколько областей страницы затронуто. Даже небольшая декоративная сцена способна мешать вводу, если её код постоянно работает в основном потоке.
В учебном сравнении выполняют одно и то же действие с включённой и отключённой декорацией. Если разница заметна, украшение нужно упростить или останавливать вне видимой области. Системный reduced motion задаёт дополнительное требование к движению, но не заменяет проверку производительности обычного режима.
Не оптимизировать по одной удачной записи
Для воспроизводимого сравнения фиксируют устройство, данные каталога и действие: например, последовательный ввод трёх символов после завершения загрузки. Затем отдельно проверяют ввод во время инициализации страницы и после нескольких минут работы.
В сценарии с сетью имитируют ответы в обратном порядке. Более быстрый интерфейс, который показывает результат старого запроса вместо нового, функционально хуже исходного. Поэтому рядом с временем реакции проверяют корректность видимого состояния.
После локального улучшения наблюдают полевые данные, если они собираются с подходящими настройками и разрешениями. Мобильные устройства, тяжёлые страницы и длинные сеансы могут вести себя иначе, чем короткий прогон в лаборатории. Цель — не зелёное число в одном отчёте, а предсказуемый ответ на действие пользователя.