Largest contentful paint как уменьшить

Оптимизация CSS

Разделите CSS на критический (отображающийся на экране) и некритический (для контента вне видимой области). Встроить критический CSS непосредственно в HTML и загружать некритический CSS асинхронно.

Кэширование и использование CDN

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

Оптимизация серверного времени отклика (TTFB)

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

Применение HTTP/2 или HTTP/3

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

Переход на более быстрый хостинг

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

Удаление ненужных ресурсов и сторонних скриптов

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

Улучшение рендер-блокировки

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

Внедрение критического пути отрисовки (Critical Path Rendering)

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

Адаптивный дизайн

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

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

Как оптимизировать показатель LCP — ускоряем загрузку контента для пользователей

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

Google Core Vitals состоит из трех метрик:

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

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

Что такое LCP — показатель Largest Contentful Paint

Largest Contentful Paint — время рендеринга самого большого элемента, видимого в области просмотра пользователем — изображения, текстового блока, видео или другого контента. Учитываются те размеры элементов, которые видны пользователю. Если элемент частично скрыт за областью просмотра, эти невидимые части не берутся в расчет.

Самый аккуратный способ определить время отображения основного содержимого страницы — использовать API Largest Contentful Paint (LCP).

Как это происходит:

При загрузке страницы контент может меняться, поэтому каждый раз, когда появляется новый большой элемент, браузер отправляет PerformanceEntry c типом largest-contentful-paint. Когда пользователь начинает взаимодействовать со страницей, отправка метрики прекращается. Нужное значение — время самого последнего отправленного события.

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

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

Как измерить LCP: инструменты веб-мастера

Инструменты, которые позволяют измерить показатель LCP:

• Отчет Core Web Vitals в Search Console, он находится в Отчете об основных интернет-показателях
• PageSpeed Insights

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

Какой показатель LCP считается хорошим

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

Инструменты для измерения показывают сводный показатель LCP для 75 % посещений URL.

Как улучшить показатель LCP

На LCP влияют четыре фактора:

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

Рассмотрим эти факторы, сопутствующие им проблемы и способы оптимизировать показатели.

Медленный ответ сервера

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

Вы можете улучшить TTFB — время до первого байта. Какие есть способы:

1. Обратитесь к рекомендациям по производительности сервера.
   Многие веб-фреймворки, работающие на сервере, имеют такие рекомендации, нужные для ускорения. Как исправить перегруженный сервер
2. Используйте CDN (Content Delivery Network).
   CDN хранят контент и быстро отдают его клиентам из разных географических точек. Подробнее есть в нашей статье. По выводам из исследования, использование CDN коррелировало с улучшением показателей скорости загрузки TTFB, особенно на десктопах.
3. Кэшируйте страницы.
   Статичный HTML, который редко изменяется, можно закэшировать в браузере пользователя, чтобы при каждом визите не загружать контент заново. О кэшировании, сжатии gzip и brotli и других способах оптимизации есть отдельный материал.
4. Попробуйте сервис-воркеры
   Service Worker могут перехватывать запросы с сервера и управлять кэшем — например, кэшировать только часть страницы или обновлять кэш только при изменении содержимого.
5. Устанавливайте сторонние подключения на раннем этапе.
   На LCP могут влиять запросы сервера к сторонним источникам. Можно дать сигнал браузеру, что страница как можно скорее собирается установить соединение, для этого есть rel=» 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 можно вообще удалить или переместить в другую таблицу стилей, если он нужен на других страницах сайта.

Если CSS не нужен для начального рендеринга, можно использовать loadCSS для асинхронной загрузки файлов, который использует rel=»preload» и onload.

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

Как автоматизировать добавление встроенных стилей на сайт:

• Critical, CriticalCSS и Penthouse извлекают и встраивают верхний CSS;
• Critters встраивает критический CSS и загружает остальные в отложенном режиме.

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

Еще полезна минификация или минимизация кода CSS и JavaScript — удаление символов, которые не нужны браузеру для чтения кода. Минификаторы удаляют отступы, интервалы, разделители и комментарии, файл по сути не меняется, но становится легче.

Список бесплатных инструментов для минимизации CSS, JS, HTML-файлов есть в статье.

Долгая загрузка ресурсов

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

