Измерение и оптимизация Google Core Web Vitals: техническое руководство по SEO

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

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

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

Взгляд на эволюцию веб-производительности

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

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

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

Стремление Google к более быстрому Интернету продолжается. PageSpeed ​​Insights (PSI) по-прежнему доступен на сайте web.dev и является лучшим инструментом для оценки загрузки отдельных страниц.

Хотя многие считают, что рейтинги PSI являются излишне карательными, они по-прежнему наиболее близки к тому, как Google может взвешивать и ранжировать сайты с помощью сигналов скорости страницы.

Чтобы пройти последнюю версию теста скорости страницы Google, вам необходимо пройти тест Core Web Vitals Assessment.

Понимание основных веб-жизненных показателей

Базовые веб-показатели — это набор показателей, интегрированных в более широкие поисковые сигналы взаимодействия с страницами, представленные в 2021 году. Каждая метрика «представляет собой отдельный аспект пользовательского опыта, поддается измерению в полевых условиях и отражает реальный опыт критически важного пользователя». ориентированный на результат», — утверждает Google.

Текущий набор показателей Core Web Vitals включает в себя:

• Первая содержательная краска
• Задержка первого ввода (заменяется на «Взаимодействие со следующей отрисовкой»)
• Взаимодействие со следующей отрисовкой
• Время до первого байта
• Самая большая содержательная краска
• Совокупный сдвиг макета

Web.dev объясняет, как работает каждая метрика, следующим образом.

Первая содержательная краска (FCP)

«Метрика First Contentful Paint (FCP) измеряет время с момента начала загрузки страницы до момента отображения какой-либо части ее содержимого на экране. Для этой метрики «контент» относится к тексту, изображениям (включая фоновые изображения), элементам <svg> или небелым элементам <canvas> ».

Что это означает для технических SEO-специалистов

FCP довольно легко понять. Когда веб-страница загружается, некоторые элементы появляются (или «рисуются») раньше других. В этом контексте «рисование» означает рендеринг на экране.

Как только какая-либо часть страницы будет отображена (скажем, основная панель навигации загружается раньше других элементов), FCP будет зарегистрирован в этот момент.

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

Первая входная задержка (FID)

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

Что это означает для технических SEO-специалистов

FID — это набор показателей скорости реагирования на взаимодействие с пользователем, который будет заменен на «Взаимодействие с следующей отрисовкой» (INP) в марте 2024 года.

Если пользователь взаимодействует с элементом на странице (например, ссылкой, сортировкой таблицы или применением фасетной навигации), сколько времени потребуется сайту, чтобы начать обработку этого запроса?

Взаимодействие со следующей отрисовкой (INP)

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

Что это означает для технических SEO-специалистов

Как уже упоминалось, INP заменит FID в качестве Core Web Vital в марте 2024 года.

INP учитывает более глубокую информацию (очевидно, распространяющуюся на клавиатуру) и, вероятно, является более подробной и сложной.

Время до первого байта (TTFB)

«TTFB — это метрика, измеряющая время между запросом ресурса и моментом, когда начинает поступать первый байт ответа».

Что это означает для технических SEO-специалистов

Когда запрашивается «ресурс» (т. е. встроенное изображение, модуль JavaScript, таблица стилей CSS и т. д.), сколько времени потребуется сайту, чтобы начать предоставлять этот ресурс?

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

Самая большая содержательная краска (LCP)

«Метрика Largest Contentful Paint (LCP) сообщает о времени рендеринга самого большого изображения или текстового блока, видимого в области просмотра, относительно момента, когда страница впервые начала загружаться».

Что это означает для технических SEO-специалистов

LCP — одна из самых важных метрик, но ее сложнее всего удовлетворить.

После загрузки наибольшего фрагмента визуального носителя (т. е. текста или изображения) LCP регистрируется.

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

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

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

Совокупное изменение макета (CLS)

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

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

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

Самый большой всплеск — это окно сеанса с максимальным совокупным баллом всех сдвигов макета в этом окне».

Что это означает для технических SEO-специалистов

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

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

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

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

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

Если вы, как и я, немного страдаете ОКР, такие переживания просто приводят в ярость (даже несмотря на то, что они стоят всего несколько секунд времени).

Из-за того, что владельцы сайтов пытались «играть» в рейтингах скорости страниц, откладывая все ресурсы, Google нуждался в контрметрике, которая компенсировала бы весь прирост скорости страницы дефицитом пользовательского опыта.

Введите совокупное смещение макета (CLS). Это один из хитрых клиентов, который хочет испортить вам день, если вы попытаетесь широко применить повышение скорости страницы, не думая о своих пользователях.

