largest contentful paint что это
Как оптимизировать LCP-показатель
Нет времени читать статью?
Но вам требуется продвижение сайта или создание сайта-лидера, идеального для SEO? Тогда вы можете оставить заявку на продвижение или заявку на создание сайта. Если вы собираетесь продвигать сайт самостоятельно — продолжайте чтение!
Вы в курсе, что с 2021 года Google будет использовать новые показатели для оценки качества сайтов. Largest Contentful Paint — один из таких. А вы знаете, как его измерить и улучшить? Если нет — тогда наш сегодняшний материал придется вам как раз кстати!
Мы подготовили статью, полностью посвященную Largest Contentful Paint и всем тонкостям улучшения этого показателя. Переходите по ссылку и читайте, чтобы одним из первых узнать важную актуальную информацию и улучшить свой сайт.
Как оптимизировать LCP-показатель: эффективные способы
LCP: как измерить
Самый простой метод — использовать соответствующее API, которое работает по следующему принципу:
Для того, чтобы измерить Largest Contentful Paint, можно также использовать:
Также можно проверить скорость загрузки сайта на одном из любых бесплатных сервисов.
Нормальный показатель LCP
Будет просто замечательно, если вы сможете ускорить загрузку сайта до такой степени, чтобы самый большой элемент на странице открывался не дольше 2,5 секунд от момента открытия сайта на 75% сессий. Только в таком случае сайтом будет удобно пользоваться. И это независимо от того, “на чем” сделан сайт — на Bitrix или WordPress.
LCP: как улучшить показатели
А теперь более детально разберем все эти показатели и подумаем, как их улучшить.
Время ответа сервера
Нам нужно улучшить время загрузки первого байта — TTFB. Для этого можно:
Время загрузки сайта
Если этот показатель довольно большой, то на LCP он скажется негативно — это 100%. Чтобы уменьшить его, необходимо:
Рендеринг на стороне пользователя
Оптимизация рендеринга на стороне клиента — еще одна прекрасная возможность улучшить показатель LCP. Но сложность метода заключается в том, что все происходит на стороне ПК пользователя, а не вашего сервера, поэтому выбор в плане инструментов для такой оптимизации у вас небольшой:
Предварительный рендеринг — еще один шанс улучшить ситуацию. При таком подходе он выполняется в headless браузера, генерирующем статичный HTML-код, а уже потом подставляет ответ сервера. Реализовав подобное, реальный сервер не будет перегружаться, что положительно скажется на показателе LCP.
JS и CSS с блокировкой рендеринга
Разумеется, критический CSS необходимо оставить включенным, если он необходим в верхней части страницы. Для JavaScript нужно использовать асинхронную загрузку. А для достижения максимального эффекта — нужно минимизировать весь код JavaScript и CSS на сайте.
Как оптимизировать показатель LCP — ускоряем загрузку контента для пользователей
В статье:
В мае Google определил новый способ оценки пользовательского опыта. Показатель называется Google Core Vitals, он связан со скоростью загрузки сайта и появления на нем контента.
Google Core Vitals состоит из трех метрик:
Про CLS у нас есть подробный материал «Как оптимизировать CLS: сдвиги макета страницы, которые мешают пользователям», в этой статье поговорим о показателе LCP и способах его улучшить.
Что такое LCP — показатель Largest Contentful Paint
Largest Contentful Paint — время рендеринга самого большого элемента, видимого в области просмотра пользователем — изображения, текстового блока, видео или другого контента. Учитываются те размеры элементов, которые видны пользователю. Если элемент частично скрыт за областью просмотра, эти невидимые части не берутся в расчет.
Самый аккуратный способ определить время отображения основного содержимого страницы — использовать API Largest Contentful Paint (LCP).
Как это происходит:
При загрузке страницы контент может меняться, поэтому каждый раз, когда появляется новый большой элемент, браузер отправляет PerformanceEntry c типом largest-contentful-paint. Когда пользователь начинает взаимодействовать со страницей, отправка метрики прекращается. Нужное значение — время самого последнего отправленного события.
Отрисовка самого большого элемента может происходить и до полной загрузки страницы. К примеру, логотип Instagram — самый большой элемент, он загружается относительно рано и остается самым большим элементом, пока постепенно отображается остальной контент.
Самый большой элемент загрузился до конца загрузки остального контента
В следующем примере самый большой элемент изменяется по мере загрузки содержимого — сначала им был текст, потом самым большим объектом стала картинка.
Самый большой элемент менялся по мере загрузки
Как измерить LCP: инструменты веб-мастера
Инструменты, которые позволяют измерить показатель LCP:
Проверка скорости сайта от PR-CY бесплатно анализирует загрузку страницы по ключевым параметрам, проверяет десктопное и мобильное отображение. Сервис дает рекомендации и прикидывает, сколько можно сэкономить, если их внедрить на сайте.
Интерфейс проверки скорости сайта
Какой показатель LCP считается хорошим
Нужно стремиться, чтобы отрисовка самого большого контента происходила не дольше, чем за 2,5 секунды после начала загрузки страницы. Тогда пользователям будет удобно работать на сайте.
Инструменты для измерения показывают сводный показатель LCP для 75 % посещений URL.
Как улучшить показатель LCP
На LCP влияют четыре фактора:
Рассмотрим эти факторы, сопутствующие им проблемы и способы оптимизировать показатели.
Медленный ответ сервера
Чем быстрее браузер получает контент с сервера, тем быстрее загрузка страницы и тем лучше показатель LCP.
Вы можете улучшить TTFB — время до первого байта. Какие есть способы:
Другой вариант — dns-prefetch для ускорения поиска DNS, подходит для браузеров, которые не поддерживают preconnect.
Можно использовать оба варианта для разных браузеров.
Блокировка рендеринга JavaScript и CSS
Браузер преобразовывает разметку HTML в дерево DOM, а потом уже отображает контент. Он не сможет продолжать работу, если обнаружит ресурсы, блокирующие рендеринг: внешние таблицы стилей link rel=»stylesheet» и сценарии JavaScript script src=»https://pr-cy.ru/news/p/main.js». Чтобы ускорить загрузку содержимого страницы, нужно отложить все некритические JavaScript и CSS.
Неиспользуемый JavaScript и CSS можно найти с помощью Chrome DevTools на вкладке Coverage.
Поиск неиспользуемого CSS и JavaScript
Найденный неиспользуемый CSS можно вообще удалить или переместить в другую таблицу стилей, если он нужен на других страницах сайта.
Если CSS не нужен для начального рендеринга, можно использовать loadCSS для асинхронной загрузки файлов, который использует rel=»preload» и onload.
Как улучшилось LCP после откладывания некритического CSS
Критический CSS можно включить в head, если он нужен для верхней части страницы. Встраивание стилей таким образом позволит не делать двусторонний запрос для получения критического CSS.
Как автоматизировать добавление встроенных стилей на сайт:
Для JavaScript также можно использовать асинхронную загрузку.
Еще полезна минификация или минимизация кода CSS и JavaScript — удаление символов, которые не нужны браузеру для чтения кода. Минификаторы удаляют отступы, интервалы, разделители и комментарии, файл по сути не меняется, но становится легче.
Список бесплатных инструментов для минимизации CSS, JS, HTML-файлов есть в статье.
Как улучшилось LCP после минификации CSS
Долгая загрузка ресурсов
Время, которое требуется контенту для загрузки, влияет на LCP, так что имеет смысл поработать с элементами на странице.
Рендеринг на стороне клиента
Есть сайты, которые работают через рендеринг на стороне клиента (CSR) — то есть рендеринг страниц происходит в браузере с использованием JavaScript, все обрабатывается на стороне клиента, а не на сервере.
Основной недостаток такого подхода в том, что по мере роста сайта, добавления новых библиотек и кода начинает страдать скорость загрузки и отображения контента для пользователя.
В некоторых случаях можно использовать предварительный рендеринг. В таком способе рендер выполняется в headless браузере типа Chrome, который генерирует статические файлы HTML, а их уже подставляют в ответ сервера.
Предварительный рендеринг не нагружает реальный сервер и позволяет улучшить показатель LCP, но не подходит для страниц с изменяемым или с введенным пользователем контентом.
Как улучшилось LCP после предварительного рендеринга
Скорость загрузки ресурса на компьютере и мобильных устройствах можно проверить в Анализе сайта от PR-CY. Он проверяет сайт по 70+ параметрам, включая скорость загрузки и отображения контента, анализирует, что реализовано на сайте для ускорения, и дает советы, что еще можно улучшить.
Проверка скорости в Анализе сайта
Некоторые подробные тесты и графики, а также проверка внутренних страниц и отслеживание позиций доступны на платных тарифах. Но мы даем новым пользователям неделю на бесплатный тест сервиса — оставайтесь, если понравится!
В комментариях напишите, о чем еще вам было бы интересно почитать по теме оптимизации и работы с техническими характеристиками сайта.
Largest Contentful Paint (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 в настоящее время, для оценки будут рассматриваться следующие типы элементов:
Как определяются размеры элемента?
Размер элемента, о котором сообщается для Largest Contentful Paint, обычно равен размеру, который виден пользователю в области просмотра. Если элемент выходит за пределы области просмотра, или если какой-либо элемент обрезан или имеет невидимое overflow, эти части не учитываются в размере элемента.
Для масштабированных изображений сообщается о видимых размерах или внутренних, в зависимости от того, что меньше. Например, уменьшенные изображения будут сообщать только размеры, в которых они отображаются, а растянутые изображения будут сообщать только свои внутренние (натуральные) размеры.
Для текстовых элементов учитываются только размеры их текстовых узлов (наименьший прямоугольник, охватывающий все текстовые узлы).
Для всех элементов любые поля, отступы или границы, применяемые с помощью только CSS, не учитываются.
Иногда бывает сложно определить, какие текстовые узлы каким элементам принадлежат. Особенно для элементов, у которых дочерние включают встроенные элементы и узлы с простым текстом, а также блочные элементы. Ключевым моментом является то, что каждый текстовый узел принадлежит своему ближайшему блочному элементу-предку. В терминах спецификации: каждый текстовый узел принадлежит элементу, который генерирует содержащий его блок.
Когда сообщается об отрисовке самого большого элемента?
Веб-страницы часто загружаются поэтапно, поэтому самый большой элемент на странице может измениться в процессе.
Важно отметить, что элемент может считаться самым большим элементом содержимого только после того, как он отрисован и станет видимым для пользователя. Еще не загруженные изображения не учитываются.
Помимо поздней загрузки изображений и шрифтов, страница может добавлять новые элементы в DOM по мере поступления контента. Если какой-либо из этих новых элементов окажется больше, чем предыдущий самый большой содержательный элемент, то PerformanceEntry обязательно сообщит о нём.
Если самый большой элемент содержимого будет удален из области просмотра (или даже удален из DOM), он будет оставаться самым большим элементом содержимого, пока не появится элемент крупнее его.
Для анализа вы должны сообщать в службу аналитики только последний отправленный PerformanceEntry элемент.
Предупреждение: иногда пользователи могут открывать страницы в фоновой вкладке. В этом случае возможно, что самая большая содержательная отрисовка вообще не произойдет, пока пользователь не откроет эту вкладку и в неё переместится фокус. Это может произойти сильно позже, чем при первой загрузке страницы.
Время загрузки или время рендеринга
Как обрабатываются изменения макета и размера элемента?
Чтобы снизить влияние вычислений и отправки LCP-записей на общую производительность, изменения размеров или положения элемента не будут учитываться и создавать новых кандидатов LCP. Учитывается только начальный размер и положение элемента в области просмотра.
Это означает, что могут не передаваться изображения, которые изначально появляются за пределами, а затем оказываются в видимой области экрана. Это также означает, что изначально отображаемые в видимой области экрана элементы, которые затем выталкиваются из поля зрения, продолжат сообщать о своем исходном размере в области просмотра.
Примеры
Вот несколько примеров, как Largest Contentful Paint происходит на нескольких популярных веб-сайтах:
На обеих временных шкалах, самый большой элемент изменяется по мере загрузки содержимого. В первом примере новый контент добавляется в DOM, и это изменяет самый большой элемент. Во втором примере макет изменяется, и содержимое, которое ранее было самым большим, удаляется из видимой области экрана.
Хотя часто происходит так, что позже загруженный контент может оказаться крупнее, чем уже находящийся на странице, это не всегда так. Следующие два примера показывают, что Largest Contentful Paint происходит до полной загрузки страницы.
В первом примере рано загруженный логотип Instagram загружается остаётся самым крупным элементом, даже когда другой контент отображается постепенно. В примере страницы результатов поиска Google самый большой элемент — это абзац текста, который отображается до того, как любое из изображений или логотип завершит загрузку. Поскольку все отдельные изображения меньше этого абзаца, он остается самым большим элементом на протяжении всего процесса загрузки.
Как измерить LCP
В полевых условиях
В лабораторных условиях
Измерение LCP в JavaScript
Этот код показывает только, как записывать в консоль записи с самым большим содержимым, но само измерение LCP в JavaScript сложнее. Ниже будет рассмотрено, как:
В приведенном выше примере каждая зарегистрированная запись largest-contentful-paint представляет текущего кандидата LCP. Как правило, значение startTime последней отправленной записи является значением LCP, однако это не всегда так. Не все записи largest-contentful-paint подходят для измерения LCP.
Здесь перечислены различия между тем, что сообщает API, и тем, как рассчитывается метрика.
Вместо того, чтобы запоминать все эти тонкости и различия, разработчики могут использовать JavaScript-библиотеку web-vitals для измерения LCP, которая, где это возможно, обрабатывает такие случаи:
В некоторых случаях (например, в cross-origin iframe ) невозможно измерить LCP в JavaScript. Подробности в разделе ограничений библиотеки web-vitals.
Что, если самый большой элемент не самый важный?
В некоторых случаях самый важный элемент (или элементы) на странице не окажется самым большим элементом, но разработчики могут быть больше заинтересованы в измерении времени рендеринга таких элементов. Это возможно с помощью Element Timing API, как описано в статье о пользовательских метриках.
Как улучшить LCP
В первую очередь на LCP влияют четыре фактора:
Подробности о том, как улучшить LCP можно изучить здесь. Дополнительные рекомендации по отдельным методам повышения производительности, которые также могут улучшить LCP, см.
Core Web Vitals: как Google решил оценивать сайты
Сегодня поговорим о важности пользовательского взаимодействия, ведь совсем скоро придется подготовить свои сайты к максимальному ускорению загрузки. Возможно, вы уже слышали про Core Web Vitals…
В прошлом году Google начал масштабный пересмотр факторов ранжирования в поисковике, чтобы улучшить качество поисковой выдачи. И в ноябре команда Google анонсировала Core Web Vitals — новые факторы оценки качества ресурсов, которые смогут влиять на индексацию и вступят в силу в мае 2021 года. Давайте разбираться.
Существуют сотни факторов ранжирования, однако Core Web Vitals будет анализировать ещё больше информации и иметь непосредственное влияние на дальнейшую индексацию. Нужно отметить, что скорость загрузки напрямую не влияет на индексацию, однако имеет значительное влияние на поведение пользователя, которое является важным сигналом для поисковых алгоритмов Google.
Чем Core Web Vitals отличается от прочих факторов ранжирования?
Положительная сторона Core Web Vitals — в прозрачности: это понятные, публично доступные критерии, которые можно отслеживать и улучшать с помощью специального набора инструментов. Кроме того, с момента анонсирования и до официального запуска есть много времени, чтобы уже начать работать над Core Web Vitals.
Андрей Липатцев, Web Partnerships Google
Core Web Vitals
Среди многих показателей ранжирования (оптимизации для мобильных устройств, безопасный просмотр, безопасность HTTPS и т.д.) Google выделил основные (core), жизненно важные для пользователя. Метрики, составляющие Core Web Vitals, со временем будут развиваться и дополняться.
Текущий набор показателей фокусируется на трех аспектах взаимодействия с пользователем: 
LCP (загрузка)
Для разработчиков всегда было непросто измерить, насколько быстро контент веб-страницы загружается и становится видимым для пользователей.
Старые метрики, такие как load или DOMContentLoaded, не подходят, так как они всегда соответствуют тому, что пользователь видит на экране. А более новые показатели производительности, такие как First Contentful Paint (FCP), отражают только самое начало процесса загрузки.
В ходе исследований обнаружилось, что более точный способ измерить загрузку основного содержимого страницы, – это посмотреть, когда был отрисован самый большой элемент.
Так появилась метрика Largest Contentful Paint (LCP), которая измеряет время рендеринга самого большого элемента на странице. 
Что считается большим элементом?
Как это работает?
Веб-страница загружается поэтапно, и в результате самый большой элемент на ней может измениться.
Чтобы справиться с таким изменением, браузер отрисовывает первый кадр и отправляет PerformanceEntry с параметром large-contentful-paint, который идентифицирует самый большой элемент. Но затем, после рендеринга последующих кадров, браузер будет отправлять PerformanceEntry при каждом изменении самого большого элемента.
Важно отметить, что элемент может считаться самым большим содержимым только после того, как он будет отрисован и виден для пользователя.
Браузер перестает сообщать о новых записях, как только пользователь начнет взаимодействовать со страницей, поскольку взаимодействие может визуально изменить страницу (прокрутка, модальное окно и т.д.).
Рис.1. Изменение самого большого элемента по мере загрузки содержимого
Как определяется размер самого большого элемента?
Размер элемента определяется в области видимости пользователя: если элемент выходит за её пределы (обрезан или имеет overflow: hidden), то эти части не учитываются.
Если у изображения видимый и исходный размеры отличаются, то будет учитываться меньший из них. Например, если изображение сжали до меньшего размера, чем его исходный, то передается видимый размер, а если растянули — исходный.
Для текстовых элементов учитывается только размер их текстовых узлов.
Для всех элементов любые margin, padding или border не рассматриваются.
FID (интерактивность)
Метрика First Input Delay (FID) помогает измерить первое впечатление пользователя об интерактивности и быстродействии вашего сайта.
FID измеряет время с момента, когда пользователь впервые взаимодействует со страницей, до того, как браузер действительно может начать обработку событий в ответ на это взаимодействие.
Задержка ввода возникает из-за того, что основной поток браузера занят чем-то другим (синтаксическим анализом или выполнением большого бандла), поэтому он (пока) не может ответить пользователю.
FID можно измерить только в реальных условиях.
Почему рассматривается именно первый ввод?
CLS (визуальная стабильность)
Cumulative Layout Shift — важный, ориентированный на пользователя показатель для измерения стабильности верстки и элементов, не препятствующих взаимодействию с контентом.
Например, вы переходите на сайт, почитать статью. Пока сайт прогружался, на странице появилось ещё несколько элементов и положение скролла неожиданно изменилось. Неприятно.
Рис.2. Пример Cumulative Layout Shift
Первая ассоциация при виде этого примера — реклама. Думаю, что каждый хотя бы раз сталкивался с таким неожиданным появлением элемента.
Это может происходить из-за асинхронной загрузки ресурсов или динамического добавления DOM-элементов на странице. Причиной может быть изображение или видео с неизвестными размерами, сторонняя реклама или виджет, которые динамически изменяют размер.
CLS измеряет общую сумму всех показателей визуальной стабильности верстки в течение сессии страницы.
Показатель визуальной стабильности определяет Layout Instability API, который отправляет layout-shift каждый раз, когда существующий элемент меняет свое начальное положение между двумя кадрами.
Обратите внимание, что визуальная стабильность не учитывается, когда новый элемент добавляется в DOM или существующий элемент меняет размер.
Чтобы вычислить коэффициент визуальной стабильности, браузер смотрит на размер области просмотра и перемещение нестабильных элементов между двумя визуальными кадрами. Коэффициент вычисляется двумя показателями: коэффициентом воздействия и расстояния.
Рис.3. Коэффициент воздействия
На изображении выше есть элемент, который занимает половину области просмотра в одном кадре. Затем в следующем кадре элемент смещается вниз на 25% от высоты экрана. Красный пунктирный прямоугольник указывает на объединение видимой области элемента в обоих кадрах, которая в данном случае составляет 75% от экрана.
Рис.4. Доля расстояния
Доля расстояния — это наибольшее расстояние, на которое любой нестабильный элемент переместился в кадре (по горизонтали или вертикали), деленное на размер экрана.
В приведенном примере наибольшим размером экрана является высота, а нестабильный элемент перемещается на 25%.
Коэффициент визуальной стабильности = 0.75 * 0.25 = 0.1875
Как улучшить показатели Core Web Vitals?
Если ваше приложение не дотягивает до идеальных показателей, то нужно заняться вопросом повышения скорости. Итак, что можно сделать:
Библиотеки и инструменты
Самый простой способ измерить все Core Web Vitals — использовать js-библиотеку web-vitals, которая измеряет каждую метрику в соответствии с Инструментами Google.
Или можно использовать расширение Web Vitals для Chrome.
Не забывайте периодически следить за скоростью загрузки своего приложения. Быстрая реакция на любые негативные изменения позволит минимизировать потери и вовремя внести необходимые коррективы. Core Web Vitals влияет не только на индексацию, но и главным образом на конверсию, посещаемость и в результате на прибыль. К счастью, Google предупредил заранее о запуске новых факторов ранжирования, поэтому у вас есть еще время исправить все погрешности к запуску Core Web Vitals (май 2021).
Полезные ссылки и используемые материалы: