Обновление Google за май 2021 года: более пристальный взгляд на Core Web Vitals

ОБНОВЛЕНИЕ: мир цифрового маркетинга постоянно меняется, но не волнуйтесь, мы на высоте. Google изменил свое мнение о грядущем алгоритме.

Прочтите последние изменения здесь, в нашем обновлении, но не стесняйтесь читать и этот блог.

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

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

Но Google не останавливается на достигнутом. Еще в мае 2020 года они рассказали нам о Core Web Vitals, а 10 ноября 2020 года объявили, что в мае 2021 года Core Web Vitals будет включен в качестве поискового сигнала в общий алгоритм ранжирования.

Кроме того, они планируют «протестировать визуальный индикатор, который выделяет страницы в результатах поиска, которые имеют хорошее восприятие страниц». Таким образом, у нас есть не только повышенные шансы на повышение рейтинга за счет оптимизации CWV, но и перспектива увеличения рейтинга кликов на страницах результатов поисковых систем.

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

Но сначала резюмируем ...

Резюме: что такое Core Web Vitals?

Core Web Vitals - это набор из трех новых показателей качества страницы, которые входят в общую оценку скорости сайта. Эти показатели уже играют заметную роль в инструменте Google PageSpeed ​​Insights PSI и мониторинге производительности Lighthouse в других местах.

Новые метрики CWV включают следующее:

Самая большая содержательная краска (LCP)

Это время, необходимое для отображения пользователю самого большого элемента над сгибом. На его долю приходится 25% общего механизма оценки скорости, поэтому жизненно важно упростить доставку самого крупного элемента до 2,5 секунд или меньше на мобильном устройстве.

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

Задержка первого входа (FID)

Это измеряет интерактивность; насколько страница реагирует на ввод данных пользователем, например, посредством касаний или щелчков мышью. Целевая скорость, с которой браузер реагирует на первый ввод, должна составлять 100 мс или меньше.

Если браузер анализирует или выполняет большой объем JavaScript во время загрузки страницы, это приведет к перегрузке ЦП или блокировке «Основного потока», в результате чего устройства станут менее реагировать на ввод. Высокий FID обычно свидетельствует о сложном JavaScript. Это может быть один сценарий или функция или несколько сценариев.

Существующие метрики PSI для времени до взаимодействия и общего времени блокировки связаны с FID и в совокупности составляют колоссальные 35% общих оценок скорости.

Накопительный сдвиг макета (CLS)

Это мера визуальной стабильности содержимого верхней части страницы. Хотя он составляет всего 5% от общей оценки скорости, его все же стоит учитывать в общей картине. Высокий уровень CLS часто может указывать на одно или несколько изменений визуального макета во время загрузки страницы, например, когда загружаются баннеры, смещающие содержимое страницы вниз.

Разбивка очков скорости

На диаграмме ниже показана разбивка общего показателя скорости и то, насколько большую роль эти новые показатели CWV играют в показателях GPSI.

Исходные данные из обновления рейтинга Lighthouse

В то время как показатели, не относящиеся к CWV, также формируют общую оценку, включая первую отрисовку контента (FCP), время до взаимодействия (TTI) и общее время блокировки (TBT), сосредоточение внимания на трех показателях CWV будет иметь прямое влияние на другие. Быстрый LCP невозможен, например, без быстрого FCP, а на высокие показатели FID напрямую влияют TBT и TTI.

Советы по оптимизации самой масштабной Contentful Paint

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

Если значение LCP намного выше, чем FCP, то нам нужно посмотреть, как мы можем лучше оптимизировать отображение этого самого большого элемента.

Определите самый большой элемент

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

В PSI в разделе «Диагностика» должна быть панель «Самый большой элемент Contentful Paint». Кроме того, вы можете просмотреть LCP, наведя курсор на индикатор в инструменте мониторинга производительности Chrome, как показано ниже.

На сайте Hallam в приведенном выше примере монитор производительности показывает LCP в качестве основного заголовка «Thrive Online». В идеале LCP должна немедленно следовать за FCP, как в этом примере, и если между ними есть разрыв, нам нужно попытаться понять, почему.

