Обновление Google Lighthouse: что, зачем и почему

Вовсю разворачивается новый апдейт Google Core Web Vitals, а вебмастера тщательно оттачивают параметры TBT и FCP своих проектов. Тем временем команда Lighthouse выпустила обновление сервиса, где оптимизировала расчет CLS и пересчитала значимость каждого параметра в совокупной оценке производительности сайта.

Подробнее в материале с github о методах расчета параметров производительности, сборе аналитических данных в Lighthouse и CWV, и том, какими сервисами пользоваться для оптимизации сайта под Core Web Vitals.

Перевод материала https://github.com/GoogleChrome/lighthouse/blob/master/docs/v8-perf-faq.md

Напомним о математических расчетах, лежащих в основе показателей Lighthouse и оценки производительности. В Lighthouse v8.0 параметры FCP и TBT оцениваются более строго. Обновили CLS: по-новому вычисляется значение сдвига макета. Кроме того, общая оценка производительности была переформирована — мы придали больше веса факторам CLS и TBT, немного снизили значимость метрик FCP, SI и TTI.

Было:

Стало:

Мы проанализировали около миллиона URL в HTTP Archive и пришли к выводу, что с обновлением Lighthouse 8.0 оценка производительности для большинства сайтов останется такой же или даже улучшится.

~ 20% сайтов — оценка упадет до 5 пунктов и менее.

~ 20% сайтов — оценка Lighthouse изменится незначительно.

~ 30% сайтов — оценка станет лучше на несколько пунктов.

~ 30% сайтов — оценка вырастет на 5 пунктов и более.

Причина падения оценки производительности связана с ужесточением расчета значения TBT и повышением значимости этой метрики в общей доле оценки. В основном улучшения оценок Lighthouse также связаны с изменениями TBT в длительном периоде рендеринга, перерасчетом метрики CLS, а также с повышением значимости обеих метрик в совокупной оценке производительности.

Изменение значимости по метрикам:

Изменение значимости по фазам:

Метрика была представлена в предыдущей версии Lighthouse v6, но была не до конца проработанной. Мы внесли в метрику CLS ряд улучшений и исправлений, в том числе благодаря письмам вебмастеров. Значимость CLS увеличилась с 5% до 15%. Это связано с не только с усовершенствованием формулы расчета оценки, но и с включением метрики в параметры Core Web Vitals.

Почему показатели Core Web Vitals оцениваются по-разному?

Показатели Core Web Vitals являются независимыми сигналами Page Experience. Мы считаем, что при оценке значимости показателей Lighthouse основывается на подходе, который улучшает пользовательское взаимодействие со страницей.

Показатели LCP, CLS и TBT — это три наиболее значимые метрики оценки производительности в Lighthouse и Core Web Vitals.

Core Web Vitals ссылаются на набор ключевых UX-метрик, привязаны к их пороговым значениям и процентилю измерения этих метрик. В целом, CWV фокусируется на данных наблюдений.

*Прим. Данные наблюдений — «полевые данные», сведения в отчете об удобстве пользования браузером Chrome.

Оценка Lighthouse — это средство понимания уровня текущих возможностей для улучшения некоторых элементов UX. Чем ниже оценка, тем выше вероятность, что пользователь столкнется с трудностями при взаимодействии со страницей.

Синтетические (лабораторные) данные Lighthouse частично совпадают с данными Core Web Vitals. В Lighthouse поддерживаются два из трех основных показателей (LCP и CLS) с такими же порогами прохождения при тестировании страницы, как и в Core Web Vitals.

В Lighthouse нет возможности просчитать время от загрузки страницы до первого взаимодействия пользователя со страницей из-за особенностей синтетического сбора данных, поэтому Lighthouse не вычисляет FID, например. Вместо этого в Lighthouse есть TBT, который можно рассматривать как прокси-метрику для FID. Хотя эти два показателя измеряют разные вещи, они оба показывают уровень интерактивности страницы.

Наиболее эффективен комбинированный подход. Используйте данные наблюдений (CWV) для долгосрочного UX-мониторинга и синтетические данные (Lighthouse), чтобы создать наилучший возможный UX-сценарий рендеринга страницы.

CrUX суммирует данные за последние 28 дней, поэтому потребуется терпение и время, чтобы измерить корреляцию между изменениями на сайте и оценкой производительности. Отчеты Lighthouse позволяют отладить и оптимизировать среду, которая воспроизводится с немедленной обратной связью. Кроме того, синтетические инструменты могут предоставить значительно больше критических деталей, чем инструменты наблюдений CrUX, так как они не ограничены лимитами API других веб-ресурсов.

Синтетические данные Lighthouse и данные наблюдений CrUX не совпадают, но любое существенное улучшение синтетических показателей будет заметно и в наблюдениях после обновления. Чем выше оценка Lighthouse, тем меньше потерь в инструменте наблюдений.

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

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

Мобильные отчеты Lighthouse имитируют слабую 4G-связь на устройствах Android. Такой анализ помогает улучшить взаимодействие с вашим сайтом, когда данные наблюдений не предоставляют таких условий. Lighthouse находит наихудший пользовательский опыт, который нельзя увидеть в данных наблюдений. Это актуально в ситуациях, когда UX-взаимодействие было настолько плохим, что пользователь больше не возвращался на страницу, а значит, не был затрекан для статистики.

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

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

