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

Brendan Kenny

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

Классический совет LCP: уменьшите размер изображений!

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

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

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

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

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

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

Разбивка по частям LCP

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

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

Цитируя эту статью , подразделы:

Время до первого байта (TTFB)

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

Задержка загрузки ресурса

Время между TTFB и моментом, когда браузер начинает загрузку ресурса LCP. Если элемент LCP не требует загрузки ресурса для рендеринга, это время равно 0 .

Длительность загрузки ресурса

Продолжительность времени, необходимая для загрузки самого ресурса LCP. Если элемент LCP не требует загрузки ресурса для рендеринга, это время равно 0 .

Задержка рендеринга элемента

Время между завершением загрузки ресурса LCP и полной отрисовкой элемента LCP.

Реальные данные о производительности навигации

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

Как и в случае с Core Web Vitals, мы взяли 75-й процентиль (p75) каждой подчасти LCP для каждого источника в наборе данных CrUX, в результате чего получилось четыре распределения значений p75 (по одному для каждой подчасти). Чтобы обобщить эти распределения, мы взяли медиану этих значений по всем источникам для каждой из четырех частей LCP.

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

Уменьшить размер изображения LCP? На этот раз с данными

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

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

Большинство источников с плохим LCP тратят менее 10% времени своего LCP p75 на загрузку образа LCP.

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

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

Время до первого байта (TTFB)

Для навигации, которая отправляет сетевой запрос, TTFB всегда занимает некоторое время. Требуется время, чтобы выполнить поиск DNS и установить соединение. И физику не победить: запрос должен пройти через реальный мир по проводам и оптическим кабелям, чтобы достичь сервера, а затем ответ должен вернуться обратно. Даже медианное происхождение с хорошим LCP тратит более полсекунды на TTFB на своем 75-м процентиле.

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

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

Подробнее см. в руководстве «Оптимизация TTFB» .

Задержка загрузки ресурсов, упущенный из виду виновник медленного LCP

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

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

Средний сайт с плохим LCP тратит почти в четыре раза больше времени на ожидание начала загрузки образа LCP, чем на его фактическую загрузку , ожидая 1,3 секунды между TTFB и запросом изображения. Это более половины 2,5-секундного бюджета LCP, потраченного на одну подчасть.

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

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

Главное — как можно скорее сообщить браузеру, каким будет LCP, чтобы он мог начать его загрузку, даже до того, как для него найдется место в макете страницы. Для этого существует несколько инструментов, например, классический тег <img> в HTML, чтобы сканер предварительной загрузки мог быстро найти его и начать загрузку, или тег <link rel="preload"> (или HTTP-заголовок) для изображения, которые не будут <img> .

Также важно помочь браузеру определить, каким ресурсам следует отдать приоритет. Это особенно верно, если ваша страница делает много запросов во время загрузки страницы, поскольку браузер часто не знает, каким будет элемент LCP, до тех пор, пока многие из этих ресурсов не загрузятся и не произойдет макет. Аннотирование вероятного элемента LCP атрибутом fetchpriority="high" (и избежание loading="lazy" ) дает браузеру понять, что нужно немедленно начать загрузку ресурса.

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

Задержка рендеринга

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

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

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

Проверьте все эти подразделы

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

Для сбора этих данных в полевых условиях сборка атрибуции библиотеки web-vitals включает в себя время для подчастей LCP. Отчет об опыте пользователя Chrome (CrUX) еще не включает все эти данные, но в нем есть записи для TTFB и LCP, так что это только начало. Мы надеемся в будущем включить данные, использованные для этого поста, в CruX, так что следите за новостями по этому поводу.

Для локального тестирования частей LCP попробуйте расширение Web Vitals или фрагмент JavaScript из этой статьи . Lighthouse также включает разбивку в свой аудит «Самый большой элемент Contentful Paint» . Дополнительные советы по подразделам LCP можно найти на панели DevTools Performance, которая появится в ближайшее время .

Brendan Kenny

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

Классический совет LCP: уменьшите размер изображений!

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

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

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

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

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

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

Разбивка по частям LCP

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

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

Цитируя эту статью , подразделы:

Время до первого байта (TTFB)

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

Задержка загрузки ресурса

Время между TTFB и моментом, когда браузер начинает загрузку ресурса LCP. Если элемент LCP не требует загрузки ресурса для рендеринга, это время равно 0 .

Длительность загрузки ресурса

Продолжительность времени, необходимая для загрузки самого ресурса LCP. Если элемент LCP не требует загрузки ресурса для рендеринга, это время равно 0 .

Задержка рендеринга элемента

Время между завершением загрузки ресурса LCP и полной отрисовкой элемента LCP.

Реальные данные о производительности навигации

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

Как и в случае с Core Web Vitals, мы взяли 75-й процентиль (p75) каждой подчасти LCP для каждого источника в наборе данных CrUX, в результате чего получилось четыре распределения значений p75 (по одному для каждой подчасти). Чтобы обобщить эти распределения, мы взяли медиану этих значений по всем источникам для каждой из четырех частей LCP.

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

Уменьшить размер образа LCP? На этот раз с данными

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

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

Большинство источников с плохим LCP тратят менее 10% времени своего LCP p75 на загрузку образа LCP.

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

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

Время до первого байта (TTFB)

Для навигации, которая отправляет сетевой запрос, TTFB всегда занимает некоторое время. Требуется время, чтобы выполнить поиск DNS и установить соединение. И физику не победить: запрос должен пройти через реальный мир по проводам и оптическим кабелям, чтобы достичь сервера, а затем ответ должен вернуться обратно. Даже медианное происхождение с хорошим LCP тратит более полсекунды на TTFB на своем 75-м процентиле.

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

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

Подробнее см. в руководстве «Оптимизация TTFB» .

Задержка загрузки ресурсов, упущенный из виду виновник медленного LCP

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

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

Средний сайт с плохим LCP тратит почти в четыре раза больше времени на ожидание начала загрузки образа LCP, чем на его фактическую загрузку , ожидая 1,3 секунды между TTFB и запросом изображения. Это более половины 2,5-секундного бюджета LCP, потраченного на одну подчасть.

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

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

Главное — как можно скорее сообщить браузеру, каким будет LCP, чтобы он мог начать его загрузку, даже до того, как для него найдется место в макете страницы. Для этого существует несколько инструментов, например, классический тег <img> в HTML, чтобы сканер предварительной загрузки мог быстро найти его и начать загрузку, или тег <link rel="preload"> (или HTTP-заголовок) для изображения, которые не будут <img> .

Также важно помочь браузеру определить, каким ресурсам следует отдать приоритет. Это особенно верно, если ваша страница делает много запросов во время загрузки страницы, поскольку браузер часто не знает, каким будет элемент LCP, до тех пор, пока многие из этих ресурсов не загрузятся и не произойдет макет. Аннотирование вероятного элемента LCP атрибутом fetchpriority="high" (и избежание loading="lazy" ) дает браузеру понять, что нужно немедленно начать загрузку ресурса.

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

Задержка рендеринга

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

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

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

Проверьте все эти подразделы

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

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

Для локального тестирования частей LCP попробуйте расширение Web Vitals или фрагмент JavaScript из этой статьи . Lighthouse также включает разбивку в свой аудит «Самый крупный элемент рисования контента» . Дополнительные советы по подразделам LCP можно найти на панели DevTools Performance, которая появится в ближайшее время .