Google PageSpeed Insights 2021

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

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

В апреле 2019-го в Гугле решили ужесточить требования для их главного инструмента для проверки скорости загрузки сайтов — в сервисе Google PageSpeed Insights (вот здесь рассказываем, что за сервис и на что изменения повлияли тогда). Из-за этого некогда шустрые по меркам Гугла и «зелёненькие» интернет-ресурсы внезапно стали красными — а значения Google PageSpeed очень влияют на позиции в поисковой выдаче.

Тогда, чтобы вернуть сайты в зелёную зону, приходилось идти на разные шаги:

сокращать объём скриптов JavaScript — а значит, расставаться со счётчиками поведения вроде Яндекс. Метрики или заставлять их подгружаться позже (SEO-специалисты также призывают сжимать файлы CSS, HTML и JavaScript, если они весят больше 150 байт);
аккуратничать с добавлениями видео с Ютуба через <iframe>;
минимизировать количество слайдеров на страницах;
сто раз думать перед установкой онлайн-чатиков, сервисов обратного звонка и прочих маркетинговых примочек;
использовать CDN и AMP-страницы;
конвертировать изображения в формат .webp.
использовать модуль Гугла ngx_pagespeed;
прописывать кэширующие заголовки у статичных ресурсов;
отключать все скрипты, когда на сайт заходит робот Гугла.

В Google стараются заставить владельцев сайтов улучшать загрузку страниц уже давно — с 2010 года, когда в компании впервые объявили, что скорость сайта будет новым фактором ранжирования в результатах поиска. В 2018 году алгоритм ранжирования стал учитывать скорость мобильной страницы.
С той поры скорость загрузки сайтов становилась всё важнее, а пользователи — всё избалованнее: они всё чаще ждут быстрой работы сайтов. Наверное, поэтому в 2020 году скорость страницы уже напрямую связана не только с рейтингом сайта в поисковике Гугла, но и с тем, насколько сайт хорош в лидогенерации.

С мая 2021 Гугл обещает сделать ставку на удобство пользователей — поэтому ещё в конце апреля 2020-го в компании объявили самыми важными показателями три параметра, объединенных в группу Core Web Vitals:

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

Что означает «основной контент»? Это самый большой блок в стартовом окне просмотра страницы — текст, изображение в шапке или видео. По мере загрузки остального контента Гугл сравнивает время загрузки остальных элементов страницы, с тем временем, что ушло на загрузку LCP. Если остальной контент подгружается медленнее, то показатель LCP обновляется — до тех пор, пока пользователь не начнет взаимодействие (щелчок мышки, прокрутка или ввод текста в поле).

Что измеряется параметром LCP <a href="https://api.vc.ru/v2.8/redirect?to=https%3A%2F%2Fhuckabuy.com%2F2020%2F12%2F30%2Fintroduction-to-largest-contentful-paint-for-seo%2F&postId=212614" rel="nofollow noreferrer noopener" target="_blank">Источник</a>

На что влияет LCP:

На количество индексированных страниц. Чем медленнее загружается контент на страницах, тем меньшее количество страниц может просканировать поисковая система в течение сеанса на сайте — как результат, меньше проиндексированных страниц и меньше возможностей для ранжирования контента в результатах поиска.
На конверсии и потенциальный доход владельца сайта. Метрика не взялась с «потолка» — её нижние границы продиктованы поведением пользователей в текущих реалиях. Всё реже они готовы ждать более 3 секунд ради загрузки контента — скорее всего, после такого ожидания человек вообще откажется ждать хоть сколько-то ещё. А это — больше отказов, ниже конверсии и ниже доход для бизнеса.

Что влияет на LCP:

Время ответа сервера: чем дольше браузер получает контент с сервера, тем больше времени требуется для его отображения и тем больше показатель LCP.
JS и CSS, блокирующие рендеринг: некритические скрипты и таблицы стилей увеличивают LCP. Если не отложить их загрузку, скорость страницы будет ниже (например, гугловскую рекапчу Google PageSpeed Insights тоже не любит).
Время загрузки ресурсов: фоновый контент, изображения и видео — чем дольше они грузятся, тем хуже показатель LCP.
Рендеринг на стороне клиента (браузера): в этом случае пользователь не может взаимодействовать со страницей, пока не загрузится и не выполнится весь JS (альтернатива — серверный рендеринг).
Скорость интернет-соединения на устройстве пользователя.

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

На что влияет FID:

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

Что влияет на FID:

объём загружаемых скриптов JS и CSS — чем больше JS используется на страницах, тем больше будет показатель FID: браузер будет обрабатывать часть содержимого страницы, но при этом пользователь не сможет ничего делать на ней до полной загрузки скриптов.

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

