Что такое Core Web Vitals и как увеличить скорость загрузки страниц
Скорость загрузки страниц является важным фактором ранжирования сайтов в поисковых системах. При поисковом продвижении сайта необходимо уделить особое внимание анализу скорости загрузки страниц.
Core Web Vitals — это группа факторов ранжирования поисковой системы Google, которые были запущены в работу в мае 2021 года.
Что такое Core Web Vitals
Core Web Vitals – это метрики алгоритма Web Vitals, которые используются для оценки веб-страниц. Метрики Core Web Vitals включены во все инструменты Google.
Чтобы сайты высоко ранжировались в поисковых системах, необходимо учитывать данные метрики при оптимизации сайта. Данные метрики влияют на поведение пользователей.
Core Web Vitals — это группа факторов ранжирования поисковой системы Google, которые были запущены в работу в мае 2021 года.
Параметры метрики Core Web Vitals
LCP (Largest Contentful Paint) — скорость загрузки основного контента веб-страницы. Основной контент — это самый большой элемент на странице: текст, видео, картинка. Гугл сравнивает разницу между загрузкой основного контента и остальных элементов веб-страницы.
FID (First Input Delay) — время ожидания до начала взаимодействия пользователя с сайтом. Чем дольше пользователю приходится ждать момента, когда можно начать взаимодействовать со страницей (скролить, кликать по ссылкам, наживать на кнопки) тем ниже лидогенерация и выше показатель отказов.
CLS (Cumulative Layout Shift) — устойчивость верстки и элементов, которые мешают пользователю взаимодействовать с сайтом. Если в процессе загрузки элементы, особенно кликабельные, смещаются по экрану, пользователь может нажать не на ту кнопку, что не понравится ни пользователю, ни Google.
Как Core Web Vitals влияют на ранжирование
Метрики Core Web Vitals напрямую связаны со скоростью загрузки страницы. С помощью Core Web Vitals Google в очередной указывает владельцам сайтов на необходимость ускорять работу сайта.
Чем быстрее работает сайт, тем удобнее пользователям взаимодействовать с контентом. Google поощряет высокую скорость загрузки страниц улучшением позиций в поисковой выдаче.
Одна стоит учитывать, что Core Web Vitals работают в совокупности с другими метриками и алгоритмами, которые влияют на ранжирование сайта.
Оптимизация скорости загрузки страниц не всегда может привести к улучшению позиций. Для увеличения позиций сайта необходимо комплексно подходить к оптимизации сайта.
К каким показателям Core Web Vitals необходимо стремиться
Согласно данным сайта https://web.dev/ необходимо стремиться к следующим показателям:
Largest Contentful Paint (LCP): Скорость загрузки основного контента: измеряет производительность загрузки. Чтобы обеспечить удобство работы пользователей, показатель LCP должен быть в пределах 2,5 секунды от начала загрузки страницы.
First Input Delay (FID): Время ожидания до первого взаимодействия с контентом: измеряет интерактивность. Чтобы обеспечить удобство работы пользователей, показатель FID у страниц не должен превышать 100 миллисекунд.
Cumulative Layout Shift (CLS): Совокупное смещение макета: измеряет визуальную стабильность. Чтобы обеспечить удобство работы пользователей, показатель CLS не должен превышать 0,1.
Как оценить метрики Core Web Vitals на своем сайте
Оценить метрики на собственном сайте можно с помощью https://search.google.com/ в отчете Основные интернет-показатели.
Также проверить показатели на своем сайте можно через инструмент Google https://pagespeed.web.dev/.
Что такое скорость загрузки страниц
Скорость загрузки страниц – это время, за которое загружается контент на страницах сайта.
Скорость загрузки страниц является одним из важнейших факторов ранжирования в поисковых системах Яндекс и Google. В связи с этим необходимо стремиться обеспечить максимальную скорость работы сайта, чтобы высоко ранжироваться в поисковой выдаче.
От скорости загрузки зависит поведение пользователей на сайте. Низкая скорость может приводить к увеличению количества отказов, что в свою очередь негативно скажется на продажах.
Почему скорость загрузки страниц является важным фактором ранжирования
Скорость загрузки страниц с 2010 года является фактором ранжирования в Google.
Данный фактор оказывает большое влияние на поведение пользователей (например, при низкой скорости загрузки страниц увеличивается количество отказов).
Соответственно скорость загрузки страниц влияет на лояльность пользователей (от скорости загрузки может зависеть совершит ли пользователь целевое действие на сайте и станет ли постоянным посетителем сайта).
Также скорость загрузки влияет на аналитику. Чем быстрее загружается страница – тем больше данных о пользователях попадает в системы аналитики.
Сайты с низкой скоростью загрузки страниц в ряде случаев могут ранжироваться в поисковых системах значительно ниже, чем сайты с высокой скоростью загрузки.
Как быстро должна загружаться страница
Официальной информации от поисковых систем об оптимальном времени загрузки страницы нет.
Одна из наиболее распространенных рекомендаций – это скорость загрузки страниц за 3 секунды.
Вероятнее всего такой показатель обусловлен тем, что согласно исследованию Google около 53% мобильных пользователей уходят с сайта, если страницы сайта загружаются дольше 3 секунд.
При этом если страница загружается дольше 3 секунд – это не означает, что сайт будет ранжироваться в поисковых системах хуже. Все факторы ранжирования работают в совокупности. Однако необходимо стремиться оптимизировать свой сайт по всем параметрам.
Как выявить проблемы со скоростью загрузки страниц
Как увеличить скорость загрузки страниц
Для увеличения скорости загрузки страниц рекомендуем рассмотреть следующие гипотезы:
Проверять размер и количество chunks с помощью webpack-bundle-analyzer
Если проект собирается с помощью сборщика модулей webpack, перед релизом рекомендуем проверить количество и размер фрагментов кода chunks с помощью инструмента webpack-bundle-analyzer.
Анализ позволит выявить большие модули и лишние фрагменты кода, и модули, которые загружаются неправильно.
С помощью webpack-bundle-analyzer вы сможете вручную выявить проблемы, замедляющие скорость загрузки страниц.
Настроить кэширование и gzip сжатие скриптов и стилей
Включить кэширование и gzip сжатие скриптов и стилей можно на стороне хостинга, обратившись к провайдеру, либо самостоятельно через файл .htaccess.
Настроить отложенную загрузку lazy load для изображений
Lazy load – это способ отложенной загрузки изображений, в результате которого изображения загружаются не сразу с загрузкой страницы, а по мере скроллинга страницы до соответствующего изображения, либо по клику.
Обращаем внимание, что изображения на первом экране должны загружаться сразу.
При настройке Lazy load необходимо убедиться, что все изображения доступны для индексации до момента загрузки изображения.
Также рекомендуем для улучшения индексации заполнять у изображений теги alt и title и отражать в данных тегах основное содержание изображений.
Сжать размер больших изображений и использовать современные форматы
Рекомендуемый размер для изображений на сайте – 100-200 кб. Большое количество тяжелых изображений на странице может значительно снижать скорость загрузки страницы.
Настроить отложенную загрузку скриптов
Скрипты будут загружаться после полной загрузки страницы. Это позволит увеличить скорость загрузки страниц.
Стоит проверить, чтобы весь контент на странице загружался вместе загрузкой страницы и был доступен для индексации.
Убрать лишние счетчики аналитики
Пример: счетчики систем аналитики и панелей веб-мастеров (Яндекс Метрика, Google Analytics, Яндекс Вебмастер и Google Search Console) можно добавить в Google Tag Manager и разместить в коде сайта только один код (вместо 4).
Перенести счетчики аналитики в footer
Перенос счетчиков системы аналитики в подвал сайта может положительно повлиять на скорость загрузки страницы.
Такой подход часто вызывает споры между SEO-специалистами и аналитиками, так как при размещении счетчиков в конце страницы данные аналитики в некоторых случаях могут не собраться (например, при низкой скорости загрузки страницы).
Предзагружать шрифты, используемые на странице
Предзагрузку шрифтов можно настроить с помощью атрибута preload.
Атрибут preload указывает браузеру на контент, который необходимо загрузить заранее. Таким образом браузер обнаружит важный контент в начале загрузки страницы.
Использовать меньше сторонних библиотек. По возможности отказаться от Jquery и других библиотек и использовать нативный JS
Если не обойтись без Jquery, разместить её как можно ниже
Рекомендуем настроить загрузку страницы таким образом, чтобы сначала загрузился основной контент страницы, а затем скрипты, стили, библиотеки и прочие элементы веб-страницы.
Это позволит не только ускорить загрузку страницы, но и улучшить индексацию контента.
Всплывающие окна загружать через несколько секунд после загрузки страницы, либо отказаться от всплывающих окон.
По возможности рекомендуем вообще отказаться от всплывающих окон. Такой функционал, кроме снижения скорости загрузки страниц, может привести к росту количества отказов.
Использовать CDN-сеть
CDN (Content Delivery Network) – сеть доставки содержимого веб-страницы, предназначенная для оперативной доставки контента до пользователей.
CDN хорошо справляется с задачей по передаче адаптивных изображений, что экономит время и ресурсы на загрузке больших изображений.
Увеличить скорость ответа сервера
Выявить проблемы со скоростью ответа сервера можно с помощью сервиса webpagetest.org.
Настроить Last-Modified
Last-Modified – это http-заголовок, который содержит информацию о дате и времени последнего изменения страницы.
Если страница не менялась, то роботы не будут повторно переходить на страницу. Тогда страница сохранится в кэше и пользователям не нужно будет заново жать загрузки страницы.
Это экономит время на загрузке страницы, а также краулинговый бюджет (сокращает нагрузку на роботов и ускоряет индексацию других страниц).
Уменьшить количество http-запросов, объединив несколько файлов / стилей / скриптов в один
Рекомендуем стремиться к минимизации и комплектации кода страницы. Если возможно объединить несколько небольших файлов со скриптами или стилями в один – рекомендуем это сделать.
Сокращение количества компонентов на странице позволит уменьшить количество http-запросов и, соответственно, увеличить скорость загрузки страницы.
Заключение
Оптимизация скорости загрузки страниц может привести к улучшению ранжирования сайта в поисковых системах и улучшению поведенческих факторов на сайте. Это в свою очередь может привести к росту конверсий и продаж.
348 показов
185 открытий
1 комментарий
Core Web Vitals — это набор метрик, используемых Google для оценки пользовательского опыта на сайте. Включает в себя Largest Contentful Paint (LCP), First Input Delay (FID) и Cumulative Layout Shift (CLS).
Largest Contentful Paint (LCP) — это время, необходимое для загрузки самого большого элемента на странице. Чтобы улучшить LCP, можно использовать оптимизированные изображения, уменьшить количество ресурсов на странице и использовать кэширование.
First Input Delay (FID) — это время, необходимое для реакции на первый ввод пользователя на странице. Чтобы улучшить FID, можно использовать асинхронную загрузку скриптов и минимизировать использование блокирующих скриптов.
Cumulative Layout Shift (CLS) — это мера того, насколько часто элементы на странице перемещаются во время загрузки. Чтобы улучшить CLS, можно использовать фиксированные размеры изображений и видео, избегать добавления новых элементов на страницу во время загрузки и использовать задержку загрузки для некоторых элементов.
Для улучшения скорости загрузки страниц также можно использовать сжатие файлов, минификацию кода, кэширование и использование CDN. Также необходимо убедиться, что хостинг-провайдер обеспечивает быстрый доступ к серверам и хорошую производительность.
Как уменьшить Largest Contentful Paint (LCP) на сайте
Largest Contentful Paint (LCP) – это показатель производительности, который измеряет время от начала загрузки страницы до момента, когда основной контент на странице полностью отображается на экране.
Чтобы улучшить показатель LCP на сайте, следует оптимизировать загрузку и отображение важного контента.
Оптимизация изображений
Сжимайте изображения, используйте современные форматы (например, WebP), и оптимизируйте размеры изображений для разных устройств и экранов.
Ленивая загрузка (Lazy Load)
Применяйте ленивую загрузку (lazy loading) для изображений и видео, чтобы отложить загрузку контента, находящегося вне видимой области экрана.
Предзагрузка ресурсов
Используйте теги для предзагрузки важных ресурсов, таких как шрифты, CSS, и JavaScript файлы, которые влияют на отображение контента.
Минификация и сжатие ресурсов
Минифицируйте и сжимайте CSS, JavaScript, и HTML файлы, чтобы уменьшить время загрузки и разбора.
Оптимизация JavaScript
Удалите или отложите загрузку блокирующих ресурсов, таких как JavaScript и CSS. Используйте атрибуты async и defer для тегов .
Оптимизация CSS
Разделите CSS на критический (отображающийся на экране) и некритический (для контента вне видимой области). Встроить критический CSS непосредственно в HTML и загружать некритический CSS асинхронно.
Кэширование и использование CDN
Кэшируйте статические ресурсы и используйте сеть доставки контента CDN для быстрой загрузки ресурсов.
Оптимизация серверного времени отклика (TTFB)
Улучшите производительность сервера, используя кэширование на стороне сервера, оптимизацию базы данных и другие методы для сокращения времени отклика сервера.
Применение HTTP/2 или HTTP/3
Используйте современные протоколы передачи данных, такие как HTTP/2 или HTTP/3, для улучшения производительности загрузки ресурсов.
Переход на более быстрый хостинг
Рассмотрите возможность перехода на более производительный хостинг или сервер, чтобы улучшить время отклика сервера и обеспечить более быструю загрузку контента.
Удаление ненужных ресурсов и сторонних скриптов
Избавьтесь от ненужных ресурсов, сторонних скриптов и плагинов, которые могут замедлить загрузку страницы и ухудшить показатель LCP.
Улучшение рендер-блокировки
Используйте оптимизацию рендера для предотвращения рендер-блокировки, вызванной сторонними скриптами или стилями.
Внедрение критического пути отрисовки (Critical Path Rendering)
Определите критический путь отрисовки для загрузки наиболее важных ресурсов страницы в первую очередь.
Адаптивный дизайн
Разрабатывайте адаптивный дизайн, который корректно отображается на различных устройствах и экранах, учитывая разные разрешения и плотность пикселей.
Применение этих методов оптимизации может значительно улучшить показатель LCP на вашем сайте, что сделает его более быстрым и удобным для пользователей, что в свою очередь может привести к более высоким позициям в результатах поиска и лучшей конверсии.
Largest Contentful Paint (LCP)
Largest Contentful Paint (LCP) – важная, ориентированная на пользователя метрика для измерения визуально-воспринимаемой скорости загрузки, она фиксирует на временной шкале загрузки страницы точку, когда основное содержимое страницы, вероятно, загружено. Быстрая LCP помогает убедить пользователя в том, что страница полезна .
Исторически сложилось так, что веб-разработчикам было сложно измерить, насколько быстро основной контент веб-страницы загружается и становится видимым для пользователей.
Старые метрики, такие как load или DOMContentLoaded, не подходят, потому что они не обязательно соответствуют тому, что пользователь видит на своем экране. А новые, ориентированные на пользователя показатели производительности, такие как First Contentful Paint (FCP), отражают только самое начало процесса загрузки. Если на странице отображается заставка или индикатор загрузки, этот момент не очень важен для пользователя.
Раньше рекомендовались такие показатели производительности, как First Meaningful Paint (FMP) и Speed Index (SI) (оба доступны в Lighthouse), чтобы помочь уловить больше впечатлений от загрузки после начальной отрисовки, но эти показатели сложны, их трудно объяснить. Они часто неверны – это означает, что они все еще не определяют, когда загружено основное содержимое страницы.
Чем проще – тем лучше. Более точный способ измерить, когда загружается основное содержимое страницы, – это посмотреть, когда был отрисован самый большой элемент.
Что такое LCP?
Метрика Largest Contentful Paint (LCP) сообщает время рендеринга самого большого изображения или текстового блока, который находится в видимой части окна браузера, относительно того, когда страница впервые начала загружаться.
Что такое хороший показатель LCP?
Чтобы обеспечить удобство работы пользователей, сайты должны стремиться к тому, чтобы максимальная продолжительность отрисовки контента составляла 2.5 секунды или меньше. Чтобы убедиться, что вы достигли этой цели для большинства пользователей, хорошим порогом для измерения является 75-й перцентиль загрузки страниц, сегментированный по мобильным и настольным устройствам.
Какие элементы учитываются?
Как указано в API Largest Contentful Paint в настоящее время, для оценки будут рассматриваться следующие типы элементов:
- элементы
- элементы внутри элемента
- элементы (используется изображение постера)
- элементы с фоновым изображением, загруженным с помощью функции url() (в отличие от CSS-градиента)
- блочные элементы, содержащие текстовые узлы или другие дочерние строковые элементы
Обратите внимание, что ограничение элементов в этом списке было намеренным, чтобы упростить задачу вначале. Дополнительные элементы (например, , ) могут быть добавлены в будущем по мере проведения дополнительных исследований.
Как определяются размеры элемента?
Размер элемента, о котором сообщается для Largest Contentful Paint, обычно равен размеру, который виден пользователю в области просмотра. Если элемент выходит за пределы области просмотра, или если какой-либо элемент обрезан или имеет невидимое overflow, эти части не учитываются в размере элемента.
Для масштабированных изображений сообщается о видимых размерах или внутренних, в зависимости от того, что меньше. Например, уменьшенные изображения будут сообщать только размеры, в которых они отображаются, а растянутые изображения будут сообщать только свои внутренние (натуральные) размеры.
Для текстовых элементов учитываются только размеры их текстовых узлов (наименьший прямоугольник, охватывающий все текстовые узлы).
Для всех элементов любые поля, отступы или границы, применяемые с помощью только CSS, не учитываются.
Иногда бывает сложно определить, какие текстовые узлы каким элементам принадлежат. Особенно для элементов, у которых дочерние включают встроенные элементы и узлы с простым текстом, а также блочные элементы. Ключевым моментом является то, что каждый текстовый узел принадлежит своему ближайшему блочному элементу-предку. В терминах спецификации: каждый текстовый узел принадлежит элементу, который генерирует содержащий его блок.
Когда сообщается об отрисовке самого большого элемента?
Веб-страницы часто загружаются поэтапно, поэтому самый большой элемент на странице может измениться в процессе.
Чтобы перехватить возможные изменения, браузер отправляет PerformanceEntry типа large-contentful-paint , идентифицирующий самый большой контентный элемент, как только отрисовывается первый кадр. Но затем, после рендеринга следующих кадров, он будет отправлять другие PerformanceEntry каждый раз, когда изменяется самый большой содержательный элемент.
Например, на странице с текстом и заглавным изображением браузер может сначала просто отобразить текст – в этот момент он отправит largest-contentful-paint , свойство element которой, скорее всего, будет ссылаться на
или . Позже, как только заглавное изображение загрузится, будет отправлена следующая запись largest-contentful-paint , а её свойство element будет ссылаться на .
Важно отметить, что элемент может считаться самым большим элементом содержимого только после того, как он отрисован и станет видимым для пользователя. Еще не загруженные изображения не учитываются.
Также текстовые узлы не используют веб-шрифты в период блокировки шрифтов. В таких случаях о меньшем элементе может быть сообщено как о самом большом содержательном элементе, но как только более крупный элемент завершит рендеринг, о нём будет сообщено через другой объект PerformanceEntry .
Помимо поздней загрузки изображений и шрифтов, страница может добавлять новые элементы в DOM по мере поступления контента. Если какой-либо из этих новых элементов окажется больше, чем предыдущий самый большой содержательный элемент, то PerformanceEntry обязательно сообщит о нём.
Если самый большой элемент содержимого будет удален из области просмотра (или даже удален из DOM), он будет оставаться самым большим элементом содержимого, пока не появится элемент крупнее его.
До Chrome 88 удаленные элементы не считались элементами с наибольшим содержимым, и их удаление приводило к отправке новой записи largest-contentful-paint . Однако из-за популярных шаблонов пользовательского интерфейса, например карусели изображений, которые часто удаляют DOM-элементы, метрика была обновлена, чтобы точнее отражать то, что испытывают пользователи.
Браузер перестанет сообщать о новых записях largest-contentful-paint , как только пользователь начнёт взаимодействовать со страницей (касание, клик, прокрутка или нажатие клавиш), поскольку взаимодействие с пользователем может изменить то, что ему показывается. Это особенно очевидно при прокрутке страницы.
Для анализа вы должны сообщать в службу аналитики только последний отправленный PerformanceEntry элемент.
Предупреждение: иногда пользователи могут открывать страницы в фоновой вкладке. В этом случае возможно, что самая большая содержательная отрисовка вообще не произойдет, пока пользователь не откроет эту вкладку и в неё переместится фокус. Это может произойти сильно позже, чем при первой загрузке страницы.
Время загрузки или время рендеринга
По соображениям безопасности метка времени рендеринга изображений не отображается для изображений из разных источников, у которых отсутствует заголовок Timing-Allow-Origin . Вместо этого отображается только время их загрузки (поскольку оно уже доступно через многие другие веб-API).
В приведенном ниже примере показано, как обрабатывать элементы, время рендеринга которых недоступно. Но, по возможности, всегда рекомендуется устанавливать заголовок Timing-Allow-Origin , чтобы ваши показатели были более точными.
Как обрабатываются изменения макета и размера элемента?
Чтобы снизить влияние вычислений и отправки LCP-записей на общую производительность, изменения размеров или положения элемента не будут учитываться и создавать новых кандидатов LCP. Учитывается только начальный размер и положение элемента в области просмотра.
Это означает, что могут не передаваться изображения, которые изначально появляются за пределами, а затем оказываются в видимой области экрана. Это также означает, что изначально отображаемые в видимой области экрана элементы, которые затем выталкиваются из поля зрения, продолжат сообщать о своем исходном размере в области просмотра.
Примеры
Вот несколько примеров, как Largest Contentful Paint происходит на нескольких популярных веб-сайтах:
На обеих временных шкалах, самый большой элемент изменяется по мере загрузки содержимого. В первом примере новый контент добавляется в DOM, и это изменяет самый большой элемент. Во втором примере макет изменяется, и содержимое, которое ранее было самым большим, удаляется из видимой области экрана.
Хотя часто происходит так, что позже загруженный контент может оказаться крупнее, чем уже находящийся на странице, это не всегда так. Следующие два примера показывают, что Largest Contentful Paint происходит до полной загрузки страницы.
В первом примере рано загруженный логотип Instagram загружается остаётся самым крупным элементом, даже когда другой контент отображается постепенно. В примере страницы результатов поиска Google самый большой элемент – это абзац текста, который отображается до того, как любое из изображений или логотип завершит загрузку. Поскольку все отдельные изображения меньше этого абзаца, он остается самым большим элементом на протяжении всего процесса загрузки.
В первом кадре временной шкалы Instagram можно заметить, что вокруг логотипа камеры нет зеленой рамки. Это потому, что он – элемент , а -элементы в настоящее время не считаются кандидатами LCP. Первый кандидат LCP – это текст появляется во втором кадре.
Как измерить LCP
В полевых условиях
- Chrome User Experience Report
- PageSpeed Insights
- Search Console (Core Web Vitals report)
- web-vitals JavaScript-библиотека
В лабораторных условиях
Измерение LCP в JavaScript
Чтобы измерить LCP в JavaScript, можно воспользоваться API Largest Contentful Paint API. В следующем примере показано, как создать PerformanceObserver , который прослушивает записи largest-contentful-paint и возвращает их в консоль.
new PerformanceObserver((entryList) => < for (const entry of entryList.getEntries()) < console.log('LCP кандидат:', entry.startTime, entry); >>).observe();Этот код показывает только, как записывать в консоль записи с самым большим содержимым, но само измерение LCP в JavaScript сложнее. Ниже будет рассмотрено, как:
В приведенном выше примере каждая зарегистрированная запись largest-contentful-paint представляет текущего кандидата LCP. Как правило, значение startTime последней отправленной записи является значением LCP, однако это не всегда так. Не все записи largest-contentful-paint подходят для измерения LCP.
Здесь перечислены различия между тем, что сообщает API, и тем, как рассчитывается метрика.
- API будет отправлять записи с самым большим содержимым largest-contentful-paint для страниц, загруженных на фоновой вкладке, но при вычислении LCP такие страницы следует игнорировать.
- API продолжит отправку записей largest-contentful-paint после того, как страница перестает быть фоновой, но эти записи следует игнорировать при вычислении LCP (элементы могут учитываться только в том случае, если страница все время была на переднем плане).
- API не сообщает о записях с самым большим содержимым, когда страница восстанавливается из кэша назад/вперед, но в таких случаях следует измерять LCP, поскольку пользователи воспринимают это как отдельные посещения страницы.
- API не учитывает элементы iframe , но для правильного измерения LCP вы должны их учитывать. iframe могут использовать API, чтобы сообщать о своих записях largest-contentful-paint в родительское окно для агрегирования.
Вместо того, чтобы запоминать все эти тонкости и различия, разработчики могут использовать JavaScript-библиотеку web-vitals для измерения LCP, которая, где это возможно, обрабатывает такие случаи:
import from 'web-vitals'; // Измерение и логирование LCP по возможности. getLCP(console.log);В некоторых случаях (например, в cross-origin iframe ) невозможно измерить LCP в JavaScript. Подробности в разделе ограничений библиотеки web-vitals.
Что, если самый большой элемент не самый важный?
В некоторых случаях самый важный элемент (или элементы) на странице не окажется самым большим элементом, но разработчики могут быть больше заинтересованы в измерении времени рендеринга таких элементов. Это возможно с помощью Element Timing API, как описано в статье о пользовательских метриках.
Как улучшить LCP
В первую очередь на LCP влияют четыре фактора:
- Медленное время ответа сервера
- Блокирующие рендеринг JavaScript и CSS
- Время загрузки ресурса
- Клиентский рендеринг
Подробности о том, как улучшить LCP можно изучить здесь. Дополнительные рекомендации по отдельным методам повышения производительности, которые также могут улучшить LCP, см.
- Применяйте мгновенную загрузку с PRPL-паттерном
- Оптимизация критического пути отрисовки
- Оптимизируйте свой CSS
- Оптимизируйте свои изображения
- Оптимизируйте web-шрифты
- Оптимизируйте свой JavaScript (для сайтов, которые рендерит клиент)
Как бороться предупреждением в GSC «Значение показателя «LCP» слишком велико»?
Подскажите, как бороться предупреждением в GSC «Значение показателя «LCP» слишком велико: более 4 сек. (мобильные устройства)»?
Что исправлять и как быстро можно отправлять страницы на повторную проверку?
Ответ
Предупреждение о значении показателя LCP (Largest Contentful Paint) указывает на то, что на вашем сайте есть задержки при загрузке основного контента. Это может отрицательно сказываться на пользовательском опыте, особенно на мобильных устройствах, где соединение может быть медленнее.
На LCP влияют такие факторы:
- время ответа сервера;
- блокирующие рендеринг JavaScript и CSS;
- время загрузки ресурса;
- рендеринг на стороне клиента.
Чтобы бороться с этим предупреждением и улучшить показатель LCP, необходимо предпринять такие действия:
- Оптимизируйте загрузку основного контента. Проверьте, какие элементы на вашей странице являются самыми большими по размеру и требуют больше времени для загрузки. Оптимизируйте эти элементы, уменьшив их размер или используя сжатие.
- Оптимизируйте изображения. Изображения, которые много весят можно сжать, или попробовать новый формат изображений WebP. Также, если на сайте много больших по размеру изображений, то попробуйте lazy loading (постепенную подгрузку).
- Оптимизируйте серверную конфигурацию. Чем быстрее браузер получает контент с сервера, тем быстрее загрузка страницы и тем лучше показатель LCP. Используйте CDN, кэшируйте страницы или попробуйте сервис-воркеры.
- Используйте асинхронную загрузку контента. Разделите свой контент на разные части и загружайте его асинхронно, чтобы сначала отобразить на экране самую важную часть. Таким образом, пользователи смогут увидеть содержимое страницы быстрее, даже если другие элементы еще загружаются.
- Оптимизируйте CSS и JavaScript. Избегайте блокировки рендеринга страницы длинным и сложным CSS или JavaScript кодом. Убедитесь, что ваш код оптимизирован и минимизирован, и загружайте скрипты асинхронно. Также можно убрать неиспользуемые CSS и Javфіскшзе со страниц, где он не нужен.
После выполненных шагов отправьте страницы на повторную проверку в GSC. Следует понимать, что повторная проверка страниц может занимать некоторое время и зависит от загруженности системы Search Console.
Хотите получить ответ на свой вопрос? Задайте его нам через телеграм-бота!↓
Подписаться на рассылку
- Как улучшить показатель CLS для Google? CLS — что предпринять, чтобы улучшить этот критерий? Бьемся и ничего не помогает, Google Search Console все время показывает ошибки. Ответ CLS — Cumulative Layout.
- Как шрифты влияют на скорость загрузки сайта? Стоял раньше шрифт PT Sans на сайте. Удобный, симпотный и т.д, на мой взгляд. А потом я вычитал мол «open sans оказался самым быстрым шрифтом.
- Какие SEO инструменты использовать для анализа и проработки скорости загрузки? Хотим ускорить сайт и убрать базовые ошибки. Какими сервисами посоветуете пользоваться? Чем эффективнее всего заниматься при работе со скоростью загрузки? Ответ Для анализа скорости загрузки.
- Влияет ли скорость загрузки и скорость ответа сервера на сканирование и индексирование сайта? Если скорость ответа сервера очень маленькая, может это повлиять на сканирование и индексирование сайта? Тот же вопрос про общую скорость загрузки сайта. Ответ Да, скорость.
- Нужно ли исправлять core web vitals и как это делать? Насколько приоритетной является задача по исправлению core web vitals? Достаточно ли для этого выполнений рекомендаций Google или есть другие рабочие способы? Ответ Исправление Core Web.