{"id":11244,"title":"\u0420\u0430\u0437\u0431\u0438\u0440\u0430\u0435\u043c\u0441\u044f, \u043b\u043e\u043f\u043d\u0435\u0442 \u043b\u0438 \u0440\u044b\u043d\u043e\u043a \u0418\u0422 \r\n ","url":"\/redirect?component=advertising&id=11244&url=https:\/\/vc.ru\/promo\/353949-razbiraemsya-lopnet-li-rynok-it&placeBit=1&hash=d208029863fe4571a57bd41458f0ed509048b262392aaffae456a4ea928923a5","isPaidAndBannersEnabled":false}
SEO
Racurs Agency

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

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

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

Lighthouse v8.0. Часто задаваемые вопросы о производительности

Об изменениях оценки производительности в версии 8.0. Что нового, какие отличия?

Напомним о математических расчетах, лежащих в основе показателей 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, а также с повышением значимости обеих метрик в совокупной оценке производительности.

Точные данные по изменениям значимости коэффициентов

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

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

Почему увеличился вес 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.

Как соотнести оценку производительности 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 и Lighthouse имеют общие черты, но все же они разные. Как можно рационализировать работу с этими данными?

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

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

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

Какие метрики дополнительно освещают синтетические инструменты?

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

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

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

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

Как мне оптимизировать CLS, учитывая, что он был обновлен?

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

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

Почему показатели TBT и FID не совпадают, если TBT является косвенной метрикой для FID?

Общие черты между 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?

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

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

Как рассчитывается оценка производительности Lighthouse? На чем это основано?

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

Какое самое интересное обновление в Lighthouse v8?

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

Пример Lighthouse Treemap

Рекомендации по оптимизации рендеринга страниц от digital-агентства “RACURS”

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

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

0
3 комментария
Популярные
По порядку
В А

Блин, только я сделал всё в зелёную зону вместе с адсенсом и на тебе...

Ответить
0
Развернуть ветку
В А

Чет сеарч консоль не видит ухудшений, а наоборот

Ответить
0
Развернуть ветку
Lily Graevskaya

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

Ответить
1
Развернуть ветку
Читать все 3 комментария
От техподдержки через переводчик до главного канала продаж

Как изменился «AliExpress Россия»: рассказывают «старички» маркетплейса.

Биржевой стакан в мобильном приложении БКС Мир инвестиций
Скоро выйдут: сериалы про WeWork, Theranos, Uber и Spotify Статьи редакции

Три из них можно будет посмотреть уже весной 2022 года.

Просмотр сетки ордеров
Как и почему я переехал в Иннополис: плюсы и минусы

В прошлом году я стал операционным директором офиса компании Promwad в Иннополисе и оказался единственным сотрудником, который исходно жил в этом городе. Остальные приезжали из других городов России. Поэтому мне часто приходилось делиться с новичками своим опытом трех лет жизни и работы в Иннополисе. В итоге я решил собрать свои заметки про плюсы…

В Бельгии начнут выдавать паспорта с изображениями из комиксов

Уже с 7 февраля все граждане смогут получить новый вариант паспорта в оформлении местных комиксов.

Хакеры взломали DeFi-платформу Qubit Finance и украли криптовалюту на $80 млн Статьи редакции

Команда проекта предложила вернуть деньги за награду — но им пока не ответили.

Доходы Yota от роуминга выросли в 1,6 раз

Ковидные ограничения стали испытанием для мобильных операторов, которые недополучили доход от роуминга в 2020 году. В Yota в 2020 году выручка от роуминга сократилась в два раза по сравнению с 2019 годом.

null