Core web vitals что это

Core Web Vitals: скорость сайта превыше всего?

В мае 2020 года веб-мастеры, владельцы сайтов и seo-специалисты были взволнованы значительными колебаниями в Google: ряд сайтов потерял львиную долю своей видимости. Даже незначительное изменение в выдаче поисковой системы, с которой приходит примерно 67% органического трафика, может сильно повлиять на бизнес-показатели.

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

Что происходило с Google в 2020 году?

Запуск алгоритма Google запланировал на май 2021-го, чем обрадовал SEO-специалистов (есть время подготовиться), однако первые сильные колебания были отмечены еще в первой половине 2020-го.

С новыми доработками алгоритм вернулся в конце прошлого года, и, по наблюдению многих специалистов, декабрьское обновление было сильнее, чем майское. Изменения начали фиксироваться 3 декабря, а на полное развертывание алгоритма потребовалось две недели. 16 декабря Google объявил о завершении внедрений.

Колебания продолжили фиксироваться в январе. Среди тематик, которых обновление коснулось в большей степени, можно выделить “недвижимость” и “здравоохранение”. Прежде всего изменения затронули крупные и часто посещаемые сайты.

Что же такое Core Web Vitals?

Core Web Vitals (в буквальном переводе “основные веб-показатели”) – новый алгоритм от Google, который базируется на трех основных сигналах загрузки сайта:

• LСP (Largest Contentful Paint) – время загрузки самого большого элемента страницы. К нему может относиться как изображение или видео, так и блок текста.
• CLS (Cumulative Layout Shift) – время, за которое верстка сайта стабилизируется до корректного вида.
• FID (First Input Delay) – время до первого взаимодействия с контентом, от захода на сайт до полной его загрузки.

Как оценить соответствие сайта новому алгоритму?

Чтобы понять, соответствует ли сайт основным показателям, рекомендуем обратиться к сервисам:

• Page Speed Insight ;
• Google Search Console (вкладка “Удобство для мобильных” и “Основные интернет-показатели”);
• Lighthouse ;
• Расширение для браузера Chrome .

Каждый из инструментов поможет выявить проблемные моменты и точки роста для сайта. К примеру, в Google Search Console вы можете увидеть список страниц, которые требуют улучшения. Page Speed Insight по определенной странице покажет текущие показатели и возможный потенциал их роста. А с помощью расширения для браузера от Lighthouse есть возможность быстро оценить ситуацию по сайту, не используя сервисы анализа.

На что обратить внимание при анализе сайта?

У каждого сигнала есть свои пороговые и предельные значения, своего рода показатели качества страницы. Google рекомендует, чтобы сайт соответствовал следующим значениям:

• Largest Contentful Paint (LCP): загрузка считается хорошей, если длится до 2.5 сек. Если же она занимает более 4 секунд – это критический показатель, с которым обязательно нужно работать.
• Cumulative Layout Shift (CLS): необходимо стремиться ко времени до 0.1, более 0.25 – требует оптимизации.
• First Input Delay (FID): показатель до 100 мс считается оптимальным, более 300 мс – срочный пункт в списке для доработки.

При оптимизации сайта в соответствии с требованиями алгоритма не стоит забывать и о пользовательских факторах, таких как:

• Оптимизация сайта под мобильные устройства.
• Проблемы с наличием блоков с навязчивой рекламой.
• Проблемы безопасности сайта (вредоносное ПО) и пользовательских данных (наличие и корректная настройка https).

Что делать в SEO? Несколько очевидных, но важных советов

• Провести аудит страниц сайта с помощью Google Search Console. Это позволит выявить медленные страницы.
• Проанализировать проблемные страницы через сервисы Page Speed Insights, Lighthouse и т.д.
• По рекомендациям сервисов оптимизировать показатели для достижения “зеленой зоны” или хотя бы приближения к ней.

Как оптимизировать показатели?

• Уменьшить размер видео и изображений без потери качества – это оптимизирует показатель LCP.
• Использовать предзагрузку больших элементов, которые также повлияют на LCP.
• Оптимизировать код или разделить большие скрипты на более мелкие, т. е. улучшит показатель FID.
• Использовать CDN – сеть доставки контента, обеспечивающую загрузку сайта с наиболее близкого сервера – для ускорения работы сайта.
• Включить кэширование браузера – это ускорит повторную загрузку страниц.

Время = деньги. Для чего нужно работать со скоростью загрузки?

Сегодня медленный или неработающий сайт может привести к серьезным последствиям: пользователь, не дождавшись полной загрузки, просто уйдет с сайта и не совершит покупку. А если таких пользователей не один, а тысячи?

Вот несколько фактов и примеров:

• Почти 70% потребителей признают, что скорость загрузки страниц влияет на их готовность к покупке на сайте.
• Исследования Google показали: если сайт будет соответствовать пороговым значениям Core Web Vitals, то вероятность покинуть пользователем страницу до ее загрузки снижается на 24%.
• У большинства посетителей психологический порог готовности ждать загрузку сайта – 2 секунды.
• Walmart улучшил конверсию сайта на 2%, увеличив скорость на 1 секунду.
• DoubleClick от Google отметил, что рекламодатели, чьи мобильные сайты загружаются за 5 секунд, получают в 2 раза больше дохода от мобильной рекламы, чем сайты, загружаемые за 19 секунд.

Что в итоге?

Новый алгоритм касается не только скорости загрузки, но и удобства для пользователей. Еще 10 лет назад сайты были значительно проще, без большого количества видео, “тяжелых” изображений и других “фичей”. Теперь же в погоне за разнообразием контента многие забывают о немаловажном факторе – скорости загрузки страницы. А нетерпеливость пользователей и неготовность ждать более 2 секунд могут привести к потере продаж.

Именно поэтому владельцы сайтов и seo-специалисты должны быть готовы к оценке сайта по скорости загрузки, идти в ногу со временем и навстречу своим пользователям. Оптимизируйте показатели, следите за их изменением и стремитесь всегда находиться в “зеленой зоне”.

Основные сведения о показателях Core Web Vitals и результатах поиска Google

Удобство оценивается по показателям Core Web Vitals, таким как скорость загрузки, интерактивность и визуальная стабильность. Мы настоятельно рекомендуем владельцам сайтов следить за показателями Core Web Vitals. Это не только обеспечивает успех в работе с Поиском, но и в целом повышает удобство страницы. Эти, а также и другие показатели взаимодействия со страницей отражают, какие страницы поощряют наши основные системы ранжирования. Более подробные сведения доступны в разделе Анализ удобства страницы в результатах Google Поиска.

Обновление от 20 мая 2023 г.: В марте 2024 г. в Core Web Vitals вместо показателя FID начнет использоваться Interaction to Next Paint.

Показатели Core Web Vitals

• Отрисовка самого крупного контента (LCP). Этот параметр отражает скорость загрузки. Чтобы страницей было удобно пользоваться, это значение должно составлять менее 2,5 сек. с начала скачивания страницы.
• Задержка после первого ввода (FID). Этот параметр отражает интерактивность. Чтобы сайтом было удобно пользоваться, значение FID должно составлять менее 100 мс. В марте 2024 г. показатель Interaction to Next Paint (INP) заменит FID в Core Web Vitals.
• Cumulative Layout Shift (CLS) отражает визуальную стабильность. Чтобы страницей было удобно пользоваться, значение CLS должно составлять менее 0,1.

Как улучшить показатели Core Web Vitals

По ссылкам ниже представлена информация, которая поможет вам оценивать и повышать показатели Core Web Vitals.

• Проверьте значения показателей в отчете Core Web в Search Console. Эти значения отражают эффективность работы страницы.
• Подробнее о показателях Core Web Vitals, а также о том, как их измерить и отладить, рассказано в руководстве по Core Web Vitals. Там же приводятся примеры практического использования этих показателей.
• Узнайте, как с помощью различных инструментов измерять основные интернет-показатели и создавать отчеты по ним (это показатели LCP, FID и CLS).

Недавние изменения

Ниже перечислены последние изменения, связанные с удобством страниц, о которых мы рассказывали в нашем блоге в Центре Google Поиска:

Отправить отзыв

Если не указано иное, контент на этой странице предоставляется по лицензии Creative Commons «С указанием авторства 4.0», а примеры кода – по лицензии Apache 2.0. Подробнее об этом написано в правилах сайта. Java – это зарегистрированный товарный знак корпорации Oracle и ее аффилированных лиц.

Последнее обновление: 2023-12-04 UTC.

Все о Core Web Vitals: как улучшить ранжирование сайта

Что такое Core Web Vitals? Как они связаны с SEO? Почему их важно регулярно измерять и в каких сервисах это можно сделать? Специалисты Альтеры ответили на эти вопросы в новой статье, — а также составили список из 14 конкретных шагов для улучшения CWV.

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

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

Важность Core Web Vitals для SEO

Google объявил, что будет использовать эти показатели как часть своего алгоритма ранжирования в поиске, начиная с 2021 года. Вот несколько тому подтверждений:

• Филип Уолтон, инженер Google, работающий над веб-производительностью, сказал, что метрики Core Web Vitals являются небинарным фактором ранжирования (фактор ранжирования не имеет какого-то конкретного значения).
• Джон Мюллер, эксперт Google, подтвердил, что Core Web Vitals влияют на ранжирование. Однако, по его словам, релевантность играет более важную роль. Если сайт А быстрее, чем сайт Б, но Б более релевантен запросу пользователей, сайт Б все равно будет выше сайта А.
• Мюллер также отметил, что сайты, переходящие из категории «требует улучшения» в категорию «хорошо», могут увидеть улучшения в ранжировании. Но веб-сайты, которые уже хороши и улучшают свою скорость на миллисекунду или две, вряд ли почувствуют изменения в рейтинге.

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

Кроме того, Патрик Стокс (технический SEO-специалист и амбассадор бренда в Ahrefs) привел ряд интересных фактов, которые, на наш взгляд, стоит учитывать при принятии решения об оптимизации CWV:

• Показатели разделены на десктопы и мобильные устройства, и влияют на ранжирование в мобильной и десктопной выдаче по отдельности (если вы ориентируетесь на пользователей мобильных устройств, то в первую очередь стоит улучшать их показатели).
• Есть своя особенность оценки: метрики оцениваются по 75-му процентилю пользователей. Если у 70% пользователей хорошие показатели, а у 5% «нуждаются в улучшении», то страница будет оценена как «нуждается в улучшении».
• Заметили, что отчеты нередко выдают данные, которые не соответствуют действительности (возможно, это следствие предыдущего пункта).
• Core Web Vitals не совсем корректно оценивает показатели для Single Page Application (тип веб-приложения, которое загружает одну HTML-страницу и динамически изменяет ее на основе действий пользователя).

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

Важно не быть самым быстрым, важнее быть не самым медленным.

Как измерить CWV: полевые и лабораторные данные

Google предоставляет ряд инструментов, помогающих владельцам сайтов отслеживать свои Core Web Vitals. Для измерения показателей используются данные, собранные от реальных пользователей (полевые данные), и информация, полученная в лабораторных условиях (синтетические данные).

Полевые данные

Полевые данные в Core Web Vitals относятся к показателям производительности, собранным от реальных пользователей, в отличие от синтетического тестирования в контролируемой среде (имитация реальных условий работы и нагрузок).

Полевые данные собираются с помощью отчета о пользовательском опыте Chrome (CrUX) — общедоступного набора данных, объединяющего реальные показатели производительности пользователей из браузера Chrome.

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

Лабораторные данные

Лабораторные данные в Core Web Vitals относятся к показателям производительности, собранным в контролируемой среде, например, с использованием инструментов разработчика или специализированного программного обеспечения для тестирования с целью имитации работы пользователя на сайте. Для сбора информации можно применять Lighthouse или PageSpeed Insights — сервисы для имитации работы пользователя и проверки производительности сайта в искусственных условиях.

С помощью лабораторных данных разработчики могут тестировать производительность сайта, например, при быстром или медленном сетевом подключении. Это позволит выявить и устранить такие проблемы, как длительные задачи JavaScript или ресурсы, блокирующие отрисовку.

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

Метрики Core Web Vitals

Core Web Vitals могут измениться со временем. На сегодняшний день важно измерять несколько показателей, о которых расскажем ниже.

Largest Contentful Paint (LCP)

Скорость загрузки основного контента (Largest Contentful Paint, LCP) – это время от начала загрузки страницы до отрисовки элемента, содержащего самый большой контент: блока с текстом или изображения в зоне браузера, которую видит пользователь.

Метрика измеряет воспринимаемую скорость загрузки. Чем быстрее пользователь получит содержимое страницы, тем быстрее сможет убедиться в ее полезности.

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

Пример: Самый большой элемент может изменяться по мере загрузки страницы. В начале загрузки страницы им может быть заголовок H1, но после него загружается изображение. Если изображение крупнее заголовка, то оно становится основным контентом.

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

Как оценивается LCP

• Хорошо: менее 2,5 секунд
• Требуется улучшение: от 2,5 секунд до 4 секунд
• Плохо: более 4 секунд

First input delay (FID)

Время задержки до первого взаимодействия (First input delay, FID) – это время от первого взаимодействия пользователя с сайтом до реакции браузера на него. Метрика учитывает такие действия как клик мышью, касания, нажатия клавиш и не учитывает другие события, например, скролл или изменение масштаба. Целью метрики является измерение интерактивности и отзывчивости страницы.

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

FID измеряется только на основе данных, полученных от реальных пользователей, поскольку эта метрика напрямую зависит от взаимодействия.

Для тестирования в лаборатории используется метрика «Общее время блокировки» (TBT), так как она тесно связана с задержкой первого ввода.

Как оценивается FID

• Хорошо: менее 100 мс
• Требуется улучшение: от 100 мс до 300 мс
• Плохо: более 300 мс