Оптимизированы ли шрифты?

Если самый большой элемент над сгибом - это типографика, то нам нужно убедиться, что доставка шрифта максимально упрощена. Это включает в себя:

1. Используйте CSS font-display: swap; чтобы гарантировать немедленное отображение шрифта во время загрузки файла шрифта. Как Google Fonts, так и Adobe Typekit имеют возможность устанавливать параметр «display» шрифта.
2. Попробуйте локально разместить файлы шрифтов .woff и .woff2 на сервере вместо того, чтобы делать междоменные запросы к сторонним шрифтам. Google Fonts работает довольно быстро, шрифты Typekit медленнее, а некоторые сторонние производители шрифтов могут быть менее надежными.
3. Предварительная загрузка файлов шрифтов может помочь. Локально размещенные шрифты часто включаются в основную таблицу стилей веб-сайта, но эта таблица стилей должна быть загружена и проанализирована до того, как будет сделан дополнительный запрос к шрифту внутри. Предварительная загрузка указывает браузеру начать загрузку шрифта раньше, не дожидаясь анализа CSS.
4. Используйте preconnect и dns-prefetch для сторонних производителей шрифтов. Эти директивы помогут установить DNS, TLS и TCP-соединения между сторонними доменами до того, как будет сделан запрос к шрифтам.
5. Включайте файлы шрифтов только для типографики, необходимой для отображения над складным изображением. Ресурсы шрифтов для библиотек значков, таких как Font Awesome, печально известны, но запросы к ним (и соответствующей библиотеке значков CSS) обычно можно отложить и загрузить после элемента <head>.
6. Не выполняйте междоменные запросы к файлам шрифтов в таблице стилей основного сайта, поскольку это зависит от возможности подключения и дополнительного поиска стороннего домена.
7. Подумайте о веб-шрифтах. Они не требуют никаких запросов к файлам шрифтов, хотя могут быть очень ограничены с точки зрения эстетики.

Оптимизированы ли изображения?

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

1. Используйте правильный тип файла изображения. Изображения JPG следует использовать для фотографий, SVG для векторной графики и значков или PNG для более сложных, нефотографических изображений и, если требуется прозрачность.
2. Убедитесь, что изображения JPG сохраняются или выводятся с качеством 50–60%. На этом уровне не должно быть заметной потери качества. Кроме того, убедитесь, что из изображений удалены метаданные.
3. Плагины или службы сжатия, такие как tinypng.com, могут автоматически и массово оптимизировать изображения и удалять ненужные метаданные.
4. Размер изображений должен соответствовать области, в которой они отображаются. Не выводите высококачественное изображение рабочего стола на мобильное устройство.
5. Изображения должны выводиться с использованием стандартного тега <img> с атрибутом srcset для адаптивных изображений.
6. Для изображений, расположенных ниже сгиба или за пределами экрана, следует использовать атрибут loading = "lazy".
7. Используйте формат файлов изображений следующего поколения .web для еще более высокого уровня сжатия. Это может легко сэкономить 30%, а во многих случаях намного больше.
8. Рассмотрите возможность предварительной загрузки самого большого изображения в верхней части страницы, чтобы начать загрузку быстрее, чем другой, потенциально менее важный контент.

Уменьшите количество файлов, блокирующих рендеринг

Любой файл JavaScript или CSS, загруженный в элемент <head> </head>, считается блокирующим рендеринг, поскольку эти файлы необходимо загрузить, прежде чем страница сможет начать рендеринг. Это может иметь огромное влияние как на показатели FCP, так и на LCP. Файлы с блокировкой рендеринга в заголовке следует использовать только в том случае, если они критичны для начального отображения над сгибом страницы.

Удаление любых неиспользуемых файлов в <head>, загрузка некритических файлов в нижний колонтитул или объединение нескольких файлов в меньшее количество файлов уменьшит количество ресурсов, блокирующих рендеринг.

Не используйте JavaScript для отображения LCP

До CWV это не было большой проблемой. Обычно JavaScript используется для анимации или отображения элементов над сгибом, например, с исчезающим текстом или каруселями героев, часто практически не влияя на показатели скорости.