Что можно сделать:

1. Оптимизировать изображения.
   Если на сайте много больших по размеру изображений, которые замедляют загрузку страниц, попробуйте lazy loading картинок — постепенную подгрузку, которая обычно зависит от действий пользователя на странице. Еще можно сжать изображения, если они много весят, попробовать новый формат WebP, обратиться к CDN.
2. Загрузить важное сначала
   Критически важные ресурсы, например, шрифты, изображения или видеозаписи, нужно загрузить первым делом. Для придания ресурсу приоритета есть < link rel = "preload" >.
3. Использовать сервис-воркеры
   В предыдущем пункте упоминали сервис-воркеры для выборочного кэширования, их можно использовать и для изображений и других элементов, которые редко обновляют на странице.
4. Использовать gzip или brotli
   Эти виды сжатия могут значительно уменьшить размер файлов HTML, CSS и JavaScript при их передаче между сервером и браузером. Об настройке в статье «Как ускорить сайт с помощью gzip, brotli, минификации и других способов».

Рендеринг на стороне клиента

Есть сайты, которые работают через рендеринг на стороне клиента (CSR) — то есть рендеринг страниц происходит в браузере с использованием JavaScript, все обрабатывается на стороне клиента, а не на сервере.

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

Что можно сделать:

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

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

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

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

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

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

Оптимизировать самую большую содержательную отрисовку

Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.

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

Филип Уолтон
Барри Поллард

Самый большой контент (LCP) — это один из трех показателей Core Web Vitals , который показывает, насколько быстро загружается основной контент веб-страницы. В частности, LCP измеряет время с момента, когда пользователь начинает загрузку страницы, до момента отображения самого большого изображения или текстового блока в области просмотра.

Чтобы обеспечить хорошее взаимодействие с пользователем, сайты должны стремиться к тому, чтобы LCP составляло 2,5 секунды или меньше как минимум для 75% посещений страниц.

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

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

Понимание вашей метрики LCP

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

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

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

Использование данных PageSpeed ​​Insights CrUX LCP

PageSpeed ​​Insights предоставляет доступ к данным CrUX в верхнем разделе с надписью «Узнайте, что испытывают ваши реальные пользователи ». Более подробные лабораторные данные доступны в нижнем разделе «Диагностика проблем с производительностью» . Если для вашего веб-сайта доступны данные CrUX, всегда сначала концентрируйтесь на реальных данных пользователя.

Если CrUX не предоставляет данные (например, страница с недостаточным трафиком для получения данных на уровне страницы), CrUX следует дополнять данными RUM, собранными с помощью API-интерфейсов JavaScript, запущенных на веб-странице. Это также может предоставить гораздо больше данных, чем CrUX может предоставить в качестве общедоступного набора данных. Позже в этом руководстве мы объясним, как собирать эти данные с помощью JavaScript.

PageSpeed ​​Insights отображает до четырех различных данных CrUX:

Их можно переключать с помощью элементов управления вверху и в верхней правой части этого раздела. Имейте в виду, что если URL-адрес не имеет достаточных данных для отображения на уровне URL-адреса, но имеет данные об источнике, PageSpeed ​​Insights автоматически покажет это.

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

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

Использование дополнительных метрик PageSpeed ​​Insights CrUX

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

TTFB — это время, когда посетитель начинает переходить на страницу (например, нажимая на ссылку), пока не будут получены первые байты HTML-документа. Высокий TTFB может сделать достижение LCP за 2,5 секунды затруднительным или даже невозможным.

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

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

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

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

Использование данных PageSpeed ​​Insights Lighthouse

Раздел Lighthouse в PageSpeed ​​Insights предлагает некоторые рекомендации по улучшению LCP, но сначала вам следует проверить, соответствует ли данный LCP реальным пользовательским данным, предоставленным CrUX.

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

Если оба источника данных показывают LCP, который следует улучшить, раздел Lighthouse может предоставить ценные рекомендации о способах улучшения LCP. Используйте фильтр LCP, чтобы отображать только аудиты, относящиеся к LCP:

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

Далее мы углубимся в эти подразделы.

Поломка ЛКП

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

Примечание. Визуальный обзор контекста, представленного в этом руководстве, см. в разделе «Глубокое погружение в оптимизацию LCP» от Google I/O ’22:

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

