Google PageSpeed Insights 2021

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

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

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

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

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

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

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

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

На что влияет 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 для масштабирования изображений в рамках адаптивного дизайна вместо указания конкретных размеров картинки.
• нестандартные шрифты — во время их подгрузки текст может «прыгать» и меняться (одно дело в текстовом блоке, другое — в форме обратной связи или оплаты).

Текущий набор метрик фокусируется на трех аспектах взаимодействия с пользователем — скорости загрузки, интерактивности и визуальной стабильности. Каждый показатель из 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).
• отложить выполнение сторонних (тех самых маркетинговых «следилок» и чатиков) и неиспользуемых в первые секунды загрузки скриптов — как вариант, подключать внешние скрипты только для реальных пользователей (роботу Гугла не показывать их).

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

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

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

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

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

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

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