Cumulative Layout Shift (CLS)

Совокупное смещение макета (Cumulative Layout Shift, CLS) – это метрика для измерения «визуальной стабильности» страницы. Она оценивает непредвиденные смещения в макете в области видимости пользователя в течение всей жизни страницы.

«Визуальная стабильность» страницы сильно влияет на взаимодействие с пользователем. Каждый сталкивался с ситуацией, когда при просмотре веб-страницы на ней внезапно что-то менялось: смещался текст, резко появлялись баннеры и тому подобное. Гораздо хуже, когда внезапно смещаются кнопки в пользовательском интерфейсе. Летающие элементы раздражают и повышают вероятность закрытия страницы. Чем ниже показатель CLS, тем лучше визуальная стабильность.

Для оценки смещения берется размер области просмотра и оценивается перемещение элементов в рамках этой области за определенный временной промежуток (время рендеринга страницы).

Как оценивается CLS

• Хорошо: менее 0,1
• Требуется улучшение: от 0,1 до 0,25
• Плохо: более 0,25

Дополнительные показатели производительности

Помимо трех вышеперечисленных показателей, для удобства пользователей также необходимо учитывать дополнительные факторы. К ним относятся первая отрисовка контента (FCP), индекс скорости (SI), общее время блокировки (TBT) и время до взаимодействия (TTI). Данные показатели помогают зафиксировать большую часть процесса взаимодействия со страницей и диагностировать конкретную проблему.

First Contentful Paint (FCP)

Первая отрисовка контента — это способ измерения скорости загрузки страницы. FCP измеряет разницу во времени между запросом страницы и моментом, когда первый значимый контентный элемент отображается на экране в первый раз. Метрика ориентирована на пользователя, поскольку показывает скорость загрузки, с которой сталкивается посетитель.

Как устроен FCP

• «First» — подразумевается момент, когда в браузере появляется что-то существенное.
• «Contentful» — имеется в виду HTML-элемент с содержимым. То есть это не часть макета, такой как пустой элемент или цвет фона, а текст, изображение (включая фоновое изображение), SVG или холст.
• «Paint» – означает, что браузер готов вывести контент на экран. Звучит легко, но на самом деле это самая сложная задача для браузера, ведь для этого он должен быть готов вычислить все характеристики элемента.

FCP измеряется путем сбора данных от реальных пользователей. FCP также можно измерить с помощью лабораторных тестов (Lighthouse).

Как оценивается FCP

• Хорошо: менее 1,8 секунд
• Требуется улучшение: от 1,8 до 3 секунд
• Плохо: более 3 секунд

Speed Index

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

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

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

Как оценивается SI

• Хорошо: от 0 до 3,4 секунды
• Требуется улучшение: от 3,4 до 5,8 секунд
• Плохо: более 5,8 секунд

Time To Interactive (TTI)

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

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

Когда страница становится «интерактивной»:

• На странице отображается полезный контент для пользователя (измеряется с помощью First Contentful Paint).
• Отображены наиболее заметные элементы страницы (обработчики событий регистрируются для наиболее видимых элементов).
• Время отклика на взаимодействие с пользователем составляет не более 50 миллисекунд.

Как оценивается TTI

• Хорошо: менее 3,8 секунд
• Требуется улучшение: от 3,8 до 7,3 секунд
• Плохо: более 7,3 секунд

Total Blocking Time (TBT)

Общее время блокировки (TBT) — это показатель, который измеряет общее время между первой отрисовкой контента (FCP) и временем до взаимодействия (TTI), когда основной поток блокируется достаточно долго, чтобы сделать его невосприимчивым к пользовательскому вводу.

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

Основной поток браузера выполняет несколько задач во время рендеринга веб-страницы, включая такие важные задачи, как синтаксический анализ HTML, построение DOM, выполнение кода JavaScript и CSS, сборка мусора, обработка событий и другие. Основной поток считается «заблокированным» каждый раз, когда возникает длительная задача, на выполнение которой уходит более 50 мс.

TBT рассчитывается как сумма блокирующей части всех длинных задач. Например, если есть три длинных задачи:

• Задача A занимает 75 мс (на 25 мс дольше, чем 50 мс)
• Задача B занимает 60 мс (на 10 мс больше, чем 50 мс)
• Задача C занимает 85 мс (на 35 мс дольше, чем 50 мс)

Тогда TBT составляет: 70 мс (25+10+35). Чем ниже TBT, тем лучше.

Как оценивается TBT

• Хорошо: менее 200 мс
• Требуется улучшение: от 200 мс до 600 мс
• Плохо: более 600 мс

Как улучшить Core Web Vitals

Оптимизация Core Web Vitals может помочь улучшить пользовательский опыт и ранжирование сайта.

