Core Web Vitals — новый критерий ранжирования Google и как теперь контролировать веб-производительность

Google объявил, что с июня 2021 года они начнут рассматривать “Page Experience” как часть ранжирования в поиске, измеряемого набором показателей, называемых Core Web Vitals.

Сигналы, которые отражают удобство страницы

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

Однако, в данной статье мы заострим внимание именно на Core Web Vitals.

Данный критерий является довольно сложным, и хотя в данный момент для нас доступно множество инструментов, раскрывающих Core Web Vitals, существует немало важных концепций и тонкостей, которые необходимо понять. Даже такие инструменты Google, как PageSpeed ​​Insights и отчет Core Web Vitals в Google Search Console дают запутанную информацию. Давайте разбираться.

Что такое “Core Web Vitals”?

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

3 главные метрики Core Web Vitals
  1. Largest Contentful Paint — показатель загрузки. Для обеспечения удобства работы пользователей, LCP должен сработать в течение первых 2,5 секунд после того, как страница начала загружаться.
  2. First Input Delay (FID) — показатель интерактивности. Для обеспечения удобства работы пользователей, показатель FID должен быть меньше или равен 0.1 секунды.
  3. Cumulative Layout Shift (CLS) — показатель визуальной стабильности. Для обеспечения удобства работы пользователей, показатель CLS должен быть меньше или равен 0.1.

В целом, результаты по 3-м показателям должны быть в пределах зеленых зон. За пределами зеленой зоны значения показателей Core Web Vital могут привести к разному ранжированию страницы. Рассмотрим каждый из критериев подробнее.

1. LARGEST CONTENTFUL PAINT (LCP)

Этот показатель, вероятно, самый простой для понимания. Он измеряет, как быстро пользователь получает самый тяжелый элемент контента, отрисованный на странице. 

Зачастую этими элементами являются:

  • тег <video>,
  • тег <img>, 
  • тег <image> внутри <svg>, 
  • элемент с CSS-свойством “background-image” и атрибутом “url”, 
  • атрибут “poster“ в теге <video>,
  • блокирующий поток элемент, содержащий текст. 

Тот факт, что это самый крупный элемент на странице, свидетельствует о том, что в то же время это самый важный элемент. LCP является относительно новым критерием. Ранее мы в первую очередь заостряли свое внимание на одноименном First Contentful Paint (FCP), но в данный момент LCP рассматривается как более эффективный показатель отрисовки контента, который пользователь захочет увидеть в первую очередь.

LCP измеряет производительность загрузки и является прокси для всех старых метрик производительности, которые мы ранее использовали (например, время до получения первого байта от сервера (TTFB), время загрузки DOM, время начала рендеринга, индекс скорости). Он охватывает далеко не всю информацию, которая содержится в этих показателях по отдельности, но при этом представляет собой единую, более понятную метрику, которая дает хорошее представление о загрузке страницы.

2. FIRST INPUT DELAY (FID)

Этот показатель измеряет время, через которое пользователь может взаимодействовать со страницей. Например: щелчком по ссылке или кнопке и моментом, когда браузер начнет обрабатывать этот щелчок. Он нужен для измерения интерактивности страницы. 

Представьте: пользователь видит весь контент загруженным, но при этом страница длительное время не отвечает на его действия. Пользователь остается разочарованным и покидает сайт(скорее всего навсегда), а вы упускаете потенциального клиента.

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

Основной причиной таких проблем обычно являются:

  • блокирующие отрисовку страницы CSS-стили и Javascript-скрипты, 
  • длительные задачи в основной потоке(зачастую Javascript-скрипты).

При изучении данного пункта необходимо также обратить внимание на критерии “Total Blocking Time” (TBT) и “Time to Interactive” (TTI), которые тесно связаны с FID.

3. CUMULATIVE LAYOUT SHIFT (CLS)

Очень интересный показатель, который предназначен для измерения визуальной стабильности страницы и отслеживает —  насколько контент страницы сдвигается (“прыгает”), когда новые элементы отрисовываются на своих местах страницы. Каждый из нас хоть раз, но встречался с ситуацией, когда при прочтении статьи текст сдвигался по мере загрузки изображений, рекламы и другого контента.

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

Причинами сдвигов макета обычно являются: 

  • отсутствие размеров изображений, видео и элементов iframe,
  • веб-шрифты,
  • инициализация плагина или библиотеки,
  • вставка рекламных объявлений, cookie-уведомления, подписки на рассылку новостей,
  • динамически вставляемые после сетевого запроса DOM элементы. 