Как это измеряется: если элемент изначально занимал 35% экрана, потом «уполз» на 15%, а в итоге он занял 50% области просмотра. 50% — это доля воздействия элемента, а 15% — доля изменения расстояния. Чтобы получить CLS, эти две цифры умножаются: 50% * 15% = 7,5% или 0,075.

На что влияет CLS:

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

Что влияет на CLS:

динамический контент — например, виджеты с видео от Youtube: могут вызывать сдвиги макета, потому что сайты, куда встраивается такая штука, не резервируют достаточно места для истинного размера вставки.
изображения без размеров — точнее, использование скриптов CSS для масштабирования изображений в рамках адаптивного дизайна вместо указания конкретных размеров картинки.
нестандартные шрифты — во время их подгрузки текст может «прыгать» и меняться (одно дело в текстовом блоке, другое — в форме обратной связи или оплаты).

Исследования самого Google и отраслевые исследования указывают на корреляцию между положительным пользовательским опытом и конверсиями:
— у страниц, загруженных за 2,4 секунды, коэффициент конверсии — 1,9%;
— за 3,3 секунды — коэффициент конверсии уже 1,5%;
— за 4,2 секунды — коэффициент конверсии менее 1%;
— при загрузке страницы за 5,7 секунды или дольше — коэффициент конверсии всего 0,6%.

Чем дольше время загрузки страницы, тем сильнее оно влияет на показатель отказов:
— если время загрузки увеличивается с 1 до 3 секунд, показатель отказов увеличивается на 32%;
— если время загрузки страницы увеличивается с 1 до 6 секунд, показатель отказов возрастает уже на 106%.

Есть соотношение и между FID и доходом:
— на мобильных устройствах за 1 сеанс пользователи при быстрой интерактивности сайта (до 100 мс) приносят на 75% больше выручки, чем при среднем FID, и на 327% больше выручки, чем с высоким FID (более 300 мс).
— на ПК при быстрой интерактивности сайта пользователи за 1 сеанс приносят на 212% больше выручки, чем при среднем FID, и на 572% больше, чем при высоком показателе FID.

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

Помимо Core Web Vitals Гугл по-прежнему смотрит на:

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

Google планирует выпустить новое обновление Page Experience Update с новыми алгоритмами ранжирования, учитывающими метрики Core Web Vitals, в мае 2021 года — и пока у владельцев сайтов всё ещё есть время, чтобы к нему подготовиться.

И действительно — почему критичными становятся скорость загрузки больше 4 секунд или доступность страницы для взаимодействия позже, чем через 300 мс?

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

В интернете можно найти рекомендации относительно оптимального времени загрузки страницы — 1 секунда. Чаще всего при этом ссылаются либо на исследование Стюарта Карда, либо статьи Роберта Миллера. В них описывается скорость реакции интерфейса на действия пользователя, которую тот считает немедленной — и которая часто варьирует от 0,5 до 2−3 секунд. Специалисты Гугла также проверили скорость загрузки большинства сайтов в интернете и выяснили, что большинство прошедших проверку по возможным пороговым значениям метрики LCP загружаются в диапазоне от 2,5 до 3 секунд — в процентном соотношении доли сайтов выглядят так:

Также в Гугле проверили и объём сайтов, не прошедших по возможным пороговым значениям метрики LCP и загружающихся дольше 3 секунд. Цифры оказались следующими:

На основании этих данных в Гугле решили, что «хорошие» значения для LCP — это 2,5 секунды или быстрее.

Для оптимального FID у Гугла используется порог в 100 мс — его упоминает Якоб Нильсен (тот самый из Нильсен-Норманн Групп), на которого ссылаются и упомянутые Кард и Миллер. При этом сам Нильсен берёт эту цифру у Альберта Мишотта в его книге «Восприятие причинности». Он же получил это значение в ходе эксперимента с группой людей.

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

при задержке в 100 мс участники думали, что движение объекта В запускается объектом А;

при задержке в 100−200 мс участники с трудом могли определить эту причинно-следственную связь;

при задержке более 200 мс участники были уверены, что объект В начинал движение сам по себе, независимо от объекта А.

В отношении параметра CLS Гугл честно признаётся, что метрика новая, и каких-либо исследований на этот счёт нет. Но в ходе собственных экспериментов они пришли к выводу, что сдвиги на 10% и менее хотя и заметны, но не слишком критичны для пользовательского опыта.

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