Чтобы увидеть, насколько хорошо ваш веб-сайт работает с точки зрения основных Core Web Vitals, используйте программы для анализа производительности: сервисы от Google, такие как Search Console и Pagespeed Insights, а также другие инструменты, например GTmetrix.

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

1. Оптимизировать изображения на сайте

Это самая распространенная проблема на любом сайте, и при этом ее легче всего исправить — с помощью оптимизации изображений.

• Сжать изображения
• Заменить анимированные GIF-файлы на видео
• Использовать форматы изображений нового поколения, например WebP

С помощью этих правок можно уменьшить время загрузки и улучшить показатель LCP.

2. Настроить ленивую загрузку изображений

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

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

Важно! Первые элементы сайта должны быть без использования lazy load.

3. Использовать CDN для изображений и других ресурсов

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

Выбирая CDN, вы должны правильно выбрать расположение серверов.

Представим, что большая часть аудитории сайта из Европы. Чтобы воспользоваться преимуществами CDN и сократить время загрузки (и ваш LCP) для европейских пользователей, один или несколько серверов должны быть географически расположены в одной из европейских стран.

4. Улучшить производительность сервера

Устройство, на котором размещается сайт, является сервером. И если оно работает медленно, сайту потребуется время для обработки информации и возврата страницы пользователю.

Бесплатные или дешевые провайдеры предлагают переполненные сервера с низкой производительностью. Рекомендуется пользоваться услугами проверенных хостинг-провайдеров: у них всегда можно обновить тарифный план и подобрать оптимальный размер жесткого диска и оперативной памяти.

5. Использовать разные изображения для десктопов и мобильных устройств

Можно создавать варианты одного и того же изображения и указывать их в HTML-коде. Таким образом, в зависимости от размера экрана будет отображаться изображение нужного размера.

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

6. Устранить ресурсы, блокирующие рендеринг

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

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

7. Удалить неиспользуемые CSS и JS

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

В работы по оптимизации входит: удаление неиспользуемых фрагментов javascript и CSS, разделение существующих файлов javascript и CSS на отдельные файлы и настройка их загрузки по мере необходимости.

8. Настроить сжатие ресурсов на стороне сервера

GNU zip, более известна как GZIP, является программой сжатия без потерь. После реализации сжатия GZIP вы можете увидеть заметное увеличение скорости страницы.

С помощью Lighthouse можно обнаружить файлы без кодировки содержимого, такие как br, gzip или deflate. Их рекомендуется сжать. Сжатие ресурсов на стороне сервера улучшит FCP.

9. Минифицировать CSS и JS

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

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

10. Добавить атрибуты размера к изображениям и видео

Включите размер атрибута изображения в HTML. Такой подход гарантирует, что браузер сможет выделить нужное количество места в документе во время загрузки изображений. Некоторое место уже отведено под изображения, что позволяет избежать визуального сдвига. Это гарантирует улучшение CLS.

11. Уменьшить конечный размер страниц

В целом хорошей практикой для разработки веб-сайта и повышения его производительности является сохранение небольшого размера страницы.

Уменьшите размер каждой страницы до 500 КБ (страница + все ресурсы) и сократите общее количество ресурсов на странице до 50 (идеально для мобильных устройств).

12. Оптимизировать шрифты

Шрифты сайта загружаются браузерами так же, как и изображения. Веб-шрифты могут быть довольно тяжелыми и занимать драгоценное время при загрузке страницы. Когда-нибудь замечали, что веб-страница загружается, а потом вдруг «сдвигается вверх»? Когда это происходит, шрифт загружается должным образом, изменяя общий макет страницы. Это серьезное нарушение, влияющее на совокупную оценку смещения макета.

Есть два простых шага, чтобы убедиться, что веб-шрифты оптимизированы:

• Используйте только те шрифты, которые вам нужны.
• Когда вы создаете веб-страницу, не используйте много разных шрифтов.

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

13. Минимизировать количество сторонних скриптов

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

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

Совет: Попробуйте подгружать сторонние скрипты через диспетчер тегов Google (Google Tag Manager). Тесты показывают, что использование GTM для загрузки может немного улучшить показатели производительности, если сравнивать с добавлением кода непосредственно на страницы сайта.

14. Настроить статическое кэширование

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

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

Это также позволяет значительно ускорить общую скорость сайта.

Заключение

Оптимизация сайта — это бесконечная история.

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

Использование инструментов аналитики, таких как Google Search Console, Google Analytics, Lighthouse, GTmetrix и других может помочь вам определить проблемы и устранить их. Важно понимать, что оптимизация сайта — это не единоразовое действие, а постоянный процесс. Необходимо регулярно проверять свой веб-сайт и обязательно включать анализ производительности в свой рабочий процесс.