CLS в основном анализирует загрузку вашей страницы на предмет сбоев и отложенных правил CSS.

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

Оценка ваших основных веб-показателей для улучшения результатов UX и SEO

Один из лучших способов проанализировать производительность отдельной веб-страницы — загрузить ее в PageSpeed ​​Insights. Представление разделено на комбинацию:

• Данные на уровне URL.
• Данные происхождения (на уровне домена).
• Лабораторные данные.
• Данные поля.

Чтобы понять это, нам нужно рассмотреть пример:

https://pagespeed.web.dev/anaанализ/https-techcrunch-com/zo8d0t4x1p?form_factor=mobile

Здесь мы можем увидеть рейтинги скорости страниц и показатели домашней страницы TechCrunch.

Выше вы можете видеть, что оценка Core Web Vitals не удалась.

В мобильном Интернете важно выбрать вкладку «Результаты для мобильных устройств », которая должна отображаться по умолчанию (это результаты, которые действительно имеют значение).

Выберите переключатель «Происхождение» , чтобы видеть общие данные, усредненные по домену вашего сайта, а не только по домашней странице (или по любой другой странице, которую вы сканируете).

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

Итак, в чем же разница между новой оценкой Core Web Vitals и старой оценкой скорости страницы?

По сути, новая оценка Core Web Vitals (пройдено/не пройдено) основана на полевых данных (реальных пользователей).

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

По сути, Google перешел на оценку Core Web Vitals с точки зрения изменения рейтинга в поисковых системах.

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

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

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

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

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

Например, оба они ссылаются на первую отрисовку контента (FCP), наибольшую отрисовку контента (LCP) и совокупный сдвиг макета (CLS).

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

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

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

Оценка ваших CWV с помощью PageSpeed ​​Insights

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

Давайте вернемся к нашему исследованию TechCrunch:

https://pagespeed.web.dev/anaанализ/https-techcrunch-com/zo8d0t4x1p?form_factor=mobile

Здесь FID удовлетворен, а INP терпит неудачу лишь с небольшим отрывом.

У CLS есть некоторые проблемы, но основные проблемы связаны с LCP и FCP.

Давайте посмотрим, что говорит PageSpeed ​​Insights о возможностях и диагностике .

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

Выше вы можете увидеть небольшую дополнительную навигацию в правом верхнем углу, выделенную зеленым цветом.

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

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

Во-первых, нам говорят сократить количество неиспользуемого JavaScript. Это означает, что иногда JavaScript загружается, но не выполняется.

Также есть примечания по сокращению неиспользуемого CSS. Другими словами, загружаются некоторые стили CSS, которые не применяются (аналогичная проблема).

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

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

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

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

Поскольку мы также обнаружили неиспользуемые CSS и JavaScript, мы также можем провести общий аудит кода JavaScript, чтобы увидеть, можно ли развернуть JavaScript более разумно.

Вернёмся к возможностям и диагностике :

Сейчас мы хотим сосредоточиться на диагностике. Google намеренно ограничивает эти проверки из-за плохого соединения 4G, поэтому такие элементы, как работа основного потока, кажутся очень долгими (17 секунд).

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

Я хочу обратить ваше внимание на «Минимизацию работы основного потока». Эта единственная запись часто является золотой жилой для понимания.

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

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

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

Хорошая работа, но не все получится!

Google все больше и больше считает, что скорость реагирования на стороне клиента является нашей обязанностью. Как ни крути, но это так (так что вам лучше ознакомиться).

Вы можете в отчаянии сказать: «Почему это так!? Веб-браузеры уже много лет имеют доступ к нескольким потокам обработки, и даже мобильные браузеры догнали их. Нет нужды в том, чтобы все было так неловко, не так ли?

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

По всей вероятности, если бы все браузеры внезапно начали обрабатывать весь JavaScript параллельно, вне последовательности, большая часть сети, вероятно, рухнула бы и сгорела.

Итак, есть веская причина, по которой последовательное выполнение сценариев является поведением по умолчанию для современных веб-браузеров. Я продолжаю подчеркивать слово «по умолчанию». Почему это?

Потому что есть другие варианты. Один из них — запретить браузеру клиента обрабатывать любые сценарии, обрабатывая их от имени пользователя. Это известно как рендеринг на стороне сервера (SSR).

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

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

Вы не сторонник такого варианта? Хорошо, давайте рассмотрим распараллеливание JavaScript. Основная идея состоит в том, чтобы использовать веб-работников для определения того, какие скрипты будут загружаться последовательно, а какие — параллельно.

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