1. Исходный HTML-документ
2. Ресурс LCP (если применимо)

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

Чтобы идентифицировать ресурс LCP, вы можете использовать инструменты разработчика (такие как PageSpeed ​​Insights, описанные выше, Chrome DevTools или WebPageTest ) для определения элемента LCP . Отсюда вы можете сопоставить URL-адрес (опять же, если применимо), загруженный элементом, в сетевом водопаде всех ресурсов, загруженных страницей.

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

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

В этой таблице более подробно объясняется каждая из этих частей LCP:

* Если для отображения элемента LCP не требуется загрузка ресурса (например, если элемент представляет собой текстовый узел, отображаемый с использованием системного шрифта), это время будет равно 0.

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

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

Например, в предыдущем сетевом водопаде, если вы уменьшили размер файла нашего изображения, сильнее его сжав или переключившись на более оптимальный формат (такой как AVIF или WebP), это уменьшило бы время загрузки ресурса , но на самом деле это не улучшите LCP, потому что время просто сместится к подчасти задержки рендеринга элемента :

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

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

Оптимальное время обработки детали

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

Из четырех подразделов в названии двух есть слово «задержка». Это подсказка о том, что вы хотите, чтобы это время было как можно ближе к нулю. Две другие части связаны с сетевыми запросами, которые по своей природе требуют времени.

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

Хороший способ подумать о разбивке времени LCP:

• Подавляющее большинство времени LCP должно быть потрачено на загрузку HTML-документа и исходного кода LCP.
• В любое время до LCP, когда один из этих двух ресурсов не загружается, появляется возможность улучшения .

Как оптимизировать каждую часть

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

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

1. Устраните задержку загрузки ресурсов.

Цель этого шага — обеспечить как можно более раннюю загрузку ресурса LCP. Хотя теоретически ресурс может начать загружаться сразу после TTFB, на практике всегда существует некоторая задержка, прежде чем браузеры начнут фактически загружать ресурсы.

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

Вообще говоря, есть два фактора, которые влияют на скорость загрузки ресурса LCP:

• Когда ресурс обнаружен.
• Какой приоритет отдан ресурсу.

Оптимизация при обнаружении ресурса

Чтобы гарантировать, что ваш ресурс LCP начнет загружаться как можно раньше, очень важно, чтобы ресурс был доступен для обнаружения в исходном ответе HTML-документа сканером предварительной загрузки браузера. Например, в следующих случаях браузер может обнаружить ресурс LCP путем сканирования ответа HTML-документа:

• Элемент LCP является элементом , и его атрибуты src или srcset присутствуют в исходной HTML-разметке.
• Для элемента LCP требуется фоновое изображение CSS, но это изображение предварительно загружается через в разметке HTML (или через заголовок Link ).
• Элемент LCP — это текстовый узел, для отображения которого требуется веб-шрифт, и шрифт загружается через в разметке HTML (или через заголовок Link ).

Вот несколько примеров, когда ресурс LCP не может быть обнаружен при сканировании ответа HTML-документа:

• Элемент LCP — это , который динамически добавляется на страницу с помощью JavaScript.
• Элемент LCP лениво загружается с помощью библиотеки JavaScript, которая скрывает его атрибуты src или srcset (часто как data-src или data-srcset ).
• Для элемента LCP требуется фоновое изображение CSS.

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

Чтобы исключить ненужную задержку загрузки ресурсов, ваш ресурс LCP всегда должен быть доступен для обнаружения из источника HTML. В тех случаях, когда на ресурс ссылаются только из внешнего файла CSS или JavaScript, ресурс LCP должен быть предварительно загружен с высоким приоритетом выборки (подробнее о приоритете выборки см. в следующем разделе ); например:

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

Оптимизируйте приоритет, который дается ресурсу

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

Например, вы можете задержать изображение LCP через HTML, если установите loading=»lazy» в элементе . Использование отложенной загрузки означает, что ресурс не будет загружен до тех пор, пока макет не подтвердит, что изображение находится в области просмотра, и поэтому загрузка может начаться позже, чем в противном случае.

Предупреждение. Никогда не загружайте образ LCP отложенно, так как это всегда приведет к ненужной задержке загрузки ресурсов и окажет негативное влияние на LCP.

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

