Название нового принципа по оценке скорости загрузки сайта дословно переводится как «Основные жизненно важные веб-показатели». Для чего они введены, сейчас разберемся!
Внедрение
Любые серьезные обновления алгоритмов компания Google внедряет постепенно. Core Web Vitals, который мы для краткости будем обозначать CWV, — не исключение. В полную силу CWV вошел недавно — в конце августа этого года. Постепенное же внедрение обновления началось с майских апдейтов 2021 года.
Подготовкой к внедрению CWV можно считать и концепцию Mobile First, появившуюся в начале 2018 года:
Теперь скорость загрузки сайтов является одним из главных факторов их ранжирования. Если скорость недостаточна, сайт может быть пессимизирован.
До CWV при оценке скорости загрузки страниц Google руководствовался несколько иным набором параметров:
- Время загрузки первого контента.
- Максимальная потенциальная задержка после первого ввода.
- Индекс скорости загрузки.
- Время загрузки достаточной части контента.
- Время окончания работы ЦП.
- Время загрузки для взаимодействия.
Все эти показатели можно было оценить в PageSpeed Insights, который выглядел в 2018 году так:
Кстати, сервис и сейчас дает подробные рекомендации для увеличения скорости загрузки сайта:
На практике оценки PageSpeed Insights были бесполезны, так как сервис имитировал загрузку сайта с учетом расположения сервера в Европе. Соответственно, страницы в любом случае загружались дольше, чем в России.
Влияет ли скорость загрузки на индексирование Google
Скорость загрузки сайта напрямую не влияет на процесс индексирования. Главное для Google — это улучшение пользовательского опыта. Связь простая: недостаточная скорость загрузки веб-страниц значительно ухудшает опыт и, следовательно, поведенческие факторы аудитории.
Что нового в CWV: обещания и реальность
Ранее Google неоднократно заявлял: группа факторов CWV станет одним из главных ориентиров для ранжирования всех сайтов в интернете. Так, при прочих равных, две полностью релевантные/полезные страницы могут ранжироваться выше или ниже по отношению друг другу. Более высокую позицию получит домен с лучшими показателями в CWV. Справедливо ли это? Узнаем позже, ведь оценки CWV не учитывались на 100% до конца августа 2021 года.
Прошел практически год с начала внедрения Core Web Vitals. Но даже сегодня делать выводы об эффективности или неэффективности его алгоритмов еще очень рано. По опыту внедрения других обновлений можно предположить, что сперва изменения затронут бурж, и лишь после этого коснутся сайтов в рунете. В любом случае, я советую следить за новостями о Core Web Vitals только в Google Search Center, так как на эту тему появляется очень много спекуляций.
Где проверять Core Web Vitals
Новые оценки я проверяю прямо в Google Search Console и реже — через PageSpeed Insights. Для этого существует много других способов. Например, Lighthouse. Но подобные инструменты больше годятся для разработчиков, чем для обычных вебмастеров.
В Google Search Console
Итак, проще всего проверить CWV в Google Search Console. Просто откройте раздел «Качество» и выберите отчет «Основные интернет показатели»:
В отчете будут указаны все проблемы, существующие на сайте по мнению CWV:
Проверка основных веб-показателей Google с помощью PageSpeed Insights, о котором я уже упомянул чуть выше, столь же проста.
Проверка в PageSpeed Insights
Для этого открываем сервис и указываем URL веб-страниц или домена:
Нажимаем кнопку «Анализировать» и ждем несколько секунд:
В итоге мы получаем отчет, в котором указано, отвечает ли проверяемая страница требованиям Core Web Vitals или нет:
Как видите, из параметров Core Web Vitals здесь представлены все три — FID, LCP и CLS). И только FCP не относится к CWV напрямую.
Как разобраться в FID, LCP и CLS
Основные параметры CWV — взаимодействие с контентом, отрисовка контента, время до первого взаимодействия. Давайте разберемся в них чуть подробнее, чтобы точно понимать, из чего именно они складываются.
Largest Contentful Paint (не путать с Pain:). Допустимое время — не более 2,5 секунд. Этот параметр обозначается как LCP и показывает время, необходимое на завершенный рендер наибольшего элемента, который находится в видимой области просмотра. В качестве такого элемента, обычно, выступает картинка или блок, в котором выводится видео.
Допустимые и недопустимые показатели на рендер самого большого элемента весьма просты:
Cumulative Layout Shift. Допустимая оценка — не более 0,1 балла. Если переводить дословно, то это «накопительный сдвиг макета». Параметр обозначается аббревиатурой CLS и демонстрирует процент сдвига области просмотра страницы.
Для наглядности параметра приведу пример: вы открываете страницу, читаете на ней текст и вдруг, неожиданно, область просмотра (а соответственно и весь текст) сдвигается куда-то вверх или вниз. Это и есть смещение макета, и оно очень негативно влияет на пользовательский опыт.
Смещение элементов страницы может происходить даже без попыток взаимодействия с элементами страницы. Главные причины: шрифты, iframe, безатрибутные изображения и динамические блоки.
Допустимые и недопустимые показатели сдвига макета в процентах выглядят так:
First Input Delay. Допустимая оценка — не более 100 миллисекунд. Название переводится как «задержка первого входа» (а точнее — ввода) или FID. Под входом/вводом имеется в виду открытие страницы при первом посещении сайта. Под задержкой — время загрузки страницы до тех пор, пока элементы на ней не станут кликабельными. Если на вашем сайте существует серьезная задержки ввода, срочно займитесь ее устранением. Эффективное время инициализация сайта эквивалентно хорошему FID.
Допустимые и недопустимые показатели задержки первого ввода выглядят следующим образом:
Подытожим все вышесказанное.
LCP или Largest Contentful Paint — физическая скорость загрузки страницы.
CLS или Cumulative Layout Shift — отсутствие смещений макета и, следовательно, элементов страницы.
FID или First Input Delay— временной интервал после которого посетитель может начать взаимодействие с кликабельными элементами страницы.
AMP-страницы
Дисклеймер: все написанное далее особенно актуально для AMP-страниц. Однако, все эти рекомендации будут справедливы и для обычных страниц, если вам нужно улучшить оценки CWV.
Наличие AMP-страниц на сайте не является прямым фактором ранжирования, скорее, косвенным. Такие страницы могут ранжироваться немного выше.
Давайте посмотрим на достоинства AMP-технологии с точки зрения соответствия требованиям Core Web Vital.
Накопительный сдвиг макета
Динамические функции, в любом случае, ждут начала взаимодействия с посетителем (когда он тапнет по кнопке, например). AMP-страницы предусматривают такое развитие событий, поэтому любой потенциально опасный (в плане сдвига страницы) элемент не будет активирован, если посетитель еще не начал взаимодействовать со страницей.
Предварительный рендеринг
AMP-страницы предварительно загружаются в кэш Google (он же Google Cache) и там обрабатываются. Это также в разы ускоряет загрузку AMP-страниц по сравнению с обычными. Ведь страница уже была предварительно обработана, и браузер успешно загрузил контент.
Задержка первого ввода
AMP-код никак не блокирует взаимодействие с пользователем, так как технология допускает только асинхронный JavaScript.
Соответственно, при загрузке основной поток браузера не занят тяжелыми операциями, которые могут тормозить взаимодействие пользователей с сайтом.
AMP-странице, как правило, требуется менее 100 миллисекунд, чтобы идентифицировать начало взаимодействия с ней. 100 миллисекунд — достаточно небольшое количество времени, чтобы получить оценку «Хорошо» в Core Web Vitals.
Приоритезация контента
Если вы изучали AMP-страницы, то знаете: они используют минимальное количество JavaScript и отсекают на корню все CSS.
Контент загружается гораздо быстрее, чем на обычных страницах. Это значительный плюс для попадания в зеленую зону Core Web Vitals.
AMP знает, какой контент находится в приоритете, и ограничивает иные ресурсы. На выходе получаем самую быструю отрисовку и бонусы по CWV.
Отложенный макет
Базовая оценка Core Web Vitals измеряет только первое «впечатление» области просмотра. Измерение заканчивается, когда пользователь начинает взаимодействовать со страницей (например, скролить ее). AMP-технология устраняет этот недостаток и тормозит рендеринг элементов, расположенных ниже по странице (речь об отложенном макете).
Внизу страницы присутствует «тяжелый» JavaScript-виджет? Значит будет серьезная задержка перед первым взаимодействием.
Разделенные процессы
Задачи, на выполнение которых нужно больше времени (длинные задачи), вызывают задержки перед началом взаимодействия с пользователем, блокируя страницу до тех пор, пока инициализация подобной задачи не будет завершена.
Технология AMP позволяет разделить выполнение длинных задач (более 150 миллисекунд) на отрезки. Небольшая задача хороша тем, что при ее прерывании браузер может мгновенно подхватить новую. Ждать завершения обработки длинной задачи уже не нужно. Этим и объясняется высокая скорость каждого взаимодействия у AMP-страниц.
Встроенные компоненты
AMP-технология обеспечивает максимально стабильные макеты, поскольку структура AMP-страницы определяет размер ресурсов еще до начала их загрузки. Изображения, видео и окна iframe загружаются с помощью встроенных компонентов, которые имеют заранее определенную высоту/ширину.
Предварительная установка высоты/ширины предотвращает смещение элементов с неопределенными размерами по отношению к другим элементам. Это очень удобно.
Виджеты изолированы
Если требуется добавить на страницу внешний код (например, виджет), его необходимо загрузить вне основной AMP-страницы. Самое очевидное решение — задействовать простой iframe. Запуская внешний код в отдельном контейнере, мы изолируем его от основного кода. Соответственно, тяжелые виджеты или другие объекты больше не тормозят взаимодействие пользователя со страницей.
Стоит ли использовать AMP для улучшения показателей Core Web Vitals
Хуже не будет: AMP-страницы получают самые высокие результаты в Core Web Vitals. Но, тем не менее, существуют факторы, которые внедрением AMP-технологии не исправишь, и такие факторы могут мешать страницам соответствовать пороговым значениям CWV. В первую очередь, это медленное время отклика сервера, неоптимизированные изображения, тяжелые файлы. Кроме того, не каждую страницу можно переделать в AMP-версию. Поэтому внедрение AMP-страниц на сайт не является панацеей для улучшения показателей в CWV, но экспериментировать, определенно, стоит.
Создание AMP-страниц сэкономит немало времени, так как вы начнете работать над оптимизацией каждой контентной страницы, пусть и не совсем обычным образом. Google любит AMP и ранжирует такие страницы немного выше. Поэтому, внедрять эту технологию полезно.
5 советов, как улучшить показатели CWV на сайте
В этот список вошли только проверенные мной действия, позволившие улучшить оценку Core Web Vitals на двух сайтах.
1. Оптимизируйте и сжимайте изображения
Наверняка вы слышали о том, что все картинки на сайте нужно сжимать. Другими словами, использовать компрессию.
Сжимая изображение, вы уменьшаете общий размер страницы и улучшаете оценку LCP. Сжатие не ухудшает качество или разрешение картинки — разницу вы увидите только при увеличении масштаба.
2. Уменьшите время отклика сервера
Чем дольше браузер получает контент с сервера, тем больше времени требуется для отображения такого элемента (или всей страницы) на экране. Быстрое время ответа сервера — это улучшение всех показателей загрузки страницы, включая LCP.
Длительное время отклика сервера — это всегда плохо. Это ухудшение UX, SEO и юзабилити в целом.
Если TTFB неприемлемый (более 200 миллисекунд) — обратитесь к хостинг-провайдеру. Иногда виноват именно он.
Отмечу главные причины медленного отклика сервера: чудит хостинг, на сайте используется слишком много плагинов (чем меньше их будет, тем лучше), вы используете «тяжелую» тему для CMS (она забирает все ресурсы), код страницы слишком большой.
3. Уменьшите время выполнения JavaScript, удалив или оптимизировав ненужный код
Если отчет CWV выводит неудовлетворительную оценку FID, значит страница взаимодействует с пользователями более 300 миллисекунд. Займитесь оптимизацией JavaScript, который присутствует на странице. Сокращайте, удаляйте, оптимизируйте. FID заметно уменьшится.
Лайфхак: чтобы уменьшить FID, нужно отложить неиспользуемый JS. Как его найти? Открываем режим просмотра кода в используемом браузере. Для этого выделяем фрагмент на странице и кликаем по нему правой кнопкой. Откроется контекстное меню. В Google Chrome оно выглядит так:
Нам нужно просмотреть код. Нажимаем нижнюю строку и идем на вкладку Sources:
Теперь необходим инструмент Coverage. Чтобы добавить его в инспектор, в самом верхнем углу, кликаем по иконке белого крестика в красном круге:
Откроется инструмент просмотра ошибок. Здесь выбираем Coverage:
В самом низу мы получаем данные по коду, который не используется во время инициализации страницы (в нашем примере это 920 kB, что не смертельно).
4. Укажите правильные размеры для изображений и встраиваемых файлов.
Уже отмечалось, что если оценка CLS превышает 0,1 единицы, то это плохо. Значит у вас серьезный сдвиг элементов на странице: изображений, рекламных блоков, встраиваемых объектов.
Убедитесь, что у каждого элемента указана корректная ширина/высота. Иначе браузер не сможет гарантировать правильное выведение таких элементов после окончания их загрузки.
5. Реализуйте отложенную загрузку картинок
Вы в любом случае используете изображения на своем сайте. Попробуйте внедрить отложенную загрузку картинок.
Для этого обратитесь к веб-разработчику или изучите подробный гайд на «Хабре».
«Ленивая» загрузка позволяет загружать изображения в тот момент, когда пользователь прокручивает страницу вниз. Отложенная загрузка гарантирует наилучшую оценку LCP.
Другие преимущества отложенной загрузки изображений:
- улучшается производительность сайта;
- улучшаются SEO-страниц;
- снижается показатель отказов;
- улучшается метрика «Время на сайте»;
- дополнительное удержание посетителя на странице, ведь она загружается очень быстро и пользователь может сразу приступить к взаимодействию с контентом.
Таким образом, если на страницах вашего сайта много изображений/анимаций/видео, то отложенная загрузка — просто «мастхев».
Итог
Google обещал, что Core Web Vitals заработает в полную силу в начале сентября 2021 года. То есть проанализировать оценки Core Web Vitals при помощи PageSpeed Insights можно прямо сейчас. Если они неприемлемы, срочно займитесь работой над ошибками. Помните: серверная часть вашего сайта вплотную взаимодействует с пользовательской. Вот почему нужно максимально оптимизировать последнюю, а особенно — скорость загрузки страниц. Оценки Core Web Vitals станут неким камертоном, который позволит сравнить скорость загрузки вашего сайта с идеальной величиной.