Взаимодействие со следующей отрисовкой (INP)

Показатель Interaction to Next Paint измеряет скорость визуальной реакции страницы на ввод пользователя, отображая значение, отражающее наихудшие задержки взаимодействия, наблюдаемые во время посещения. В марте 2024 года он заменил First Input Delay в качестве метрики отзывчивости Core Web Vitals, и это изменение было значительным: если старый показатель фиксировал только задержку до начала обработки при первом взаимодействии, то этот измеряет полную продолжительность от ввода до обработки и до отрисовки следующего кадра, для всех взаимодействий в рамках сессии.

Эта разница важна, потому что прежний показатель льстил многим сайтам. Страница могла демонстрировать отличную задержку при первом вводе, оставаясь при этом медленной на протяжении всего процесса, поскольку этот показатель игнорировал время выполнения обработчика событий и время, необходимое браузеру для отображения результата, а также потому, что он учитывал только одно взаимодействие. Сайты, которые казались отзывчивыми по старому показателю, часто перестают таковыми быть по новому, особенно одностраничные приложения и любые интерфейсы с интенсивной логикой на стороне клиента.

Приведенное значение получено на основе самых длительных наблюдаемых взаимодействий, с учетом выбросов на страницах с большим количеством взаимодействий. Опубликованный Google пороговый уровень считает значение 200 миллисекунд или меньше хорошим показателем, соответствующим 75-му процентилю реального пользовательского опыта. Поскольку он охватывает весь путь от ввода до отрисовки, низкие оценки могут быть вызваны несколькими причинами: длительные задачи в основном потоке, блокирующие обработку события браузером, чрезмерная синхронная работа обработчиков событий, сбои в компоновке, вызванные чередованием чтения и записи стилей, и дорогостоящая отрисовка после изменения состояния.

Диагностика обычно указывает на выполнение JavaScript, а не на состояние сети, что отличает этот показатель от показателей загрузки. К распространенным причинам относятся большие монолитные пакеты, выполняющиеся в основном потоке, сторонние скрипты, выполняющие произвольную работу во время взаимодействия, перерисовка фреймворка, затрагивающая гораздо большую часть дерева, чем требуется для изменения, и обработчики, выполняющие синхронные вычисления, которые можно отложить или перенести из основного потока. В большинстве случаев в основе лежит механизм длительных задач, поскольку браузер не может реагировать на ввод, пока задача выполняется.

После диагностики следует устранение проблемы. Разбиение длительных задач на более мелкие части с явным указанием приоритетов позволяет браузеру обрабатывать ввод между ними. Откладывание некритичной работы до момента визуального обновления, чтобы пользователь сразу увидел ответ, решает наиболее распространенную проблему. Сокращение объема используемого JavaScript, проверка сторонних скриптов на предмет затрат на основной поток, виртуализация длинных списков и перенос ресурсоемких вычислений на рабочий процесс — все это решает конкретные причины. Предоставление немедленной визуальной обратной связи для медленных операций не улучшает измеряемый показатель, но меняет восприятие задержки.

Скрипты сторонних разработчиков заслуживают особого внимания, поскольку они часто являются причиной сбоев и находятся вне прямого контроля команды. Виджеты чата, менеджеры согласия, аналитические библиотеки, инструменты персонализации и рекламные скрипты — все они выполняются в основном потоке и могут занимать его именно в те моменты, когда посетитель пытается взаимодействовать с сайтом. Аудит затрат на основной поток каждого стороннего разработчика, в идеале путем измерения производительности страницы с ним и без него, позволяет получить конкретный список затрат каждого поставщика с точки зрения адаптивности. Эта цифра позволяет обсудить компромисс с командами, которые запросили каждый инструмент, что обычно является более продуктивным подходом, чем попытка оптимизировать код приложения вокруг скрипта, который поглощает большую часть доступного бюджета.

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