Как подготовить сайт к Core Web Vitals

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

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

Анонс Core Web Vitals от Google

В мае 2020 года Google объявил, что Core Web Vitals станет частью алгоритмов Google в 2021 году, с оговоркой для оптимизаторов, что «нет необходимости немедленно принимать меры». 

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

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

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

Показатели Core Web Vitals

Ниже Гугл представил показатели, которые необходимо проанализировать в ходе оптимизации сайта под Core Web Vitals:

Largest Contentful Paint (LCP) — измеряет производительность загрузки (сколько времени требуется для загрузки самого большого элемента в области просмотра).

Чтобы обеспечить удобство работы пользователя, LCP должна срабатывать в течение 2,5 секунд после первой загрузки страницы и не позже 4 секунд; это поможет избежать низкой оценки.

FirstInputDelay (FID) измеряет интерактивность (сколько времени требуется сайту для ответа, когда пользователь куда-то нажимает). 

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

CumulativeLayoutShift (CLS) измеряет визуальную стабильность (смещается ли страница по мере того, как пользователь прокручивает содержимое). 

Чтобы обеспечить удобство работы пользователей, страницы в идеале должны поддерживать CLS ниже 0,1 и не превышать значения 0,25.

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

Core Web Vitals аудит сайта с помощью Screaming Frog

Недостаточно знать, что такое Core Web Vitals. Поиск способа проверки и постановки ТЗ клиенту для исправления проблем, связанных с Core Web Vitals — вот основная проблема, с которой столкнулись оптимизаторы.

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

Для начала аудита вам потребуется:

• Платная версия поискового робота Screaming Frog;

• Ключ API PageSpeed ​​Insights (который можно получить на этой странице документации Google PageSpeed ​​Insights);

• Домен сайта.

Шаг 1. Подключаем ключ API PageSpeed ​​Insights к Screaming Frog

Вам нужно подключить ключ API PageSpeed ​​Insights в Screaming Frog. Это позволит вам получить доступ к данным и рекомендациям PageSpeed ​​Insights для каждой страницы. У PageSpeed ​​Insights есть лимиты — около 25 000 в день, которых должно хватить для небольших сайтов, а для более крупных проектов вы сможете реплицировать информацию, полученную с других типовых страниц.

• Скопируйте ключ API PageSpeed ​​Insights и вставьте в Screaming Frog. Перейдите в Конфигурация —> Доступ к API —> PageSpeed ​​Insights;

• Вставьте свой ключ API в поле «Секретный ключ»;

• Нажмите «Подключиться».

После подключения нажмите «Metrics». Здесь вы определите метрики, которые будут отображаться при сканировании. Для целей этого аудита я выбираю «Все группы показателей», но вы можете выбрать только те, по которым хотите составить отчет, и нажать «ОК».

Доступны следующие группы показателей:

• Overview — предоставляет общую обзорную информацию для страницы, такую ​​как размер страницы и потенциальная экономия нагрузки для страницы.
• CrUX Metrics — данные из отчета пользователей гугл хром. Если данные поля от реальных, включенных пользователей доступны, они появятся здесь.
• Lighthouse Metrics— отсюда берется большинство данных, которые мы используем в ходе аудита, включая оценки LCP, TBT и CLS.
• Opportunities — предоставляет советы по улучшению скорости для каждой страницы.
• Diagnostics — предоставляет дополнительную информацию об общей производительности сканируемого сайта.

Шаг 2: просканируйте сайт

Во время сканирования сайта вы заметите, что в правом верхнем углу появился индикатор выполнения «API». Вам нужно подождать, пока оба показателя достигнут 100%, прежде чем вы начнете анализировать данные.

Шаг 3. Анализ общего состояния сайта

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

На верхней панели навигации выберите «PageSpeed», а затем «Экспорт».

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

• Largest Contentful Paint Time (ms) — фильтр для поиска всех страниц с LCP 4000 мс и более.
• Total Blocking Time (ms) — фильтр для поиска всех страниц с TBT 300 мс и более.
• Cumulative Layout Shift — фильтр страниц с CLS 0,25 и более.

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

• 95% страниц имеют отрисовку содержимого на экране более 4 секунд (сбой) — см. вкладку «LCP> 4s» в прилагаемой таблице данных;
• 58% страниц имеют общее время блокировки более 300 миллисекунд (сбой) — см. вкладку «TBT> 300ms» в прилагаемой таблице данных;
• 93% страниц имеют оценку совокупного сдвига макета более 0,25 (сбой) — см. вкладку «CLS> 0,25» в прилагаемой таблице данных.

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

Присоединяй­тесь к
Rush-Analytics уже сегодня

7-ми дневный бесплатный доступ к полному функционалу. Без привязки карты.

Попробовать бесплатно

Шаг 4. Готовим ТЗ для исправления для каждой страницы

Результат аудита — превращение проблемы в решение. Мы знаем, что X страниц не соответствует минимальным пороговым значениям Core Web Vitals, но что мы можем с этим поделать? Вот где действительно творит свое чудо API PageSpeed ​​Insights.

Справа на вкладке «Overview» прокрутите вниз до «PageSpeed». Здесь вы найдете список проблем/рекомендаций, касающихся скорости загрузки страниц и, по большей части, Core Web Vitals. 

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

Кликните на проблему, чтобы просмотреть затронутые страницы и экспортировать их в таблицу. Теперь вы знаете, сколько страниц затронула конкретная проблема.

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

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

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

Шаг 5. Анализ проблем, которые характерны для каждой страницы

Следуя примеру ресурсов с блокировкой рендеринга, теперь вам нужно выбрать один из URL-адресов, затронутых этой проблемой, и выбрать вкладку «PageSpeed ​​Details» на нижней панели навигации. 

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

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

Вы можете массово экспортировать конкретные проблемы:

Reports —> PageSpeed —> Конкретная проблема.

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

Шаг 6. После внесения изменений повторно проверьте сайт

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

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

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

Рекомендуемые инструменты:

Кластеризация семантики

Парсер wordstat

Статистика ключевых запросов гугл