Инструмент Google Lighthouse пропускает метрику INP. Адвокат разработчиков Web Performance из команды Google Chrome объясняет почему.
- Lighthouse не может напрямую измерить INP из-за отсутствия взаимодействия с пользователем.
- Общее время блокировки служит прокси для INP в тестах Lighthouse.
- Пользовательские потоки пользователей позволяют измерять INP для известных путей пользователя.
Google’s 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!”
Ограничение TBT как заменителя INP
TBT имеет ограничение как заменитель INP.
Поллард отметил:
“Если вы не’не взаимодействуете во время длительных задач, возможно, у вас не будет никаких проблем с INP. Также взаимодействия могут загружать БОЛЬШЕ JavaScript, который не измеряется Lighthouse.&~~~~~~~~~~~~~~~~~
Он добавляет:
“Итак, это подсказка, но не замена фактического измерения INP.”
Оптимизация для баллов Lighthouse против взаимодействия с пользователем
Некоторые разработчики оптимизируют оценки Lighthouse, не учитывая влияние на пользователей.
Поллард предостерегает от этого, заявляя:
“Распространенной схемой, которую я вижу, является задержка ВСЕХ JS, пока пользователь не взаимодействует со страницей: отлично для балов Lighthouse! Часто ужасно для пользователей:
- Иногда ничего не загружается, пока вы не переместите мышь.
- Часто ваше первое взаимодействие имеет большую задержку.”
Полное сообщение Полларда
Почему это важно
Понимание отношений Lighthouse, INP и TBT необходимо для оптимизации взаимодействия с пользователем.
Признание ограничений в измерении INP помогает избежать ошибочной оптимизации.
Совет Полларда по измерению INP состоит в том, чтобы сосредоточиться на реальном взаимодействии с пользователем, чтобы гарантировать, что улучшение производительности улучшает UX.
Поскольку INP остается Core Web Vital, понимание его нюансов имеет важное значение для того, чтобы поддерживать его в пределах приемлемого порога.
Практические применения
Для мониторинга производительности сайта и INP:
<ол>
Использование “потоков пользователей”Lighthouse’ для измерения INP в обычных поездках. Автоматизируйте потоки пользователей в CI для мониторинга INP и выявления регрессий. Используйте TBT как прокси INP, но поймите его ограничения. Предоставьте приоритет полевым измерением для получения точных данных INP. Сбалансируйте оптимизацию производительности с учетом UX.