Рекомендуется установить fetchpriority=»high» для элемента , если вы считаете, что это, скорее всего, будет элемент LCP вашей страницы, но ограничьте его одним или двумя изображениями (в зависимости от обычных размеров области просмотра для настольных компьютеров и мобильных устройств), в противном случае сигнал становится бессмысленным. Вы также можете снизить приоритет изображений, которые могут находиться в начале ответа документа, но не видны из-за стиля, например изображений в слайдах карусели, которые не видны при запуске:

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

После того, как вы оптимизировали приоритет и время обнаружения ресурса LCP, ваш сетевой водопад должен выглядеть следующим образом (ресурс LCP запускается одновременно с первым ресурсом):

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

2. Устранить задержку рендеринга элемента

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

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

• Отображение всей страницы заблокировано из-за таблиц стилей или синхронных скриптов в , которые все еще загружаются.
• Ресурс LCP завершил загрузку, но элемент LCP еще не добавлен в DOM (он ожидает загрузки кода JavaScript).
• Элемент скрыт каким-то другим кодом, например библиотекой A/B-тестирования, которая все еще определяет, в каком эксперименте должен участвовать пользователь.
• Основной поток блокируется из-за длинных задач , и работу рендеринга приходится ждать, пока эти длинные задачи завершатся.

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

Уменьшите или встройте таблицы стилей, блокирующие рендеринг.

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

Чтобы это исправить, вы можете:

• встроить таблицу стилей в HTML, чтобы избежать дополнительных сетевых запросов; или,
• уменьшить размер таблицы стилей.

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

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

Некоторые рекомендации по уменьшению размера таблицы стилей:

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

Отложенный или встроенный JavaScript, блокирующий рендеринг

Почти никогда нет необходимости добавлять синхронные скрипты (скрипты без атрибутов async или defer ) в ваших страниц, и это почти всегда будет иметь негативное влияние на производительность.

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

Используйте рендеринг на стороне сервера

Рендеринг на стороне сервера (SSR) — это процесс выполнения логики клиентского приложения на сервере и ответа на запросы документов HTML с полной разметкой HTML.

С точки зрения оптимизации LCP есть два основных преимущества SSR:

• Ресурсы ваших изображений будут доступны для обнаружения из источника HTML (как обсуждалось ранее в шаге 1 ).
• Содержимое вашей страницы не потребует дополнительных запросов JavaScript для завершения, прежде чем оно сможет отображаться.

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

Подобный вариант SSR называется генерацией статического сайта (SSG) или предварительной отрисовкой . Это процесс создания HTML-страниц на этапе сборки, а не по требованию. Если предварительный рендеринг возможен в вашей архитектуре, это, как правило, лучший выбор с точки зрения производительности.

Разбивайте длинные задачи

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

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

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

3. Сократите время загрузки ресурса

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

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

Уменьшите размер ресурса

Ресурс LCP страницы (если он есть) будет либо изображением, либо веб-шрифтом. Следующие руководства подробно описывают, как уменьшить размер обоих:

• Обеспечьте оптимальный размер изображения
• Используйте современные форматы изображений
• Сжатие изображений
• Уменьшить размер веб-шрифта

Уменьшите расстояние, которое ресурс должен пройти.

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

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

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

Уменьшите конкуренцию за пропускную способность сети

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

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

Полностью исключите время работы в сети

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

А если ваш ресурс LCP является веб-шрифтом, помимо уменьшения размера веб-шрифта вам также следует подумать, нужно ли блокировать рендеринг при загрузке ресурса веб-шрифта. Если вы установите значение font-display отличное от auto или block , тогда текст всегда будет виден во время загрузки , и LCP не будет блокироваться при дополнительном сетевом запросе.

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

4. Сократите время до первого байта

Цель этого шага — как можно быстрее доставить исходный HTML-код. Этот шаг указан последним, поскольку часто именно его разработчики имеют наименьший контроль. Однако это также один из самых важных шагов, поскольку он напрямую влияет на каждый следующий шаг. Ничего не может произойти во внешнем интерфейсе, пока серверная часть не доставит первый байт контента, поэтому все, что вы можете сделать для ускорения вашего TTFB, также улучшит все остальные показатели нагрузки.

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

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