Сервиса PageSpeed Insights (PSI): он расскажет о совокупной эффективности отдельной страницы и сайта в целом и предложит, как улучшить показатели.
Search Console — расскажет об эффективности каждой конкретной страницы, благодаря чему можно найти особенно критичные страницы, нуждающиеся в улучшении (правда, здесь придётся подтвердить право собственности на сайт).
Панели управления CrUX — предварительно созданная панель управления, которая расскажет о пользовательском опыте в браузере Chrome, включает больше параметров, плюс их можно разбить на категории (по типу устройства, например).
JS-библиотеки Web Vitals (для прошаренных) — предоставляет удобный API для сбора и создания отчетов по каждой измеряемой метрике Web Vitals.

Расширения Web Vitals Chrome Extension — будет автоматически измерять LCP, FID и CLS для конкретной страницы (инструмент хорош для разработчиков, поскольку сигнализирует о производительности в режиме реального времени при внесении изменений в код).
Инструмента Lighthouse — может рассказать о LCP и CLS; FID узнать не получится, но вместо этой метрики можно смотреть на TBT (общее время блокировки — оценивает время, когда страница не интерактивна). А чтобы узнать влияние конкретных метрик на скорость загрузки, можно использовать калькулятор Lighthouse Scorecalc.
Сервиса WebPageTest — он включает три ключевые метрики Core Web Vitals в свою стандартную отчетность.

Среди решений не так уж много новых по сравнению с теми, о которых мы писали в 2019-м. Всё так же тренд на сокращение объёмов JS и CSS, отказ от сложных дизайнерских элементов в пользу простоты, ну и парочка специфических рекомендаций для каждого конкретного параметра Core Web Vitals.

Оптимизировать серверный код — например, отказаться от отрисовки содержимого в браузере в пользу серверного рендеринга (скажем, с помощью фреймворка React).
Если аудитория сайта сильно разнится географически, использовать CDN — сеть распределенный серверов, чтобы пользователи из Владивостока так же шустро открывали ваш сайта, как и юзеры из Москвы.
Кэшировать HTML статичных страниц на стороне сервера — чтобы не загружать их каждый раз заново, а показывать пользователю сохранённую копию.
Использовать service worker — он перехватывает запросы с сервера, кеширует часть или всё содержимое HTML-страницы и обновляет кеш только при каких-то изменениях на странице.
Просить браузер устанавливать подключение к сторонним сервисам как можно скорее — Гугл рекомендует прописывать это в коде как:

Минимизировать CSS и JS — можно использовать плагины для минимизации (например, для CSS — плагин для webpack); скрипты также можно сжать.
Прописать ленивую инициализацию JS-блоков (загрузка по запросу пользователя).
Сокращать размер структуры DOM (дерева HTML-страницы, которое строит браузер при получении HTML от сервера) за счёт сокращения вложенности.
Запускать поиск JS-элементов в DOM после подгрузки конкретного блока.
Отложить некритический CSS — удалить полностью или переместить в другую таблицу стилей, если такой CSS используется на отдельной странице сайта.
Встроить критический CSS в <head> — помогает избежать необходимости двустороннего запроса для получения этого критического CSS.
Отложить выполнение некритичного JS — либо подгружать его спустя какое-то время, либо только по запросу пользователя.

Сжимать изображения или преобразовывать их в новые форматы (JPEG 2000, JPEG XR или WebP).
Использовать lazyload (ленивую загрузку) для графического контента — когда изображения подгружаются по мере скроллинга страницы, а не все сразу.
Сжимать текстовые файлы — например, с помощью алгоритмов сжатия Gzip или Brotli, которые значительно уменьшают размер текстовых файлов (HTML, CSS, JavaScript) при их передаче между сервером и браузером.
Использовать адаптивные изображения (задаются через атрибуты srcset и <picture>) — хороши тем, что у браузера есть выбор из нескольких размеров изображений, и он автоматически показывает именно то, которое больше всего соответствует размеру экрана устройства пользователя.
Настроить адаптивную подачу контента — например, показывать изображение вместо видео, если скорость соединения пользователя меньше 4G.

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

На FID точно так же влияет объём скриптов, поэтому рекомендация всё та же — как можно меньше CSS и JS: меньше сторонних библиотек, меньше слайдеров (2−3 на страницу, а лучше — вообще один), меньше вычурных скроллов (аналогично, лучше — один и кастомный). Рекомендация оставить только критический CSS и JS, а остальные скрипты отложить или переместить значительно ниже на странице — тоже сохраняются.

Чтобы «приручить» FID, также можно:

разбить долго выполняющийся JS-код (более 50 мс) на более мелкие асинхронные задачи;
использовать web-workers — специальное API-решение, которое позволяет загружать JavaScript, который не связан с пользовательским интерфейсом, в фоновом режиме (и при этом никак не влиять на FID).
отложить выполнение сторонних (тех самых маркетинговых «следилок» и чатиков) и неиспользуемых в первые секунды загрузки скриптов — как вариант, подключать внешние скрипты только для реальных пользователей (роботу Гугла не показывать их).

Ребята из Carrot quest проверили, как установка разных чатов влияет на скорость загрузки сайта — для эксперимента они создали пустой тестовый сайт, куда устанавливали разные чаты, чтобы улучшить собственное решение на фоне конкурентов. В топ-5 чатов, наименее влияющих на скорость загрузки страницы, в итоге вошли:
1. Carrot quest,
2. Юздеск,
3. Intercom,
4. User.com,
5. Livechat.
Хуже всех — чат от Livetex.
Кстати, в более ранней своей статье мы тоже проводили такой эксперимент. Тогда в лидерах были чаты от WebConsult, Битрикса и Jivosite.

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

Очевидное решение — верстать сразу так, будто JS не существует: иными словами, чтобы при подключении JS блоки на странице не меняли размер. Среди прочих способов уменьшить сдвиг макета:

Прописывать размеры для изображений и видео через атрибуты width/height и их ширину через стили. Если изображения адаптивные, указывать хотя бы пропорции (например, 2:3 или 16:9).Такой подход гарантирует, что браузер заранее подготовит место на странице под загрузку этого изображения.

Для пропорций изображений обычно используется известный трюк с padding-top: calc (@ratio*100%, который задает высоту блоку, в котором содержится изображение/видео. Для изображений также срабатывает CSS-свойство object-fit, которое позволяет вписывать/накладывать/растягивать изображение в существующий контейнер: например, горизонтальное изображение на десктопе кадрировать для мобильной версии. Другой вариант — создание CSS-свойства aspect-ratio, которое позволяет добиться аналогичного эффекта для любых других блоков. На данный момент поддерживается только в Chrome 88+.
Леонид, Разработчик

Как выглядит изображение на странице в зависимости от указанного свойства object-fit <a href="https://api.vc.ru/v2.8/redirect?to=https%3A%2F%2Fweb.dev%2Faspect-ratio%2F&postId=212614" rel="nofollow noreferrer noopener" target="_blank">Источник</a>

Для рекламных баннеров задавать определенное положение, где они будут отображаться — так браузер будет резервировать под них достаточно места (когда ширина и высота баннера не заданы, сдвиг макета при загрузке неизбежен). Это же касается и вставок через <iframe>.
Включать атрибуты размеров в динамически отображаемый контент (видео Youtube или вставка с твитом).
Избегать вставки нового контента поверх существующего — если только это результат взаимодействия с пользователем (а значит, он это ожидает): речь идёт о внезапно всплывающих формах подписки, «читайте ещё по теме» и уведомлениях о GDPR.
Использовать предварительную загрузку шрифтов: браузер видит объявление о предзагрузке шрифта, загружает его, параллельно загружает CSS и к моменту, как он его разберет, шрифт уже будет доступен для рендера. Без предзагрузки браузер сначала читает страницу, видит указание на CSS, скачивает его, разбирает, находит блок с описанием шрифтов и только потом начинает их загрузку — это и замедляет загрузку страницы, и способствует сдвигам макета.
Настроить рендеринг шрифтов: либо рендерить текстовый контент доступным системе шрифтом, но до загрузки невидимым пользователю, и потом показать итоговый шрифт на странице, либо рендерить его доступным шрифтом (пользователь видит контент с базовым шрифтом) и подменить шрифт уже после его загрузки. Методы отличаются лишь тем, что видит пользователь, и как долго ожидается загрузка шрифта: в первом случае скорость загрузки ниже, но сдвиг макета минимальный, во втором — загрузка быстрее, но сдвиг более вероятен.

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

Гугл также пишет, что с мая 2021 года при определении рейтинга в результатах поиска приоритет получат страницы, которые удобно просматривать. Чтобы пользователи сразу понимали, удобна страница для просмотра или нет — в результатах поиска будет приводиться её фрагмент или изображение с неё.

При этом в компании говорят, что технология, с помощью которой создана та или иная страница (например, AMP), учитываться не будет. Также в планах у поисковика Гугла — визуальный индикатор, выделяющий в результатах поиска страницы, удобные для просмотра. Поэтому, даже если ваш сайт уже соответствует новым метрикам, расслабляться не стоит :)