Google PageSpeed Insights 2021

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

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

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

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

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

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

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

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

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

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

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

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

• при задержке в 100 мс участники думали, что движение объекта В запускается объектом А;
  
• при задержке в 100−200 мс участники с трудом могли определить эту причинно-следственную связь;
  
• при задержке более 200 мс участники были уверены, что объект В начинал движение сам по себе, независимо от объекта А.

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


Полевые данные можно собрать с помощью:

• Сервиса 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 в свою стандартную отчетность.

• Оптимизировать серверный код — например, отказаться от отрисовки содержимого в браузере в пользу серверного рендеринга (скажем, с помощью фреймворка 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.

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