Если отображение самого большого элемента зависит от JavaScript, это часто может вызвать длительную задержку, так как JavaScript должен быть загружен, проанализирован и выполнен до появления элемента. Файлы JavaScript обычно (и совершенно справедливо) загружаются после элемента <head>, поэтому они не «блокируют рендеринг», но это означает, что они по-прежнему могут эффективно блокировать рендеринг LCP.

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

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

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

Выполнение сценариев при загрузке окна

JavaScript редко требуется (и не должен быть обязательным) для отображения критически важного содержимого над сгибом, но общая проблема, которую мы видим, заключается в том, что функции могут запускаться, как только DOM будет готов. В популярном фреймворке jQuery это делается через событие «готово». Диспетчер тегов Google также может запускать функции или «теги» по готовности.

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

Включите LCP

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

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

Советы по оптимизации задержки первого входа

Как мы упоминали ранее, FID измеряет, насколько страница реагирует на ввод пользователя. Он сочетает в себе время до интерактивного TTI и общее время блокировки TBT, что может составлять до 35% общих оценок скорости.

На эти показатели в первую очередь влияет анализ и выполнение скриптов во время загрузки страницы; блокирует основной поток ЦП и потенциально влияет на скорость отклика устройства, особенно для смартфонов нижнего уровня.

Важно отметить, что «лабораторные данные», показанные в PSI, не измеряют FID напрямую. Это связано с интерактивным характером измерения касаний или щелчков пользователем, что трудно смоделировать. Вместо этого он собирается «Полевыми данными»; измерения, полученные от реальных пользователей за 28-дневный период на основе отчета Chrome User Experience Report CrUX.

Таким образом, оптимизация для FID напрямую немного сложнее, поскольку мы не можем что-то изменить и ждать 28 дней, пока не будут собраны дополнительные данные. Поэтому вместо этого мы должны использовать показатели TTI и TBT в лабораторных данных, поскольку низкие значения этих показателей будут коррелировать с низким FID.

Так как же нам оптимизировать эти показатели?

Проведите аудит вашего JavaScript

JavaScript может быть всех форм и размеров, и нередко одиночное встраивание видео, виджет чата, скрипт ReCaptcha или интеграция HubSpot являются единственной причиной высоких показателей FID, TTI и TBT.

Диагностические панели в Page Speed ​​Insights - хорошее место для начала. В разделе «Минимизация работы основного потока» будет указано, сколько времени на выполнение занимает JavaScript, в разделе «Уменьшить время выполнения JavaScript» будет указано, какие файлы имеют высокое время синтаксического анализа и выполнения, а также «Уменьшить влияние сторонних разработчиков. code 'выделит и сгруппирует высокоэффективные сторонние скрипты.

На снимке экрана ниже показан сайт, который страдает от наличия нескольких тяжелых скриптов с метрикой «Время до взаимодействия», равной 15 секундам. Многие скрипты предоставлены третьими сторонами, включая HubSpot и Vimeo.

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

Приведенный ниже пример взят с того же сайта и показывает JavaScript, представленный желтыми, розовыми и оранжевыми полосами, причем более длинные полосы показывают, что задачи выполняются дольше. Когда мы нажимаем на эти более длинные задачи, мы видим, что выделенные сценарии соотносятся с большими сценариями, выделенными PSI выше.

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

Загружать скрипты асинхронно

По умолчанию JavaScript выполняется последовательно. Если есть какие-либо сценарии, которые не зависят от загрузки других, эти сценарии должны быть загружены с атрибутом async, чтобы они не блокировали синтаксический анализ и выполнение других сценариев.

Условно загрузить JavaScript

Обычная проблема, которую мы видим на многих сайтах, заключается в том, что тяжелые скрипты загружаются глобально или на страницах, когда они не нужны. Если вам нужно использовать ReCaptcha, например, чтобы помочь остановить спам при отправке форм, убедитесь, что вы загружаете скрипты только на страницы, на которых есть формы.

Оптимизация пакетов JavaScript

Библиотеки JavaScript, такие как jQuery UI или Bootstrap, часто используются для предоставления дополнительных возможностей и функций JavaScript. При использовании пакета убедитесь, что в него включены только соответствующие функции, чтобы избавить ненужный JavaScript от загрузки и анализа.