Синтетические инструменты vs. реальные показатели

Один из ключевых моментов для понимания Core Web Vitals заключается в том, что они основаны на реальных показателях пользователей (RUM). Google использует анонимные данные пользователей Chrome и делает их доступными в отчете о пользовательском опыте Chrome (CrUX). Эти данные они используют для измерения трех метрик, рассмотренных выше и на их основе формирует ранжирование. Данные CrUX доступны в ряде инструментов, в том числе в Google Search Console вашего сайта.

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

Таким образом, если вы запускаете Lighthouse на мощном компьютере и получаете отличный результат по всем критериям, рассмотренным выше — это с большой долей вероятности не  отразит то, что пользователи испытывают в реальном мире и что Google будет использовать для измерения опыта пользователей вашего сайта.

LCP сильно зависит от состояния сети и вычислительной мощности используемых устройств и высока вероятность, что пользователи вашего сайта будут использовать устройства с меньшей мощностью, чем вы думаете. Однако, стоит заметить, что часто реальный показатель загрузки сайта на мобильном устройстве лучше, чем его тестирование с помощью того же Lighthouse. При этом, в данный момент в Github репозитории Lighthouse ведется обсуждение по изменению(ужесточению) мобильных настроек.

Точно так же FID часто зависит от скорости работы процессора и того, как устройство обрабатывает весь контент, который мы ему отправляем — будь то изображения для обработки, элементы для макета на странице или, конечно же, JavaScript.

Теоретически, CLS легче измерить с помощью инструментов тестирования, поскольку он менее подвержен изменениям в сети и не так зависит от оборудовании. Однако, важно отметить несколько важных соображений, которые изначально могут быть неочевидными:

  • CLS измеряется на протяжении всего времени использования страницы, в отличии от синтетических инструментов Google, о которых мы поговорим позже. Это вызывает большую путаницу, когда смоделированные данные загрузки страницы имеют очень низкий CLS, но оценка CLS намного выше из-за CLS, вызванного прокруткой или другими изменениями после начальной загрузки, которую обычно измеряют инструменты тестирования.
  • CLS может зависеть от размера окна браузера — обычно такие инструменты, как PageSpeed ​​Insights, измеряют производительность для мобильных и десктопных устройств. Однако, мобильные устройства имеют разный размер экрана, а десктопные часто намного больших размеров, чем установлено в инструментах тестирования.
  • Пользователи видят на веб-страницах разные вещи. Cookie-баннеры, настраиваемый контент типа рекламных акций и блокировщиков рекламы. Все они влияют на то, какой контент отображается, и на то, какой CLS пользователи могут испытать на своих устройствах.

CLS все еще находится в процессе развития, и команда Chrome занимается исправлением «невидимых» сдвигов и прочих критериев, которые не должны учитываться в CLS. Это означает, что вы можете видеть разные значения CLS в зависимости от того, какая версия Chrome запущена.

Как ранее формировались показатели веб-производительности

Еще одна путаница заключается в том, что эти метрики являются новыми и отличаются от тех, которые мы традиционно использовали в прошлом для измерения веб-производительности. 

Самым популярным бесплатным инструментом онлайн-аудита является PageSpeed ​​Insights. Просто введите URL-адрес, по которому вы хотите провести аудит, и нажмите «Анализировать», и через несколько секунд вам будут представлены две вкладки (одна для мобильных устройств и одна для десктопных), которые содержат большой объем информации:

Показатели производительности сайта PageSpeed Insights

Наверху находится рейтинг производительности Lighthouse.

Общая оценка производительности сайта PageSpeed Insights

Lighthouse хорошо известен в сообществах веб-производительности и часто упоминается как ключевой показатель, к которому нужно стремиться и который суммирует показатели многих критериев в понятный всем формат — числовое значение из 100. Частично, итоговый результат совпадает с показателями Core Web Vitals, но в отличии от Core Web Vitals, представляет более широкий набор показателей.

В настоящий момент оценку производительности Lighthouse составляют шесть показателей, включая Core Web Vitals, а также некоторые другие:

  • First Contentful Paint (FCP)
  • Speed Index (SI)
  • Largest Contentful Paint (LCP)
  • Time to Interactive (TTI)
  • Total Blocking Time (TBT)
  • Cumulative Layout Shift (CLS)