Однако реализовать его будет очень сложно и потребуется (как вы уже догадались!) время старшего веб-разработчика.

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

В этом примере вот что действительно интересно:

Сразу видно, что хотя основной поток занят 17 секунд, на выполнение JavaScript приходится 12 секунд.

Означает ли это, что 12 секунд из 17 секунд работы потока — это выполнение JavaScript? Это весьма вероятно.

Мы знаем, что весь JavaScript по умолчанию передается через основной поток.

Точно так же по умолчанию настроен WordPress, активная CMS.

Поскольку на этом сайте работает WordPress, все эти 12 секунд выполнения JavaScript, скорее всего, составляют 17 секунд работы основного потока.

Это отличное открытие, поскольку оно говорит нам, что большая часть времени основного потока обработки тратится на выполнение JavaScript. И глядя на количество упоминаемых сценариев, в это нетрудно поверить.

Крестовый поход в Chrome Dev Tools

Пришло время перейти к технике и снять тренировочные колеса.

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

Помните: выполняйте эти действия из чистого гостевого профиля Chrome.

Загрузите сайт, который хотите проанализировать. В нашем случае это TechCrunch.

Принимайте файлы cookie по мере необходимости. После загрузки страницы откройте Chrome DevTools (щелкните страницу правой кнопкой мыши и выберите «Проверить »).

Перейдите в «Производительность» > «Снимки экрана».

Нажмите кнопку перезагрузки, чтобы записать загрузку страницы. После этого будет создан отчет:

Здесь нам всем нужно глубоко вздохнуть и постараться не паниковать.

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

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

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

Вот где происходит загрузка главной страницы и что мне интересно изучить.

В данном случае я грубо выбрал диапазон времени и событий от 32мс до 2,97 секунды. Давайте сосредоточим внимание на внутренней части основного потока:

Знаете, раньше я говорил, что большинство задач рендеринга и выполнения JavaScript принудительно выполняются через узкое место основного потока?

Что ж, теперь мы смотрим на внутреннюю часть этого основного потока с течением времени. И да, желтым цветом можно увидеть множество скриптовых задач.

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

Хотя это мощный визуальный элемент, вы найдете еще более мощный в разделе «Сводка» :

Это суммирует все подробные данные, разбитые на простые тематические разделы (например, «Сценарии» , «Загрузка» , «Рендеринг ») с помощью удобного визуального средства в виде кольцевой диаграммы.

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

В 2023 году это одна из наиболее широко встречающихся проблем, имеющая мало простых и готовых решений.

Создать критически важные пути рендеринга JavaScript сложно. Для проведения аудита кода JavaScript требуется опыт, а внедрить распараллеливание JavaScript или SSR не так-то просто.

Теперь давайте посмотрим на Дерево вызовов :

Дерево вызовов часто более полезно, чем «Снизу вверх» .

Данные аналогичны, но дерево вызовов тематически группирует задачи в удобные сегменты, например Evaluate Script (выполнение сценария).

Затем вы можете щелкнуть группу, развернуть ее и увидеть сценарии и время их загрузки. 11% времени ушло на загрузку pubads_impl.jsm , а 6% времени ушло на загрузку opus.js

Я не знаю, что это за модули (и вы, возможно, тоже не знаете), но именно здесь часто начинается путь оптимизации.

Теперь мы можем сделать шаг назад и:

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

Другие инструменты для измерения и оптимизации Core Web Vitals

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

• Статистика PageSpeed
• Инструменты разработчика Chrome (вкладка «Производительность »)

Да, ты действительно можешь быть таким худым. Однако есть и другие инструменты, которые могут вам очень помочь:

• GTMetrix : особенно полезен благодаря своей водопадной диаграмме (для водопада требуется бесплатная учетная запись), которую вы можете научиться читать здесь. Не забывайте, что GTMetrix по умолчанию работает без ограничений, что дает слишком благоприятные результаты. Обязательно установите соединение LTE.
• Консоль поиска Google : если вы настроите это и подтвердите свой сайт, вы сможете увидеть множество данных о производительности и удобстве использования с течением времени, включая показатели Core Web Vitals на нескольких страницах (агрегированные).
• Screaming Frog SEO Spider : его можно подключить к API скорости страницы, чтобы обеспечить массовую выборку оценок Core Web Vitals Pass или Fail (для нескольких страниц). Если вы используете бесплатный API скорости страницы, не забивайте его необоснованным образом.

Раньше повысить рейтинг скорости страницы было так же просто, как сжать и загрузить несколько изображений.

Настоящее время? Это сложная кампания Core Web Vitals.

Приготовьтесь к полноценному участию. Все, что меньше, приведет к провалу.