Инструмент Google Lighthouse не учитывает показатель INP. Адвокат разработчиков веб-производительности из команды Google Chrome объясняет, почему.

• Lighthouse не может измерить INP напрямую из-за отсутствия взаимодействия с пользователем.
• Общее время блокировки служит показателем INP в тестах Lighthouse.
• Настраиваемые потоки пользователей позволяют измерять INP для известных действий пользователя.

Google Lighthouse не использует метрику Interaction to Next Paint (INP) в своих стандартных тестах, несмотря на то, что INP является одним из основных веб-показателей.

<стр>Барри Поллард, представитель разработчиков веб-производительности в Google Chrome, объяснил причину этого и предложил идеи по измерению INP.

Lighthouse измеряет загрузку страницы, а не взаимодействие

Lighthouse измеряет простую загрузку страницы и фиксирует различные характеристики во время этого процесса.

Он может оценить наибольшую отрисовку контента (LCP) и совокупный сдвиг макета (CLS) при определенных условиях нагрузки, выявить проблемы и дать рекомендации по улучшению этих показателей.

Однако INP отличается и зависит от взаимодействия с пользователем.

Поллард объяснил:

“Проблема в том, что Lighthouse, как и многие другие веб-инструменты, обычно просто загружает страницу и не взаимодействует с ней. Нет взаимодействий = нет INP для измерения!”

Настраиваемые пользовательские потоки включения измерения INP

Хотя Lighthouse не может измерить INP, знание общих путей пользователя позволяет вам использовать “потоки пользователей” для измерения INP.

Поллард добавил:

<блоковая цитата><п>“Если вы, как владелец сайта, знаете свои общие действия пользователей, вы можете измерить их в Lighthouse с помощью ‘потоков пользователей’ который затем БУДЕТ измерять INP.”

Эти обычные действия пользователей можно автоматизировать в среде непрерывной интеграции, что позволяет разработчикам тестировать INP при каждом коммите и выявлять потенциальные регрессии.

Общее время блокировки в качестве прокси-сервера INP

Хотя Lighthouse не может измерить INP без взаимодействия, он может измерить вероятные причины, особенно длительные, блокировки задач JavaScript.

Здесь вступает в игру показатель общего времени блокировки (TBT).

По Полларду:

“TBT (общее время блокировки) измеряет суммарное время всех задач длительностью более 50 мс. Теория такова:

<ул>

Много длинных блокирующих задач = высокий риск INP!

<ли>Мало длительных блокирующих задач = низкий риск INP!”

Ограничения использования ТБТ в качестве заменителя INP

TBT имеет ограничения в качестве замены INP.

Поллард заметил:

“Если вы не взаимодействуете во время длительных задач, возможно, у вас не возникнет проблем с INP. Кроме того, взаимодействия могут загружать БОЛЬШЕ JavaScript, который не измеряется Lighthouse.”

<п>Он добавляет:

“Так что это подсказка, но не замена фактическому измерению INP.”

Оптимизация показателей Lighthouse в зависимости от пользовательского опыта

Некоторые разработчики оптимизируют показатели Lighthouse, не учитывая влияние на пользователя.

Поллард предостерегает от этого, заявляя:

“Общим шаблоном, который я вижу, является задержка ВСЕХ JS до тех пор, пока пользователь не взаимодействует со страницей: отлично подходит для оценки Lighthouse! Часто ужасно для пользователей 😢:

<ул>

Иногда ничего не загружается, пока вы не переместите мышь.

Часто ваше первое взаимодействие происходит с большей задержкой.”

Полный пост Полларда

Почему это важно

<стр>Понимание взаимоотношений Lighthouse, INP и TBT необходимо для оптимизации взаимодействия с пользователем.

Признание ограничений в измерении INP помогает избежать ошибочной оптимизации.

Совет Полларда по измерению INP — сосредоточиться на реальных взаимодействиях с пользователем, чтобы обеспечить улучшение производительности и улучшение UX.

Поскольку INP остается ключевым элементом сети, понимание его нюансов необходимо для поддержания его в пределах приемлемого порога.

Практическое применение

Для мониторинга производительности сайта и INP:

<ол>

Использовать “потоки пользователей” Lighthouse” для измерения INP в обычных поездках.

Автоматизировать потоки пользователей в CI для мониторинга INP и выявления регрессий.

Используйте TBT в качестве прокси-сервера INP, но помните о его ограничениях.

Уделяйте приоритетное внимание полевым измерениям для получения точных данных INP.

Сбалансируйте оптимизацию производительности с учетом UX.