webvitals react что это
Метрики производительности WEB Vitals
Меня зовут Денис, я работаю в компании Домклик. Как вы уже догадались из названия, в этой статье речь пойдет о таком важном элементе любого веб-сервиса, как производительность. Сразу хочу оговориться, я не буду рассказывать о том, почему это важно, в интернете уже и так очень много исследований и материалов, посвящённых этому вопросу. Я хотел бы затронуть практическую сторону этого вопроса и дать ответы на такие вопросы:
Какие существуют метрики производительности?
Как оценить качество вашего приложения?
Как поднять метрики?
Какие инструменты позволяют оценить показатели производительности, и др.
Прежде чем приступить к оптимизации вашего приложения, необходимо определиться с тем, что же такое хороший сайт? На сегодняшний день Google выделяет три основных критерия качества сайта: скорость его загрузки, отзывчивость и визуальная стабильность.
Ключевые критерии качества
В первую очередь содержимое должно грузиться быстро, причём вне зависимости от качества сети пользователя. Чем дольше пользователь ждёт загрузки, тем больше вероятность того, что он просто покинет наш сайт! Отзывчивость также очень важна: вы нажимаете на кнопку, а ничего не происходит! Нужно, чтобы содержимое не просто отображалось, но и было доступно для взаимодействия. И наконец, мы хотим, чтобы страница была стабильна и вела себя предсказуемо. Тут и приходит на помощь Core web vitals.
Core web vitals — это инициатива Google, представляющая из себя набор метрик и интервалов, позволяющих измерить те самые ключевые показатели Performance, о которых мы только что говорили.
Разумеется, существует множество других метрик, позволяющих сделать ваш сайт лучше быстрее и безопаснее. Но Core Web Vitals в первую очередь покрывает именно эти три ключевых показателя производительности.
Метрика LCP отражает скорость загрузки. Точнее, она показывает точку во время загрузки страницы, когда были загружены основные или самые большие элементы содержимого во view port. Это важное дополнение к метрике FCP (First Contentful Paint), которая фиксирует только самое начало загрузки. Иначе говоря, LCP позволяет измерить, как быстро пользователь сможет увидеть основное содержимое страницы.
Чтобы гарантировать положительный пользовательский опыт при загрузке страницы, сайт должен стремиться к тому, чтобы показатель LCP отрабатывал в течение первых 2,5 секунд с начала загрузки страницы.
Что влияет на LCP?
На рисунке ниже приведены четыре основных фактора, которые могут влиять на показатели загрузки страницы:
Вы можете увидеть все события загрузки страницы на вкладке Timings в Google Chrome DevTools, в том числе и метрику LCP.
Следующая метрика — FID (First Input Delay). Она отражает интерактивность приложения. FID измеряет время с момента, когда пользователь начал как-то взаимодействовать со страницей (нажимать на кнопки, заполнять формы и т.д.) до момента, когда браузер на самом деле был готов ответить на это взаимодействие.
Чтобы гарантировать хороший пользовательский опыт интерактивности, сайт должен иметь FCP менее 100 мс.
Что влияет на FID?
Большие размеры бандлов могут сильно повлиять на показатели интерактивности, так как браузер будет дольше исполнять их, что повлияет на время, необходимое браузеру для ответа на взаимодействия пользователя. На рисунке ниже приведены все факторы, влияющие на задержку ответа браузера.
Однако FID можно измерить только в полевых условиях с реальными пользователями. Для того, чтобы исследовать интерактивность во время локальной разработки, существует метрика TBT.
TBT показывает общее количество времени, когда основной поток заблокирован достаточно долго, чтобы реагировать на взаимодействия пользователя. Иначе говоря, TBT отражает время с FCP до Time to Interact.
Чтобы гарантировать положительный опыт взаимодействия пользователя, нужно стремиться к тому, чтобы каждая задача выполнялась не дольше 50 мс.
Вы можете увидеть метрику TBT в Chrome Dev Tools.
Наконец, третья метрика CLS (Cumulative Layout Shift) позволяет оценить визуальную стабильность страницы. CLS показывает, какое количество содержимого во viewport двигалось во время загрузки страницы. С её помощью можно убедиться, что взаимодействие пользователя с сайтом плавное и естественное.
Что влияет на CLS?
На рисунке ниже приведены основные факторы, влияющие на этот показатель.
Чтобы избежать CLS, необходимо резервировать место под динамически добавляемое содержимое.
Вы можете с помощью Chrome DevTools отладить элементы интерфейса, которые смещались во время загрузки страницы.
На вкладке Experience метрика CLS отмечена красными прямоугольниками. При клике на них на вкладке Summary вы сможете получить более полную информацию о том, что за элемент вызвал CLS, откуда и куда произошел сдвиг и т.д
Мы обсудили основные метрики хорошего сайта, а как их измерить? Core Web Vitals доступны практически во всех инструментах разработчиков. Но для начала стоит упомянуть, что существует два основных типа исследований, которые мы можем проводить над нашим приложением.
Лабораторные измерения критически важны для поиска проблем и багов, потому что они воспроизводимы и дают мгновенный результат, а также позволяют увидеть, какие необходимо внести правки до того, как пользователи посетят наш сайт.
Полевые измерения позволяют понять, какой опыт получают реальные пользователи. Включая условия, которые невозможно воспроизвести в лаборатории: состояния кеша, сети и т.д.
На рисунке ниже приведены основные инструменты, которые позволяют оценить качество сайта.
Обратите внимание, что метрику FID можно измерить только в полевых условиях. Чтобы измерить интерактивность, вам понадобятся реальные пользователи для кликов по странице. Но это не значит, что вы не можете использовать лабораторные инструменты для улучшения этого показателя. Как я уже говорил выше, TBT — это прокси-метрика, которая позволяет локально отладить и улучшить интерактивность вашего сайта.
Все инструменты, которые мы рассмотрим, можно включить в свой рабочий процесс. Начать можно с Page Speed Insides, так как он позволяет сравнить ваши полевые показатели с лабораторными. Google Search Console позволяет выявить группы страниц, требующих оптимизации. Затем с помощью Lighthouse и Chrome DevTools вы можете начать локально диагностировать и оптимизировать сайт. Далее вы можете предотвратить регрессию показателей производительности с помощью Lighthouse CI. И наконец, CrUX позволит создать кастомные дашборды для мониторинга. Для получения советов и инструкций можно использовать web.dev.
Как я уже сказал, Page Speed Inside позволяет получить как полевые данные из CrUX (чтобы убедиться, проходят ли 75 % показов сайта пороговые значения метрик; если да, то сайт классифицируется как оптимизированный, и это относится ко всем трём метрикам LCP, CLS, FID), так и лабораторные данные от Lighthouse.
С недавних пор в Lighthouse появились новые метрики, включая Core Web Vitals, а также новые проверки и отчеты.
Метрики Lighthouse можно сгруппировать по трём основным критериям качества сайта
FCP, SI, LCP представляют загрузку сайта;
TBT отражает интерактивность;
CLS отражает визуальную стабильность.
Новые метрики позволяют убедиться в производительности загрузки, интерактивности и стабильности макета. Собственно, эти метрики и их веса и формируют Performance Score!
LightHouse — очень интересный инструмент, в котором существует огромное количество разных отчётов и проверок, но в рамках Core Web Vitals нас в первую очередь интересуют следующие.
По загрузке страницы: отчеты о скорости ответа сервера; блокирующие отрисовку ресурсы; отчеты об оптимизации загрузки ресурсов.
По интерактивности: отчеты о загрузке main thread и оптимизации качества загружаемых ресурсов (дублирующиеся модули, неиспользуемый код и др.).
Ну и отчеты, позволяющие предотвратить сдвиги макета!
Как я уже сказал, Lighthouse довольно регулярно обновляется, и хочется показать пару новых фич, которые мы можем увидеть в ближайшее время.
У нас появится возможность анализировать prod-бандлы, смотреть, какие модули дублируются, какой процент кода в каждом конкретном бандле не использовался на этапе загрузки страницы.
Сам Chrome DevTools — тема отдельного разговора. Мы поговорим о нём сегодня именно в разрезе Core Web Vitals. И наибольший интерес у нас вызывает вкладка Performance. Также в этом инструменте можно увидеть задачи, которые ухудшают интерактивность (длятся более 50 мс), они помечаются красным треугольничком в правом верхнем углу. Кликнув на такую задачу, можно получить более подробную информацию о ней (трассировку стека и подзадачи).
Еще одна полезная вкладка в DevTools — Coverage. Всякий раз, как Lighthouse пишет «Удалите неиспользуемый код»
вы можете подробнее изучить, какая доля каждого бандла использовалась на этапе загрузки.
web.dev/measure — очень удобный способ получить отчёты наподобие Lighthouse, с той лишь разницей, что Measure отсортирует отчеты по приоритетам и к каждому из них даст ссылку на инструкции с более подробной информацией по каждой проблеме.
CrUX позволяет получить огромное количество данных по реальному пользовательскому опыту.
Также при разработке может помочь Web-vitals Chrome Extension, NPM-пакет web-vitals позволяет легко журналировать эти и другие метрики производительности.
Core Web Vitals: как Google решил оценивать сайты
Сегодня поговорим о важности пользовательского взаимодействия, ведь совсем скоро придется подготовить свои сайты к максимальному ускорению загрузки. Возможно, вы уже слышали про Core Web Vitals…
В прошлом году Google начал масштабный пересмотр факторов ранжирования в поисковике, чтобы улучшить качество поисковой выдачи. И в ноябре команда Google анонсировала Core Web Vitals — новые факторы оценки качества ресурсов, которые смогут влиять на индексацию и вступят в силу в мае 2021 года. Давайте разбираться.
Существуют сотни факторов ранжирования, однако Core Web Vitals будет анализировать ещё больше информации и иметь непосредственное влияние на дальнейшую индексацию. Нужно отметить, что скорость загрузки напрямую не влияет на индексацию, однако имеет значительное влияние на поведение пользователя, которое является важным сигналом для поисковых алгоритмов Google.
Чем Core Web Vitals отличается от прочих факторов ранжирования?
Положительная сторона Core Web Vitals — в прозрачности: это понятные, публично доступные критерии, которые можно отслеживать и улучшать с помощью специального набора инструментов. Кроме того, с момента анонсирования и до официального запуска есть много времени, чтобы уже начать работать над Core Web Vitals.
Андрей Липатцев, Web Partnerships Google
Core Web Vitals
Среди многих показателей ранжирования (оптимизации для мобильных устройств, безопасный просмотр, безопасность HTTPS и т.д.) Google выделил основные (core), жизненно важные для пользователя. Метрики, составляющие Core Web Vitals, со временем будут развиваться и дополняться.
Текущий набор показателей фокусируется на трех аспектах взаимодействия с пользователем: 
LCP (загрузка)
Для разработчиков всегда было непросто измерить, насколько быстро контент веб-страницы загружается и становится видимым для пользователей.
Старые метрики, такие как load или DOMContentLoaded, не подходят, так как они всегда соответствуют тому, что пользователь видит на экране. А более новые показатели производительности, такие как First Contentful Paint (FCP), отражают только самое начало процесса загрузки.
В ходе исследований обнаружилось, что более точный способ измерить загрузку основного содержимого страницы, – это посмотреть, когда был отрисован самый большой элемент.
Так появилась метрика Largest Contentful Paint (LCP), которая измеряет время рендеринга самого большого элемента на странице.
Что считается большим элементом?
Как это работает?
Веб-страница загружается поэтапно, и в результате самый большой элемент на ней может измениться.
Чтобы справиться с таким изменением, браузер отрисовывает первый кадр и отправляет PerformanceEntry с параметром large-contentful-paint, который идентифицирует самый большой элемент. Но затем, после рендеринга последующих кадров, браузер будет отправлять PerformanceEntry при каждом изменении самого большого элемента.
Важно отметить, что элемент может считаться самым большим содержимым только после того, как он будет отрисован и виден для пользователя.
Браузер перестает сообщать о новых записях, как только пользователь начнет взаимодействовать со страницей, поскольку взаимодействие может визуально изменить страницу (прокрутка, модальное окно и т.д.).
Рис.1. Изменение самого большого элемента по мере загрузки содержимого
Как определяется размер самого большого элемента?
Размер элемента определяется в области видимости пользователя: если элемент выходит за её пределы (обрезан или имеет overflow: hidden), то эти части не учитываются.
Если у изображения видимый и исходный размеры отличаются, то будет учитываться меньший из них. Например, если изображение сжали до меньшего размера, чем его исходный, то передается видимый размер, а если растянули — исходный.
Для текстовых элементов учитывается только размер их текстовых узлов.
Для всех элементов любые margin, padding или border не рассматриваются.
FID (интерактивность)
Метрика First Input Delay (FID) помогает измерить первое впечатление пользователя об интерактивности и быстродействии вашего сайта.
FID измеряет время с момента, когда пользователь впервые взаимодействует со страницей, до того, как браузер действительно может начать обработку событий в ответ на это взаимодействие.
Задержка ввода возникает из-за того, что основной поток браузера занят чем-то другим (синтаксическим анализом или выполнением большого бандла), поэтому он (пока) не может ответить пользователю.
FID можно измерить только в реальных условиях.
Почему рассматривается именно первый ввод?
CLS (визуальная стабильность)
Cumulative Layout Shift — важный, ориентированный на пользователя показатель для измерения стабильности верстки и элементов, не препятствующих взаимодействию с контентом.
Например, вы переходите на сайт, почитать статью. Пока сайт прогружался, на странице появилось ещё несколько элементов и положение скролла неожиданно изменилось. Неприятно.
Рис.2. Пример Cumulative Layout Shift
Первая ассоциация при виде этого примера — реклама. Думаю, что каждый хотя бы раз сталкивался с таким неожиданным появлением элемента.
Это может происходить из-за асинхронной загрузки ресурсов или динамического добавления DOM-элементов на странице. Причиной может быть изображение или видео с неизвестными размерами, сторонняя реклама или виджет, которые динамически изменяют размер.
CLS измеряет общую сумму всех показателей визуальной стабильности верстки в течение сессии страницы.
Показатель визуальной стабильности определяет Layout Instability API, который отправляет layout-shift каждый раз, когда существующий элемент меняет свое начальное положение между двумя кадрами.
Обратите внимание, что визуальная стабильность не учитывается, когда новый элемент добавляется в DOM или существующий элемент меняет размер.
Чтобы вычислить коэффициент визуальной стабильности, браузер смотрит на размер области просмотра и перемещение нестабильных элементов между двумя визуальными кадрами. Коэффициент вычисляется двумя показателями: коэффициентом воздействия и расстояния.
Рис.3. Коэффициент воздействия
На изображении выше есть элемент, который занимает половину области просмотра в одном кадре. Затем в следующем кадре элемент смещается вниз на 25% от высоты экрана. Красный пунктирный прямоугольник указывает на объединение видимой области элемента в обоих кадрах, которая в данном случае составляет 75% от экрана.
Рис.4. Доля расстояния
Доля расстояния — это наибольшее расстояние, на которое любой нестабильный элемент переместился в кадре (по горизонтали или вертикали), деленное на размер экрана.
В приведенном примере наибольшим размером экрана является высота, а нестабильный элемент перемещается на 25%.
Коэффициент визуальной стабильности = 0.75 * 0.25 = 0.1875
Как улучшить показатели Core Web Vitals?
Если ваше приложение не дотягивает до идеальных показателей, то нужно заняться вопросом повышения скорости. Итак, что можно сделать:
Библиотеки и инструменты
Самый простой способ измерить все Core Web Vitals — использовать js-библиотеку web-vitals, которая измеряет каждую метрику в соответствии с Инструментами Google.
Или можно использовать расширение Web Vitals для Chrome.
Не забывайте периодически следить за скоростью загрузки своего приложения. Быстрая реакция на любые негативные изменения позволит минимизировать потери и вовремя внести необходимые коррективы. Core Web Vitals влияет не только на индексацию, но и главным образом на конверсию, посещаемость и в результате на прибыль. К счастью, Google предупредил заранее о запуске новых факторов ранжирования, поэтому у вас есть еще время исправить все погрешности к запуску Core Web Vitals (май 2021).
Полезные ссылки и используемые материалы:
Core Web Vitals: полная инструкция 2021
Существуют три основных показателя Core Web Vitals:
— загрузка сайта (loading);
— визуальная стабильность (visual stability).
Измерить Web Vitals
Оптимизация показателей юзабилити — основа успеха любого сайта. Если вы владелец бизнеса, маркетолог или разработчик, Web Vitals поможет вам понять, удобен ли ваш сайт для посетителей. А если нет, то подскажет, что именно нужно улучшить.
Cмотрите наш прямой эфир про Core Web Vitals с Михаилом Шакиным 👇
Краткий обзор
Web Vitals — инициатива Google, разработанная для того, чтобы получать сигналы о качестве пользовательского опыта, который испытывают посетители вашего сайта.
Google создал множество сервисов для замера скорости загрузки сайтов. Некоторые разработчики уже стали экспертами в понимании этих отчетов, но многим всё еще сложно следить за метриками и осознавать, что они значат и насколько критичны прямо сейчас.
Владельцы сайтов не должны быть гуру в производительности, чтобы понимать, какое качество получают посетители их сайтов. Web Vitals создан для того, чтобы упростить понимание показателей, которые действительно важны и над которыми стоит работать.
Core Web Vitals
Core Web Vitals включает в себя показатели Web Vitals, измеряющие все страницы в интернете, и эти параметры будут отображаться во всех инструментах Google tools. Каждый параметр Core Web Vitals представляет собой отдельную часть пользовательского опыта, который измерен и отражает критические показатели, ориентированные на хорошее юзабилити посетителей сайта.
Метрики, входящие в ядро Web Vitals, будут изменяться со временем. В 2021 году фокус будет на трех аспектах:
Что такое Largest Contentful Paint (LCP) или Элемент «Отрисовка самого крупного контента»
Largest Contentful Paint (LCP) измеряет производительность загрузки. Для получения хорошего показателя удобства сайта, необходимо, чтобы LCP наступил в течение 2,5 секунд с момента, когда страница впервые начинает загрузку.
First Input Delay (FID), или задержка первого ввода. Измеряет время с момента действия пользователя и до реакции на это действие браузера в момент загрузки страницы, когда основной поток может быть занят другими процессами. Низкий показатель FID помогает гарантировать, что страница является пригодной для использования, то есть быстро реагирует на действия посетителя. Чтобы понимать в цифрах, то для хорошего юзабилити необходимо стремиться к значению FID меньше 100 миллисекунд.
Cumulative Layout Shift (CLS), или неожиданные смещения макета из PageSpeed Insights, — параметр, который измеряет визуальную стабильность сайта. Самая критичная ошибка в юзабилити — это когда что-то происходит без желания и контроля посетителя сайта. CLS — это про тот случай, когда вы открыли страницу и начали изучать контент, как вдруг выехал баннер сверху и сдвинул контент вниз. То, что произошло без предупреждения и без вашего желания на странице. В данном случае, контент должен «уезжать», чаще всего это сдвиг вниз. Рекламные баннеры, меню, шрифты — эти и другие элементы могут быть причиной CLS. Чтобы UX был хорошим, вам надо держать показатель CLS ниже 0.1.
Чем замерить Web Vitals: три сервиса для теста
В Гугл абсолютно уверены, что Core Web Vitals критичен для каждого посетителя сайта. Именно поэтому Web Vitals интегрирован в каждый сервис от Гугл.
Отчет Chrome User Experience Report собирает анонимизированные данные реальных посетителей с замером по каждому параметру Core Web Vitals. Эти данные дают быстрый доступ к показателям производительности сайта без необходимости делать ручные замеры. Эти же данные выводятся в PageSpeed Insights и в отчете Search Console Core.
Chrome User Experience Report: +LCP +FID +CLS
PageSpeed Insights: +LCP +FID +CLS
Search Console (Core Web Vitals report): +LCP +FID +CLS
Данные из отчета Chrome User Experience Report — это быстрый доступ к пониманию производительности сайтов. Но это не подробные данные, которые можно собрать, используя технологию real-user monitoring. Рекомендуем настроить живой мониторинг. Обратитесь к нам за консультацией.
Как измерить Core Web Vitals, используя JavaScript
Каждый параметр Core Web Vitals может быть измерен JavaScript’ом, используя стандартные web APIs.
Самый простой метод измерить всё из Core Web Vitals — использовать JavaScript библиотеку «web-vitals». Маленькая и готовая библиотека, которая аккуратно сделает все замеры и передаст их, куда надо.
С библиотекой web-vitals замерить каждую метрику так же просто, как вызвать функцию. Для полной инструкции использования смотрите документацию API:
const body = JSON.stringify(metric);
// Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
(navigator.sendBeacon && navigator.sendBeacon(‘/analytics’, body)) ||
Проверить, как это работает в реальном времени, можно при помощи расширения для браузера. В этом случае не придется писать ни одной строки кода. Это расширение использует библиотеку «web-vitals», измеряя каждый параметр в реальном времени, и показывает данные в браузере, как они есть.
Это расширение CWV поможет понять производительность вашего сайта и изучить сайты ваших конкурентов.
web-vitals: +LCP +FID +CLS
Web Vitals Extension: +LCP +FID +CLS
Для тех, кто предпочитает измерять каждую метрику через API, есть отдельные гайды на все случаи жизни:
Синтетический замер Core Web Vitals
Считается, что Core Web Vitals работает только для живых замеров. Но его также можно замерять и в лабораторных условиях. Это называется синтетический замер, когда для получения метрик мы берем настроенный определенным образом сервер, с браузером Chrome. При этом скорость соединения тоже ограничена для эмуляции мобильного посетителя.
Синтетические замеры помогают увидеть узкие места еще до того, как их получат посетители вашего сайта, а вы увидите их спустя время в отчетах Search Console или PageSpeed Insights.
Сервисы для синтетического замера Core Web Vitals:
Такие сервисы, как Lighthouse, которые загружают страницу в эмулированном окружении без реального посетителя, измеряют FID, имитируя действия пользователя, что может вызывать некорректные значения показателя. Поэтому синтетическая метрика Total Blocking Time (TBT) — это отличная замена параметру FID. Ускорение сайта, при котором улучшается параметр TBT в лабораторных замерах, должен исправить к лучшему FID в живых замерах. Про то, как улучшать каждый из параметров, мы напишем отдельные статьи.
Синтетические замеры — важнейшая часть при оценке производительности сайта. Но это не замена живых данных.
Скорость загрузки сайта зависит от устройства пользователя, скорости интернета, фоновой активности на устройстве и от того, как люди взаимодействуют со страницей. На любую метрику из Core Web Vitals может влиять то, как происходит интерактивность на странице. Только живые замеры могут точно составить цельную картину.
Рекомендации для исправления ваших показателей Core Web Vitals
После измерений метрик Core Web Vitals и определения узких мест для исправлений — самое время для оптимизации скорости сайта.
Скачайте нашу инструкцию по улучшению показателей Core Web Vitals.
Другие параметры Core Web Vitals
Основные метрики Core Web Vitals критичны для оценки и внедрения отличного юзабилити для посетителей. Но есть и другие важные метрики.
Эти другие показатели Web Vitals часто служат для определения дополнительных показателей, чтобы дополнить картину диагностики или найти специфичную загвоздку в производительности сайта.
Например, показатели Time to First Byte (TTFB), или время ответа сервера, и First Contentful Paint (FCP), или отрисовка первого контента, — два важнейших показателя для скоростной загрузки. Оба показателя очень помогают в диагностике проблем с LCP.
То же самое с метриками Total Blocking Time (TBT) и Time to Interactive, TTI — время до полной интерактивности. Это синтетические метрики, которые важно измерять, чтобы поймать узкие места в наступлении интерактивности, которые будут влиять на FID. TBT и TTI не входят в Core Web Vitals, потому что они не отражают опыт, полученный пользователями в реальном времени.
Развитие Core Web Vitals в 2021 году
Web Vitals и Core Web Vitals — это лучший инструмент для разработчика, чтобы измерять показатель впечатлений посетителей от вашего сайта. Но эти сигналы не идеальны, и будущие изменения не за горами.
Показатели Web Vitals актуальны для каждого сайта в интернете и представлены в каждом инструменте от Гугл. Любое изменение в этих метриках затронет очень большой массив данных. В то же время, разработчики должны понимать, что необходимо держать показатели Web Vitals в определенной стабильности при каждом обновлении на вашем сайте.