Фильтр срабатывает с паузой, меню открывается не сразу, а текст появляется позже нажатия клавиш. Страница при этом может загружаться быстро. Чтобы найти причину, нужно проверить отклик после действия и работу JavaScript. Для приложений с Worker и iframe в этот разбор входит ещё и обмен сообщениями.
Почему быстрый сайт может медленно отвечать на действия
После клика браузеру нужно обработать событие, выполнить JavaScript и показать обновлённый кадр. Если главный поток занят, часть работы ждёт своей очереди. Поэтому хорошая скорость загрузки ещё не гарантирует быстрый отклик меню, фильтров и форм.
Перенос вычислений в Web Worker освобождает главный поток, но добавляет обмен данными. Окно страницы, Worker и iframe передают сообщения через postMessage(). Отправленное сообщение тоже может ждать обработки.
Где возникают задержки в очереди сообщений
Начните с трёх возможных причин:
- Получатель выполняет долгую синхронную задачу. Новое сообщение будет обработано, когда поток освободится.
- Сообщений слишком много. Даже короткие обработчики создают очередь, если работа поступает быстрее, чем выполняется.
- Передаётся большой объём данных. Сериализация у отправителя и десериализация у получателя требуют времени на соответствующих потоках.
Например, поиск отправляет Worker новый запрос после каждой введённой буквы. Если расчёт предыдущей выдачи ещё идёт, следующие запросы накапливаются. Человек уже дописал слово, а приложение продолжает считать результаты для старого ввода. Здесь стоит измерить частоту сообщений, время обработки и объём передаваемых данных.
Как INP измеряет отклик страницы
INP, Interaction to Next Paint, оценивает отзывчивость страницы на клики, тапы и нажатия клавиш за время посещения. Итоговое значение отражает одно из самых медленных взаимодействий с учётом правил исключения выбросов. Задержка отдельного взаимодействия состоит из ожидания начала обработки, выполнения обработчиков и времени до показа следующего кадра.
Хорошее значение INP составляет не более 200 мс. Диапазон свыше 200 до 500 мс требует улучшения, свыше 500 мс считается плохим. Для оценки сайта используют 75-й процентиль посещений отдельно на мобильных и настольных устройствах.
Очередь сообщений может влиять на эту задержку, когда её обработка занимает главный поток и мешает вводу или отрисовке. Но время ответа Worker нельзя автоматически считать INP.
Вернёмся к поиску: введённая буква может появиться сразу, а выдача обновиться позже. Следующий кадр уже показан, хотя полезная работа ещё не завершена. В таком сценарии измеряйте отдельно отклик на ввод и время до актуальных результатов. Быстрый индикатор загрузки не доказывает, что сам поиск стал быстрее.
Проверка INP и анализ JavaScript в Milten
Проверка INP помогает исследовать задержки взаимодействий в тестовом запуске. Выберите страницу с проблемным действием: меню, каталог, форму или корзину. В отчёте проверьте, какие взаимодействия были выполнены и какие причины задержек обнаружены. Вывод относится к этому прогону и его условиям.
JS Scanner анализирует JavaScript при загрузке одной страницы в Chromium, без кликов и прокрутки. Он показывает размеры и загрузку скриптов, выполнение кода, долгие задачи, ошибки и скрипты с другим именем хоста. Карта модулей внутри бандлов доступна, если сайт отдаёт source maps.
Сопоставляйте отчёты, чтобы выбрать участок для проверки. Тяжёлый файл в JS Scanner может объяснять нагрузку при старте страницы, но его присутствие ещё не доказывает причину медленного клика. Поведение после загрузки нужно воспроизвести отдельно. Оба инструмента помогают сузить поиск; они не дают трассировку каждого сообщения между всеми окнами и Workers.
Неисполненный при загрузке код может понадобиться после клика или в другом состоянии страницы. Перед удалением проверьте эти сценарии. Скрипт с другим именем хоста тоже не обязательно лишний: в эту группу может попасть собственный CDN проекта.
Как найти причину плохого INP
- Запишите шаги воспроизведения. Укажите страницу, устройство и состояние интерфейса. Например: открыть каталог, быстро ввести запрос, затем выбрать фильтр.
- Если есть RUM или CrUX, используйте полевые данные, чтобы выбрать наиболее заметную проблему. Лабораторный прогон не заменяет статистику реальных посещений.
- Запустите проверку INP и сопоставьте охват отчёта с проблемным действием. Если оно не было воспроизведено, исследуйте его отдельно в браузере.
- Изучите загрузку JavaScript через JS Scanner. Выберите подозрительные файлы и долгие задачи, которые могут пересекаться с задержкой.
- Запишите проблемный сценарий в DevTools. Для Worker или iframe проследите отправку сообщения, начало обработки, ответ и обновление экрана. Идентификаторы запросов помогут отличить ответ на старый ввод от текущего.
- После исправления повторите те же действия при одинаковых настройках устройства, CPU и сети. Сравните несколько прогонов, затем проверьте полевые данные по мере их накопления.
Что менять для оптимизации INP
Оптимизация INP начинается с сокращения работы, которая задерживает следующий кадр. Уменьшайте синхронные обработчики, разбивайте длинные задачи и позволяйте браузеру отрисовать обратную связь до необязательных вычислений.
В приложении с Worker проверьте, нужна ли вся отправляемая работа. Для поиска можно объединять частые обновления и отбрасывать устаревшие результаты. Подбирайте задержку отправки по поведению интерфейса: слишком большой debounce сам замедлит поиск для пользователя.
Сократите сообщения до данных, необходимых получателю. Вместо всего каталога после каждого изменения фильтра иногда достаточно передавать параметры запроса. Для подходящих бинарных данных рассмотрите transferable objects. Учитывайте передачу владения: переданный буфер становится недоступен отправителю.
Проверяйте каждую гипотезу отдельно. Если уменьшили объём сообщения, сравните время передачи и обработки. Если перенесли вычисление, проверьте отклик интерфейса и время до результата. Так будет видно, какая правка помогла.
Можно ли автоматически увидеть перегрузку очередей
В предложении WICG диагностика таких задержек развивается в сторону расширения Long Animation Frames API. Текущий вариант посвящён устойчивой перегрузке очередей в документах и Workers. Измерение каждого отдельного сообщения и стоимости сериализации не входит в это расширение.
Это экспериментальное предложение, поэтому не стоит строить обязательную диагностику на примере наблюдения за delayed-message из ранних материалов. Для работы сейчас достаточно начать с воспроизводимого сценария, INP Scanner, анализа JavaScript и записи в DevTools. Выберите одно медленное действие и проверьте весь путь до нужного пользователю результата.