Чтобы усложнить задачу, каждый из этих шести показателей оценивается по-разному, и CLS, несмотря на то, что является одним из основных, в настоящее время составляет всего 5% от оценки производительности Lighthouse. Все это означает, что вы можете получить очень высокую оценку производительности Lighthouse, окрашенную в зеленый цвет, и думать, что ваш веб-сайт в порядке, но при всем при этом не пройти порог Core Web Vitals. Поэтому, возможно, сейчас вам потребуется направить свои усилия именно на 3 основных показателя.

Перейдем к блоку “Данные наблюдений” и получим еще одну путаницу:

Данные наблюдений сайта PageSpeed Insights

First Contentful Paint отображается в данном блоке вместе с другими тремя Core Web Vitals, несмотря на то, что не является их частью. FCP всегда являлся одним из ключевых критериев и, вероятно, таким и останется. К данному разделу мы еще вернемся.

После идет блок “Имитация загрузки страницы”, где мы видим уже шесть показателей, которые составляют оценку производительности. Если вы нажмете на переключатель в правом верхнем углу данного блока, то получите немного больше информации об этих показателях:

Имитация загрузки страницы PageSpeed Insights

Как видите, сюда включены LCP и CLS, и, поскольку они являются частью Core Web Vitals, имеют синюю этикетку, выделяясь как особо важные. PageSpeed ​​Insights также предоставляет полезную ссылку на калькулятор, чтобы увидеть влияние этих оценок на общий балл и позволяет настраивать их, чтобы увидеть, как улучшение каждого показателя повлияет на результат. 

Lighthouse также выполняет около 50 других проверок дополнительных возможностей и диагностики. По словам Google, они не влияют ни на оценку, ни на Core Web Vitals, но могут использоваться веб-разработчиками для повышения производительности сайта. От себя хотел бы добавить, что часто исправление данных рекомендаций на общую оценку все же влияют.

Они отображаются в PageSpeed ​​Insights ниже:

Дополнительные рекомендации PageSpeed Insights

Несмотря на то, что Google трактует их как предложениях по повышению производительности, а не как конкретные проблемы, которые необходимо решить, я бы рекомендовал обращать на них внимание.

Диагностика покажет вам элемент LCP и сдвиги, которые повлияли на вашу оценку CLS, что является очень полезной информацией при оптимизации для Core Web Vitals.

Подводя небольшой итог, отмечу, что хотя в прошлом сторонники веб-производительности могли в значительной степени сосредоточиться на оценках и аудитах Lighthouse, в ближайшее время внимание будет направлено на три основные показателя Core Web Vital. 

Просмотр Core Web Vitals вашего сайта

Самый простой способ быстро взглянуть на Core Web Vitals для отдельного URL-адреса — ввести URL-адрес в PageSpeed ​​Insights, как описывалось ранее. Однако, чтобы увидеть, как Google видит Core Web Vitals для всего вашего сайта, необходимо получить доступ к Google Search Console. Для этого вам понадобится учетная запись Google, а затем подтвердить свое право собственности на сайт.

Отчет Core Web Vitals в Google Search Console дает вам сводную информацию о том, насколько ваш сайт соответствовал критериям Core Web Vitals за последние 90 дней:

Отчет Core Web Vitals в GSC

В идеале, для того, чтобы пройти критерии Core Web Vitals, все ваши страницы должны быть отмечены зеленым цветом. Несмотря на то, что оранжевая линия является хорошим индикатором того, что вы близки к удаче, на самом деле, для получения всех преимуществ учитывается только зеленая. 

Изначально Google применяет рейтинг Core Web Vitals только к мобильным устройствам, но, на самом деле, реализация подобных алгоритмов для десктопных устройств — вопрос времени, поэтому не игнорируйте их оптимизацию.

Щелкнув на один из отчетов, вы получите более подробную информацию о том, какие из основных показателей не проходят тест, а затем и рассмотреть проблемы конкретных URL. Нажмите на URL-адрес, чтобы запустить PageSpeed ​​Insights для быстрого аудита производительности определенного URL-адреса (включая отображение данных о Core Web Vitals для этой страницы). После, устраняете выявленные проблемы, повторно запускаете PageSpeed ​​Insights для того, чтобы убедиться, что синтетические показатели верны, а затем переходите к следующей странице.