Подписывайтесь на наш Телеграм — еженедельно мы публикуем статьи про SEO-продвижение, онлайн-маркетинг, контекстную рекламу, новости отрасли и многое другое.

Core Web Vitals и новая метрика INP: ускорение сайта актуальными методами

Поисковик анализирует удобство страницы для пользователей. Для этого у него есть Page Experience — набор требований к сайту для оценки пользовательского опыта и качества страницы. В него входит мобилопригодность, наличие HTTPS, отсутствие навязчивых поп-апов, быстрая загрузка.

Google не просто измеряет скорость, а отдельно оценивает этапы загрузки. Для измерения он использует набор показателей — Core Web Vitals.

В Google Core Web Vitals входят три основных параметра:

• Время отрисовки контента
  LCP, Largest Contentful Paint — время, за которое браузер отрисовывает самый крупный видимый объект в области просмотра.
• Отзывчивость или интерактивность
  FID, First Input Delay — время между первым взаимодействием пользователя со страницей и ответом браузера.
• Визуальная стабильность
  CLS, Cumulative Layout Shift — оценка сдвигов макета во время загрузки страницы.

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

Можно ли считать Core Web Vitals фактором ранжирования? Скорее это сигнал для поисковой системы, но вряд ли сайт упадет в выдаче из-за проблем с каким-то из показателей. Например, на Reddit пользователь спросил, может ли снижение органического трафика быть связано с плохим CLS. Джон Мюллер ответил, что нет.

Новый показатель INP

INP (Interaction to Next Paint) — взаимодействие со следующей отрисовкой. В марте 2024 года этот показатель заменит FID. Метрика анализирует все задержки, которые происходят от открытия до закрытия страницы, и фиксирует самую длинную.

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

Разница между INP и FID в том, что новая метрика измеряет все взаимодействия, тогда как FID учитывает только первое.

Как рассчитывается INP?

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

Взаимодействие — это группа обработчиков событий, которые реагируют на действия пользователя. Какие взаимодействия со страницей учитывает метрика:

• Клик мышью;
• Нажатие на устройство с сенсорным экраном;
• Нажатие клавиши на физической или цифровой клавиатуре, в том числе и прокрутка.

Прокрутка мышью или движение мыши не считаются взаимодействиями.

Взаимодействия состоят из событий. Например, взаимодействие «касание» на устройстве с тачпадом подразумевает три события: pointerup , pointerdown и click. Задержкой будет считаться самая большая продолжительность любого события, которое входит в взаимодействие.

Продолжительность самого события состоит из суммы периодов:

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

Больше о событиях можно прочитать в справке Google.

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

INP может меняться в зависимости от интерактивности страницы. Например, если на странице всего менее 50 взаимодействий, INP — это взаимодействие с наибольшей задержкой. Будет учитываться 75-й процентиль всех просмотров страниц, чтобы не учитывать выбросы.

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

Какой INP считается хорошим?

Порогом для измерения считается 75-й процентиль загрузок страниц, зарегистрированных в полевых условиях, то есть сегментированных по мобильным устройствам и компьютерам:

• 200 миллисекунд и ниже означает, что у страницы хорошая скорость отклика
• От 200 до 500 миллисекунд означает, что скорость отклика нужно увеличить;
• Выше 500 миллисекунд — страница реагирует плохо.

Почему INP не отображается?

Тот факт, что страница загружена, не означает, что пользователь взаимодействовал с ней. Почему это может произойти:

• Пользователь загрузил страницу, но не взаимодействовал с ней;
• Пользователь загрузил страницу, пролистал ее, но ни на что не кликал;
• Страницу посетил бот, который не взаимодействовал с ней.

О том, как улучшить INP, читайте в руководстве на web.dev.

Как проверить скорость и этапы загрузки страницы

Есть онлайн-инструменты для проверки. Прогоните сайт через бесплатный инструмент для проверки скорости от PR-CY: он бесплатно проанализирует загрузку сайта поэтапно, в соответствии с параметрами Google Core Web Vitals. Работает на API Google.

Для каждого пункта есть пояснения и советы, что можно улучшить, с примерным подсчетом экономии скорости при выполнении.

Инструменты от Google для оценки LCP, FID и CLS

• Оценка основных веб-жизненных показателей PageSpeed ​​Insights;
• Вкладка «Производительность» в Chrome DevTools;
• Отчет в GSC;
• Расширение Chrome Core Web Vitals.

Google PageSpeed ​​Insights

Google PageSpeed ​​Insights проводит комплексный анализ производительности страницы, включая показатели Core Web Vitals — первый блок отчета показывает именно их.