Скрипты отложенной загрузки при необходимости

Даже если JavaScript загружается только на тех страницах, на которых он необходим, сам скрипт не обязательно должен анализировать и выполнять во время загрузки страницы или события загрузки окна. Загрузка JavaScript только тогда, когда это действительно необходимо, может существенно повлиять на показатели TTI, TBT и FID. Вот некоторые примеры:

1. Встраиваемые видео, такие как YouTube и Vimeo, обычно имеют большое влияние. Рассмотрите возможность загрузки этих сценариев только при нажатии на миниатюру видео.
2. Интеграция сторонних форм, таких как HubSpot, может быть интенсивной. Если форма отображается в модальном окне или внизу страницы, рассмотрите возможность загрузки или внедрения необходимого скрипта при прокрутке или модальной активации вместо загрузки страницы.
3. Виджеты живого чата могут влиять на общий показатель скорости до 35%. Подумайте о том, чтобы переместить виджет живого чата на специальную страницу контактов с поддержкой глобального призыва к действию «живого чата» или внедрить скрипт живого чата только при нажатии кнопки «чат с нами».
4. Добавление атрибута loading = "lazy" во встроенное содержимое на основе iFrame может помочь, но это новая функция браузера, которая требует тестирования в зависимости от используемого встроенного iFrame.

Оцените инструменты бизнес-аналитики

Анализ поведения пользователей с помощью таких инструментов, как Hotjar или программного обеспечения для A / B-тестирования, такого как VWO, действительно важен для бизнес-аналитики, и во многих случаях их преимущества перевешивают влияние на скорость сайта.

При этом все же стоит оценить важность использования этих инструментов в режиме 24/7 в зависимости от того, как часто данные анализируются. A / B-тестирование следует отключить, если, например, не запущены никакие активные тесты, а инструменты анализа поведения, такие как Hotjar, могут быть отключены после того, как будет собрано и обработано достаточное количество данных.

Советы по оптимизации кумулятивного сдвига макета

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

Определить элемент CLS

Иногда может показаться очевидным, какой элемент или элементы вызывают сдвиг в содержимом, но всегда стоит проверить это с помощью панели «Сдвиг макета» в PSI, как показано ниже.

Показатель CLS должен быть ниже 0,1, но в приведенном выше примере он превышен более чем на 400% и приведет к снижению оценок на 5%. Если это глобальная проблема, это 5% на каждой странице.

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

Остерегайтесь анимации

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

Если вам нужно скрыть, а затем скрыть содержимое для пользователя, убедитесь, что размер контейнера или общая высота страницы не изменяется по мере загрузки содержимого. Содержимое можно скрыть (при необходимости) с помощью правил видимости CSS, а не display: none; который сохранит необходимое ему пространство.

Укажите размеры изображения

Если для тега <img> не заданы атрибуты ширины и высоты, или CSS не используется для установки размеров или соотношения сторон изображения, браузеры должны будут сначала загрузить изображение, прежде чем они смогут определить область пикселей, которая ему необходима. отображать в. Это может вызвать сдвиг любого содержимого, отображаемого под изображением, по мере загрузки изображения.

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

Баннеры

Рекламные объявления, панели закона о файлах cookie или любая другая информация, используемая для отображения важной информации в баннере, вероятно, являются одной из наиболее распространенных причин высокого CLS.

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

На этот счет есть несколько решений:

1. Установите минимальную высоту баннера или контейнера баннера в CSS, чтобы браузер мог эффективно отображать заполнитель. Хотя это может быть проблематично, если объем контента динамический и неизвестный.
2. Абсолютно или зафиксируйте положение баннера вверху или внизу экрана. Для баннеров, которые можно закрыть или отклонить, это хорошее соображение, поскольку фиксированные элементы не повлияют на расположение других элементов.
3. Если возможно, посмотрите на рендеринг содержимого баннера на стороне сервера, что означает, что содержимое и размеры баннера могут быть загружены заранее, прежде чем они достигнут пользователя.

Резюме

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

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