Таким образом, iframe, включая те, что вы не можете контролировать, могут добавлять дополнительные сдвиги макета, а это влияет на оценку CLS. Имейте в виду: вклад сабфреймов измеряется в окне iframe в области просмотра.

Общие черты между TBT (собранному в синтетической среде) и FID (собранному в контексте поля) заключаются в том, что они измеряют влияние на отклик пользовательскому вводу при загрузке длинных задач в основном потоке. В остальном они абсолютно разные. FID измеряет время задержки между пользовательским вводом и откликом браузера. TBT примерно показывает, насколько критична блокировка всех задач основного потока.

Для одной страницы вполне вероятно получить хорошие результаты FID, но при этом плохой показатель TBT. Немного сложнее, но все же возможно, добиться хорошего показателя TBT, но при этом снизить оценку по показателю FID *. Поэтому не думайте, что ваши показатели TBT и FID будут коррелировать. Масштабный анализ показал, что ρ Спирмена — коэффициент ранговой корреляции — составляет около 0,40. Это указывает на связь показателей, но не настолько сильную, насколько бы нам хотелось.

С точки зрения Lighthouse, текущий порог прохождения FID довольно низкий, а процент записи для FID (75-й процентиль) недостаточен для обнаружения проблем. 95-й процентиль — гораздо более сильный индикатор проблемных UX-взаимодействий для этого показателя. Мы рекомендуем вебмастерам, ориентированным на пользователя, сосредоточиться на 95-м процентиль всех задержек пользовательского ввода, а не только на первом вводе, чтобы своевременно выявлять и решать проблемы, которые возникают только в 5% случаев.

* Кроме того: изменение FID Chrome 91 для double-tap-to-zoom (двойной клик для увеличения объекта) фиксит множество случаев с «высоким FID/низким TBT» и может быть обнаружено в показателях данных наблюдений по страницам.

Большинство случаев с «высоким FID/низким TBT», вероятно, связано с неправильными метатегами viewport, которые Lighthouse отмечает в отчете. Настройка viewport для мобильных устройств, минимизация JS, блокирующего основной поток, поддержание низкого значения TBT — это основные задачи для улучшения FID в данных наблюдений.

Изменения во всех обновлениях оценок Lighthouse нужны, чтобы показать, как улучшилось UX-качество страниц. Также они помогают сфокусировать взгляд на ключевых приоритетах.

Тяжеловесный JS и длинные задачи — усугубляющаяся проблема. Наблюдаемый FID — слишком мягкая метрика, которая не решает проблему глобально. Lighthouse исторически оценивал свои показатели интерактивности на уровне 40–55% от оценки производительности, а поскольку интерактивность является ключом к UX, мы поддерживаем вес 40% (TBT и TTI вместе) и в Lighthouse 8.0.

Кривая оценки FCP была скорректирована для соответствия текущему фактическому «хорошему» порогу, в результате чего оценка стала более строгой. Кривую TBT сделали более жесткой, чтобы приблизиться к кривой идеальной оценки. У TBT была, и до сих пор остается, более плавная кривая, что диктуется нашей методологией. Но новая кривая более линейна, поэтому улучшение метрики положительно повлияет на оценку производительности. Новая кривая графика будет заметно изменяться, если постепенно улучшать производительность страницы. Вес FCP снизился с 15% до 10%, потому что он учитывается индексом скорости только частично.

TTI крайне полезен, поскольку это самый крупный анализируемый показатель, часто свыше 10 секунд.

И все же мы видим TBT как более надежный показатель оценки работоспособности основного потока и его влияния на интерактивность, к тому же он имеет небольшую изменчивость. TTI анализирует выполнение длительных задач, часто связанных с тяжеловесным JavaScript. Тем не менее мы продолжим снижать значимость TTI и, вероятно, удалим его в будущем обновлении Lighthouse.

Оценка производительности Lighthouse рассчитывается на основе значимости всего набора показателей производительности. Вы можете посмотреть текущие и предыдущие оценки и значимость параметров Lighthouse в калькуляторе оценок, а также узнать больше о специфике расчета оценок здесь.

Нам очень нравится интерактивная древовидная карта, сортировка аудитов по метрикам и новый аудит политики безопасности контента, который был разработан совместно с командой Google Web Security.

• Выводите метрики CLS, LCP и TBT в «зеленую зону». Важно оптимизировать данные метрики рендеринга страниц, чтобы получить наибольший эффект от улучшений на проекте во времена CWV.
• При оптимизации показателей CWV пользуйтесь сервисами Lighthouse в совокупности с браузерными данными Chrome UX Report.
• Оптимизируйте весь путь загрузки DOM так, чтобы элементы структуры js, css, не участвующие в рендеринге текущей страницы, не блокировали основной поток.
• Оптимизируйте JS и CSS, настраивайте асинхронную загрузку и медиаэлементы для улучшения качества загрузки страниц, улучшайте скрипты, используйте CSS-сплиты, удаляйте ненужный код, который не используется при загрузке.
• Используйте CDN для ускорения загрузки контента сайта.

Автор перевода Group Head команды RACURS Лилия Граевская.