Эта оценка входит в отчет о полевых данных. Полевые данные содержатся в отчете об опыте пользователей Chrome — CrUX. Эта информация собирается от реальных пользователей и основана на их взаимодействиях с сайтом. При ранжировании в поиске Google будет использовать именно эти результаты.

Есть два способа получить данные CrUX:

• API отчетов Chrome UX – нужен опыт с JavaScript и JSON;
• BigQuery – понадобится проект Google Cloud и навыки SQL.

Вкладка «Производительность» в Chrome DevTools

Отчет показывает детальную информацию о производительности страницы и диагностировать проблемы.

Как посмотреть отчет:

1. Откройте в Google Chrome сайт, который хотите проверить, и щелкните правой кнопкой мыши в любом месте страницы. Выберите «Проверить» или «Inspect» в меню, чтобы открыть панель Chrome DevTools.
2. На панели DevTools перейдите на вкладку «Производительность» или «Performance».
3. Нажмите кнопку «Запись» в виде кружка, чтобы начать запись профиля производительности страницы;
4. Взаимодействуйте с веб-сайтом, как обычный пользователь — кликайте по элементам страницы, открывайте формы, листайте;
5. Нажмите кнопку «Стоп»;
6. На вкладке «Производительность» будет отображаться подробная временная шкала действий на странице во время сеанса записи.

В результате проверки вы увидите временную шкалу, отображающую ваши действия. Показатели LCP, FID и CLS будут отображены на ней же. Для дополнительной информации каждую метрику можно развернуть.

Отчеты в Google Search Console (GSC)

В разделе «Основные интернет-показатели» есть два отчета по скорости сайта — для компьютеров и для мобильных устройств.

Они покажут количество эффективных и неэффективных страниц. Каждый отчет можно посмотреть подробнее — вы найдете наименование проблемы и список страниц, которые нужно улучшить.

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

Если вы улучшили страницы, нажмите «Проверить исправление»:

Расширение Chrome Core Web Vitals

Для быстрой проверки основных веб-показателей вы можете использовать это расширение Chrome, оно проверит LCP, CLS и FID и покажет краткую сводку.

Как оптимизировать показатели Core Web Vitals

Разберем каждый параметр по отдельности.

LCP: как ускорить отрисовку контента

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

Самым большим элементом могут быть разные части страницы, появляющиеся по мере загрузки. В этом примере таким элементом сначала был заголовок, а потом стала картинка.

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

На LCP влияют четыре фактора, их можно оптимизировать:

• ускорить время ответа сервера;
• решить блокировку рендеринга JavaScript и CSS;
• ускорить загрузку ресурсов;
• оптимизировать рендеринг на стороне клиента.

Как поработать над каждым из пунктов, подробно разобрали в статье про LCP.

FID: как ускорить время реакции страницы

Показатель оценивает, насколько страница задержалась с ответом на первое действие пользователя. К примеру, на странице появилось изображение, на которое пользователь кликнул, чтобы открыть картинку целиком. Картинка должна открыться сразу после клика. FID измеряет, насколько она задержалась.

Чем меньше времени тратится, тем лучше. Оптимальный показатель FID — не дольше 100 миллисекунд.

Для ускорения реакций страницы есть несколько решений:

• сократить время выполнения JavaScript;
• разбить длинные задачи на части;
• отложить неиспользуемый JavaScript;
• следить за размером подгружаемых библиотек JavaScript;
• оптимизировать выполнение сторонних скриптов;
• использовать web-workers

Как выполнить каждый из пунктов, написали в подробной статье про FID.

CLS: как убрать сдвиги макета страницы

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

Из-за сместившихся кнопок пользователь промахнулся

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

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

Для вычисления нужны два компонента:

• общая область на экране, которую занимает элемент до и после сдвига;
• расстояние, на которое он сдвинулся.

Оптимальный показатель CLS —не больше 0,1 на 75% сессий.

В статье про CLS подробнее разбираем, как это работает и что делать для оптимизации.

Что еще влияет на загрузку страницы: оптимизируем CSS

Стили страницы влияют на скорость отрисовки самого большого видимого элемента и визуальные сдвиги макета.

Например, блокировка рендеринга при обработке CSS тормозит загрузку остальных ресурсов на странице. Чтобы такого не происходило, можно ускорить процесс и разделить CSS на критические и некритические для выполнения.

Для сравнения на верхней строчке загрузка страницы с блокирующими рендеринг CSS, на нижней с разделением CSS:

Кроме критических и некритических CSS можно поработать со стилями изображений, рекламой, скриптами, фреймами и шрифтами.

Все эти возможности разобрали в отдельном материале.

Как уменьшить вес страниц сайта и ускорить загрузку

Другие возможности повлиять на скорость.

Как оптимизировать код верхней части страницы

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

