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

У ТБТ есть ограничения в качестве замены INP.

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

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

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

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

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

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

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

«Я вижу обычную закономерность — задерживать ВСЕ JS до тех пор, пока пользователь не взаимодействует со страницей: отлично подходит для оценок Lighthouse! Часто ужасно для пользователей ?:

• Иногда ничего не загружается, пока не подвигаешь мышкой.
• Часто ваше первое взаимодействие происходит с большей задержкой».

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

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

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

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

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

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

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

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

1. Используйте «потоки пользователей» Lighthouse для измерения INP в обычных поездках.
2. Автоматизируйте потоки пользователей в CI, чтобы отслеживать INP и выявлять регрессии.
3. Используйте TBT в качестве прокси-сервера INP, но помните о его ограничениях.
4. Отдавайте приоритет полевым измерениям для получения точных данных ИЯФ.
5. Сбалансируйте оптимизацию производительности с соображениями UX.

---

Рекомендованное изображение: Йе Лью/Shutterstock