Конкретные рекомендации по этой теме см. в разделе Оптимизация TTFB .

Мониторинг разбивки LCP в JavaScript

Информация о времени для всех рассмотренных выше подразделов LCP доступна вам в JavaScript через комбинацию следующих API производительности:

• Крупнейший контентный API Paint
• API синхронизации навигации
• API синхронизации ресурсов

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

Например, на следующем снимке экрана используется метод performance.measure() из API пользовательского времени для добавления полос на дорожку «Тайминги» на панели «Производительность» Chrome DevTools.

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

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

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

Обе эти визуализации были созданы с помощью следующего кода:

const LCP_SUB_PARTS = [ 'Time to first byte', 'Resource load delay', 'Resource load time', 'Element render delay', ]; new PerformanceObserver((list) => < const lcpEntry = list.getEntries().at(-1); const navEntry = performance.getEntriesByType('navigation')[0]; const lcpResEntry = performance .getEntriesByType('resource') .filter((e) =>e.name === lcpEntry.url)[0]; // Ignore LCP entries that aren't images to reduce DevTools noise. // Comment this line out if you want to include text entries. if (!lcpEntry.url) return; // Compute the start and end times of each LCP sub-part. // WARNING! If your LCP resource is loaded cross-origin, make sure to add // the `Timing-Allow-Origin` (TAO) header to get the most accurate results. const ttfb = navEntry.responseStart; const lcpRequestStart = Math.max( ttfb, // Prefer `requestStart` (if TOA is set), otherwise use `startTime`. lcpResEntry ? lcpResEntry.requestStart || lcpResEntry.startTime : 0 ); const lcpResponseEnd = Math.max( lcpRequestStart, lcpResEntry ? lcpResEntry.responseEnd : 0 ); const lcpRenderTime = Math.max( lcpResponseEnd, // Use LCP startTime (which is the final LCP time) as sometimes // slight differences between loadTime/renderTime and startTime // due to rounding precision. lcpEntry ? lcpEntry.startTime : 0 ); // Clear previous measures before making new ones. // Note: due to a bug this does not work in Chrome DevTools. LCP_SUB_PARTS.forEach((part) => performance.clearMeasures(part)); // Create measures for each LCP sub-part for easier // visualization in the Chrome DevTools Performance panel. const lcpSubPartMeasures = [ performance.measure(LCP_SUB_PARTS[0], < start: 0, end: ttfb, >), performance.measure(LCP_SUB_PARTS[1], < start: ttfb, end: lcpRequestStart, >), performance.measure(LCP_SUB_PARTS[2], < start: lcpRequestStart, end: lcpResponseEnd, >), performance.measure(LCP_SUB_PARTS[3], < start: lcpResponseEnd, end: lcpRenderTime, >), ]; // Log helpful debug information to the console. console.log('LCP value: ', lcpRenderTime); console.log('LCP element: ', lcpEntry.element, lcpEntry.url); console.table( lcpSubPartMeasures.map((measure) => (< 'LCP sub-part': measure.name, 'Time (ms)': measure.duration, '% of LCP': `$< Math.round((1000 * measure.duration) / lcpRenderTime) / 10 >%`, >)) ); >).observe(); 

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

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

Библиотека веб-показателей включает эту разбивку в сборку атрибуции и учитывает эти соображения.

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

Отслеживайте разбивку LCP с помощью расширения Web Vitals

Краткое содержание

LCP является сложным процессом, и на его время может влиять ряд факторов. Но если учесть, что оптимизация LCP — это прежде всего оптимизация загрузки ресурса LCP, то это может существенно упростить дело.

На высоком уровне оптимизацию LCP можно свести к четырем этапам:

1. Убедитесь, что ресурс LCP начинает загружаться как можно раньше.
2. Убедитесь, что элемент LCP может отображаться, как только его ресурс завершит загрузку.
3. Максимально сократите время загрузки ресурса LCP, не жертвуя при этом качеством.
4. Доставьте исходный HTML-документ как можно быстрее.

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

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

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

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

Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.

Филип Уолтон
Барри Поллард

Примечание. Наибольшая отрисовка контента (LCP) — это важная и стабильная метрика Core Web Vital для измерения воспринимаемой скорости загрузки, поскольку она отмечает точку на временной шкале загрузки страницы, когда основной контент страницы, скорее всего, загрузился. Быстрый LCP помогает убедить пользователя в том, что страница полезна .

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

Старые метрики, такие как загрузка или DOMContentLoaded, не подходят, поскольку они не обязательно соответствуют тому, что пользователь видит на своем экране. А новые, ориентированные на пользователя показатели производительности, такие как First Contentful Paint (FCP), фиксируют только самое начало процесса загрузки. Если на странице отображается заставка или отображается индикатор загрузки, для пользователя этот момент не очень актуален.

Раньше мы рекомендовали такие показатели производительности, как «Первая значимая отрисовка» (FMP) и «Индекс скорости» (SI) (оба доступны в Lighthouse), чтобы помочь лучше понять процесс загрузки после первоначальной отрисовки, но эти показатели сложны и их трудно объяснить. , и часто ошибаются — это означает, что они по-прежнему не определяют, когда загрузился основной контент страницы.

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

Что такое ЛКП?

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

Что такое хороший показатель LCP?

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

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

Какие элементы учитываются?

Как указано в API Largest Contentful Paint , типы элементов, рассматриваемых для Largest Contentful Paint, следующие:

• элементы
• Элементы внутри элемента
• Элементы с изображением постера (используется время загрузки изображения постера)
• Элемент с фоновым изображением, загруженным с помощью функции url() (в отличие от градиента CSS ).
• Элементы уровня блока , содержащие текстовые узлы или другие дочерние элементы текстовых элементов строкового уровня.
• Первый кадр, нарисованный для автоматического воспроизведения элементов (по состоянию на август 2023 г. ).
• Первый кадр формата анимированного изображения, например анимированного GIF-файла (по состоянию на август 2023 г. ).

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

Помимо рассмотрения только некоторых элементов, применяются определенные эвристические методы для исключения определенных элементов, которые могут показаться пользователям «несодержательными». Для браузеров на базе Chromium к ним относятся:

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

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

Эти «содержательные» эвристики могут отличаться от эвристики, используемой First Contentful Paint (FCP) , которая может учитывать некоторые из этих элементов, такие как изображения-заполнители или изображения полного окна просмотра, даже если они не могут быть кандидатами на LCP. Несмотря на то, что оба используют слово «содержательный» в своем названии, цель этих показателей разная. FCP измеряет, когда какой-либо контент отображается на экране, а LCP — когда отображается основной контент , поэтому LCP должен быть более избирательным.

Как определяется размер элемента?

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

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

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

Для всех элементов любые поля, отступы или границы, примененные с помощью CSS, не учитываются.

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

Когда сообщается о самой насыщенной краске?

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

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

Например, на странице с текстом и главным изображением браузер может сначала просто отобразить текст, после чего браузер отправит запись largest-contentful-paint свойство element которой, скорее всего, будет ссылаться на

или . Позже, как только главное изображение завершит загрузку, будет отправлена ​​вторая largest-contentful-paint , и ее свойство element будет ссылаться на .

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

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

Если элемент, который на данный момент является самым большим содержимым, удаляется из области просмотра (или даже удаляется из DOM), он останется самым большим содержимым элементом, пока не будет отображен более крупный элемент.

Примечание. До версии Chrome 88 удаленные элементы не считались элементами с наибольшим содержимым, а удаление текущего кандидата приводило к отправке новой записи largest-contentful-paint . Однако из-за популярных шаблонов пользовательского интерфейса, таких как карусели изображений, в которых часто удаляются элементы DOM, метрика была обновлена, чтобы более точно отражать впечатления пользователей. Более подробную информацию можно найти в СИСТЕМЕ ИЗМЕНЕНИЙ .

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

В целях анализа вам следует сообщать в свою аналитическую службу только самую последнюю отправленную PerformanceEntry .

Внимание: поскольку пользователи могут открывать страницы на фоновой вкладке, возможно, что записи largest-contentful-paint не будут отправлены до тех пор, пока пользователь не выделит вкладку, что может произойти намного позже, чем при первой загрузке. Инструменты Google, измеряющие LCP, не сообщают об этом показателе, если страница загружалась в фоновом режиме, поскольку он не отражает воспринимаемое пользователем время загрузки.

Время загрузки и время рендеринга

По соображениям безопасности метка времени рендеринга изображений не отображается для изображений из разных источников, у которых отсутствует заголовок Timing-Allow-Origin . Вместо этого отображается только время загрузки (поскольку оно уже доступно через многие другие веб-API).

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

Если это возможно, всегда рекомендуется устанавливать заголовок Timing-Allow-Origin , чтобы ваши метрики были более точными.

Как обрабатываются изменения макета и размера элемента?

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

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

Примеры

Вот несколько примеров того, когда на нескольких популярных веб-сайтах происходит самая большая содержательная отрисовка:

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

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

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

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

Как измерить ЛКП

LCP можно измерить в лаборатории или в полевых условиях , и он доступен в следующих инструментах:

Полевые инструменты

• Отчет об опыте использования Chrome
• Статистика PageSpeed
• Search Console (отчет «Основные веб-показатели»)
• JavaScript-библиотека web-vitals

Лабораторные инструменты

• Инструменты разработчика Chrome
• Маяк
• Статистика PageSpeed
• Веб-ПейджТест

Измерение LCP в JavaScript

Чтобы измерить LCP в JavaScript, вы можете использовать Largest Contentful Paint API . В следующем примере показано, как создать PerformanceObserver , который прослушивает записи с largest-contentful-paint и записывает их в консоль.

new PerformanceObserver((entryList) => < for (const entry of entryList.getEntries()) < console.log('LCP candidate:', entry.startTime, entry); >>).observe(); 

Предупреждение: этот код показывает, как регистрировать в консоли записи largest-contentful-paint , но измерение LCP в JavaScript сложнее. Подробности смотрите ниже:

В приведенном выше примере каждая зарегистрированная запись largest-contentful-paint представляет текущего кандидата LCP. Обычно значение startTime последней созданной записи является значением LCP, однако это не всегда так. Не все записи largest-contentful-paint действительны для измерения LCP.

В следующем разделе перечислены различия между тем, что сообщает API, и тем, как рассчитывается метрика.

Различия между метрикой и API

• API будет отправлять записи largest-contentful-paint для страниц, загруженных на фоновую вкладку, но эти страницы следует игнорировать при расчете LCP.
• API продолжит отправлять записи largest-contentful-paint после того, как страница была переведена в фоновый режим, но эти записи следует игнорировать при вычислении LCP (элементы могут учитываться только в том случае, если страница все время находилась на переднем плане).
• API не сообщает о записях largest-contentful-paint когда страница восстанавливается из обратного/прямого кэша , но в этих случаях следует измерять LCP, поскольку пользователи воспринимают их как отдельные посещения страниц.
• API не учитывает элементы внутри iframe, но учитывает метрику, поскольку они являются частью взаимодействия пользователя со страницей. На страницах с LCP внутри iframe — например, на постере во встроенном видео — это будет отображаться как разница между CrUX и RUM . Чтобы правильно измерить LCP, вам следует их учитывать. Подкадры могут использовать API для передачи своих записей largest-contentful-paint в родительский фрейм для агрегирования.

Вместо того, чтобы запоминать все эти тонкие различия, разработчики могут использовать библиотеку JavaScript web-vitals для измерения LCP, которая обрабатывает эти различия за вас (где это возможно):

import from 'web-vitals'; // Measure and log LCP as soon as it's available. onLCP(console.log); 

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

Примечание. В некоторых случаях (например, в iframe из разных источников) невозможно измерить LCP в JavaScript. Подробности смотрите в разделе ограничений библиотеки web-vitals .

Что, если самый большой элемент не является самым важным?

В некоторых случаях наиболее важный элемент (или элементы) на странице не совпадает с самым большим элементом, и вместо этого разработчики могут быть более заинтересованы в измерении времени рендеринга этих других элементов. Это возможно с помощью Element Timing API , как описано в статье о пользовательских метриках .

Как улучшить ЛКП

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

Дополнительные ресурсы

• Уроки, извлеченные из мониторинга производительности в Chrome,Энни Салливан на Performance.now() (2019)

ИЗМЕНЕНИЯ

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

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

Если у вас есть отзывы об этих показателях, вы можете оставить их в группе Google web-vitals-feedback .

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

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