Однако, после кропотливой работы, вы, возможно, будете разочарованы тем, что отчет Core Web Vitals не изменился, а PageSpeed ​​Insights упорно продолжает показывать URL и сайт в целом как неисправные. Почему?

Отчет о пользовательском опыте Chrome (CrUX)

Причина, по которой Web Vitals обновляется довольно медленно заключается в том, что данные формируются на основе последних 21-28 дней пользовательского опыта Chrome (CrUX) — именно столько времени достаточно для устранения разного рода отклонений и отображения более точной производительности вашего сайта.

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

Дополнительная информация о данных CrUX

CrUX — это инструмент Chrome. Пользователи iOS устройств и других браузеров (десктопная версия Safari, Firefox, Opera, Edge и т.д.) никаким образом не влияют на данные CrUX, соответственно и на показатели Core Web Vitals вашего сайта.

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

Используемая версия Chrome также будет иметь влияние на показатели, поскольку все критерии все еще находятся в стадии развития и изменений(в частности, CLS).

CrUX включает в себя все страницы, в том числе те, которые обычно не отображаются в поиске Google(например с мета-тегом <meta name=»robots» content=»noindex»>). Теперь такие страницы, скорее всего, не будут включены в результаты поиска Google, соответственно не будут влиять на ранжирование, несмотря на то, что в CrUX вы все еще будете их наблюдать. 

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

Теперь мы знаем, каким образом собираются и анализируются данные, но актуальным становится вопрос — как ускорить обновление наших изменений во время разработки. Ждать 21-28 дней, чтобы увидеть влияние данных CrUX — только для того, чтобы понять, что ваших исправлений было недостаточно?

Получение мгновенных результатов об изменениях в CRuX

На рынке существует несколько отличных коммерческих продуктов RUM, которые дают возможность запрашивать данные гораздо глубже и с гораздо большей частотой, чем CrUX. 

Однако, в данной статье мы рассмотрим 2 других инструмента — расширение для браузера Chrome Web Vitals Chrome Extension и Javascript-библиотека для фронтенд-разработчиков web-vitals.

Расширение Web Vitals Chrome Extension

Это довольно простой для понимания инструмент. Давайте рассмотрим процесс его установки, а затем получим результаты одного из примеров.

  1. Переходим на страницу расширения в веб-магазине Google.
  2. Устанавливаем расширение, нажав на кнопку “Установить” в правом верхнем углу.
Расширение Web Vitals Chrome Extension

Спустя пару секунд расширение будет установлено в вашем браузере Chrome.

Отображается расширение в виде квадрата,

Отображение Web Vitals Chrome Extension

который может быть 3х цветов:

  1. Зеленый — хорошие показатели Core Web Vitals.
  2. Красный — плохие показатели Core Web Vitals.
  3. Серый — показатели недоступны.

Нажав на иконку расширения, мы можем получить более точные данные по конкретным метрикам:

Данные по метрикам в Web Vitals Chrome Extension

Javascript-библиотека web-vitals

Это минималистичная (1кб) библиотека, которая создана для фронтенд-мониторинга. По моему мнению, в данный момент этот инструмент является самым эффективным, потому что позволяет отследить показатели за короткие промежутки времени с очень высокой точностью.

Полное описание по установке и использованию, а также API данной библиотеки можно посмотреть тут.

Я же опишу ее главные функции. Итак, приступим:

Установка и загрузка библиотеки с помощью npm

Существует две разные версии библиотеки web-vitals («стандартная» версия и версия «base + polyfill»), и то, как вы загружаете библиотеку, зависит от того, какую версию вы хотите использовать.

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

1. “Стандартная” версия

Для загрузки импортируйте модули из пакета web-vitals в код своего приложения:

2. «Базовая версия с полифиллом»

Загрузка версии «base + polyfill» — это двухэтапный процесс:

Во-первых, в коде вашего приложения импортируйте «базовую» сборку, вместо «стандартной». Для этого достаточно изменить путь на ‘web-vitals/base’:

Затем вставьте код из dist/polyfill.js, который находится в папке установленной библиотеки в <head> своих страниц. Этот шаг важен, поскольку «базовая» сборка не сработает, если код полифилла не будет добавлен.

Установка и загрузка библиотеки с помощью CDN

Важно отметить, что авторы рекомендуют устанавливать библиотеку через npm и интегрировать сборку в ваш код. Однако, если вы не используете npm, подключение web-vitals с помощью CDN все еще допускается.