Есть несколько методов:

• удалить лишние символы и скрипты из верхней части кода;
• настроить асинхронную загрузку с jQuery;
• ускорить получение первых байтов (TTFB);
• объединить и сократить JavaScript и CSS;
• настроить загрузку из кэша на стороне пользователя;
• использовать CDN.

О каждом методе с примерами есть в статье.

Как внедрить gzip, brotli, использовать кэширование, минификацию и другие способы сжатия

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

Способы ускорить загрузку:

• уменьшить размер HTML;
• использовать сжатие gzip или brotli;
• использовать минификацию, то есть сократить HTML, CSS и JS;
• использовать кэш браузера для ускорения;
• сжать фотографии, иллюстрации и другую графику: подобрать разрешение, уменьшить количество цветов, прописать параметры в CSS и сжать сами файлы.

К примеру, при уменьшении количества цветов качество этой картинки почти не страдает, зато сильно уменьшается вес. Слева направо: 32 бита (16M цветов), 7 бит (128 цветов), 5 бит (32 цвета).

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

Все способы разбираем в подробной статье.

Что используют самые быстрые страницы интернета: исследование 5,2 млн страниц

Команда блога Backlinko во главе с Брайаном Дином провели исследование страниц из выдачи Google и проверили, какие способы ускорения используют самые быстрые страницы. В выборке было 5,2 млн страниц из десктопной и мобильной выдачи, так что результат стоит посмотреть.

• Общая скорость загрузки
• Как CDN влияет на скорость загрузки
• Какие фреймворки самые быстрые
• Как сжатие файлов влияет на скорость
• Какое сжатие изображений эффективнее ускоряет загрузку
• Сайты на каких CMS грузятся быстрее

Несколько интересных тезисов:

1. Средняя скорость загрузки первого байта (TTFB) — 1,286 секунды на десктопе и 2,594 секунды на смартфоне. Среднее время полной загрузки страницы — 10,3 секунды на десктопе и 27,3 секунды на мобильном.
2. Как ни странно, лучшие варианты — либо минимально сжать файлы перед отправкой с сервера, либо максимально. У таких страниц более высокая производительность по сравнению со средним уровнем сжатия.
3. Для загрузки на десктопе на скорость сильнее влияет использование CDN, на мобильных — количество запросов HTML.
4. Если сравнивать разные способы оптимизировать картинки, использование адаптивных изображенийвыходитна первое место.

Больше интересного в переводе выводов исследования.

Как оптимизировать и сжать картинки

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

Как сжимать картинки и заполнять SEO-атрибуты

Изображения много весят и сильно влияют на загрузку сайта. Чтобы они не сильно замедляли загрузку и приносили пользу в SEO, нужно учитывать эти факторы:

• количество картинок на странице, размеры, уникальность, тематика;
• правильная оптимизация;
• правильное заполнение SEO-атрибутов изображений.

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

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

Не стоит использовать тег picture для настройки разных форматов картинок для разных устройств. Это увеличит количество узлов в DOM-дереве.

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

Большая часть советов основана на вебинаре специалиста технического SEO и реверс инжиниринга Деми Мурыча (Demi Murych). Речь не только о сжатии и уменьшении веса, но и о требованиях по размерам, качеству, уникальности и актуальные советы по заполнению метатегов.

Как настроить отложенную загрузку картинок — lazy loading изображений

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

Есть несколько вариантов настройки:

1. Пока пользователь скролит: когда он дойдет до места, где должна быть картинка, она загрузится.
2. Когда пользователь кликнет на элемент: картинка загрузится, если он перейдет по ссылке или щелкнет на превью.
3. В фоновом режиме: контент будет загружаться постепенно, например, когда пользователь открыл документ и оставил его. Обычно применяют для больших чертежей и схем.

Картинки загружаются по мере просмотра:

Выбор варианта зависит от поведения пользователей на сайте.

В статье разбираем, так ли нужна ленивая загрузка, и как ее настроить правильно.

Нужно ли использовать формат изображений WebP

WebP — это формат графических изображений, его разработали в Google в 2010 году. Получилась альтернатива PNG и JPEG, но с меньшим размером при таком же качестве изображения. При этом в WebP можно сохранить прозрачность фона или анимацию.

Формат выгоднее с точки зрения ускорения загрузки сайта, но не все браузеры его поддерживают.

В статье мы собрали все самое важное о формате WebP: исследования качества и веса, достоинства и недостатки формата, поддержку браузерами, способы конвертирования и другие темы.

Эти материалы позволят разобраться с оптимизацией страниц, чтобы ускорить загрузку и привести показатели Core Web Vitals в норму. Как вы ускоряете сайт, какие способы используете? Поделитесь в комментариях!