Примеры, которые будут показаны ниже, отображают загрузку web-vitals вне зависимости, нацелены ли вы на браузеры, построенные на кодовой базе Chromium(используя “стандартную версию”) или не на ней (используя «Базовую версию с полифиллом»):

Загрузка “стандартной версии” (используя <script type=”module”></script>):

Загрузка “стандартной версии” (используя тег <script></script>):

Загрузка “базовой версии с полифиллом” (используя тег <script></script>):

Использование

Каждая метрика Web Vitals представлена ​​в виде отдельной функции, которая принимает коллбэк “onReport”, который будет вызываться каждый раз, когда значение метрики доступно и готово к отправке.

В следующем примере измеряется каждая из метрик Core Web Vitals и как только значение для отчета получено — выводится в консоль.

(Примеры ниже используют «стандартную» сборку, но они также будут работать с версией полифилла).

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

Кроме того, в некоторых случаях данный коллбэк может никогда не вызваться:

  • FID не будет получен, если пользователь не будет взаимодействовать со страницей.
  • FCP, FID и LCP не будут получены, если страница загружалась в фоновом режиме.

В некоторых случаях данный коллбэк может быть вызван более одного раза:

Получение значения при каждом изменении

В большинстве случаев, коллбэк “onReport” вам понадобится лишь тогда, когда значение метрики будет доступно. Однако, у вас есть возможность получать значение при каждом изменении(например, при каждом сдвиге макета), установив необязательный второй аргумент «reportAllChanges» в значение true.

Данный прием может быть полезен для отладки, но в большинстве случаев «reportAllChanges» вам не понадобится.

Получение только дельты изменений

Некоторые инструменты аналитики позволяют обновлять значение метрики даже после того, как вы уже отправили ее сервер (перезаписывая ранее отправленное значение с тем же id).

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

В следующем примере показано, как использовать свойства id и delta:

Отправка результатов в конечную точку аналитики

В следующем примере измеряется каждая из метрик Core Web Vitals и отправляется по гипотетическому адресу аналитики, как только каждая из них будет готова к отправке.

Функция sendToAnalytics() использует метод navigator.sendBeacon() (если он доступен), в противном случае возвращается к fetch() API.

Отправка результатов в Google Analytics

В том случае, если вы установите уникальное значение параметра (в данном случае id метрики, как будет показано в примерах ниже) для каждого экземпляра метрики, которую вы отправляете в Google Analytics, вы можете создать отчет, используя Google Analytics Reporting API и любую библиотеку визуализации данных на ваш выбор.

Например, отчет Web Vitals Report  — бесплатный инструмент с открытым исходным кодом, который вы можете использовать для создания визуализаций данных Web Vitals, которые вы отправили в Google Analytics.

Web Vitals Report

Чтобы использовать Web Vitals Report (или создавать свои собственные пользовательские отчеты с помощью API), вам необходимо отправить свои данные в Google Analytics, следуя одному из примеров, описанных ниже:

Использование analytics.js

Использование gtag.js (Universal Analytics)

Использование gtag.js (Google Analytics 4)

Google Analytics 4 предоставляет новую модель событий, позволяющую настраивать параметры вместо фиксированных категорий, действий и меток. Он также поддерживает нецелочисленные значения, что упрощает измерение показателей Web Vitals по сравнению с предыдущими версиями.

Отправка результатов в Google Tag Manager

Рекомендуемый способ измерения показателей Web Vitals с помощью Google Tag Manager — использование настраиваемого тега шаблона Core Web Vitals.

Полную инструкцию по установке и использованию читайте тут.

Вывод

Google имеет большую власть в области веба. Компания не всегда действовала из лучших побуждений, но Core Web Vitals преследует благородную цель. Теперь у нас есть инструменты, которые измеряют показатели производительности страницы на основе реального опыта. Они помогут разработчикам сконцентрироваться на улучшениях, которые принесут наибольшую пользу пользователям клиентов.

Core Web Vitals — это набор ключевых показателей, предназначенных для представления пользовательского опыта просмотра веб-страниц и сейчас нам надо заострить свое внимание

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

Javascript-библиотека “web-vitals” в свою очередь помогает разработчикам существенно повысить скорость и эффективность контроля веб-производительности.  

Надеюсь, эта статья помогла вам лучше понять 3 важных критерия Core Web Vitals. Ну а в следующей я расскажу, что со своей стороны мы делаем, чтобы достичь наилучших показателей Core Web Vitals.