Пошаговое руководство по анализу LCP и выявлению ключевых областей для улучшения.
Опубликовано: 30 апреля 2020 г., Последнее обновление: 31 марта 2025 г.
Показатель Largest Contentful Paint (LCP) — один из трех основных показателей Web Vitals , отражающий скорость загрузки основного контента веб-страницы. В частности, LCP измеряет время от момента начала загрузки страницы пользователем до момента отображения самого большого изображения или текстового блока в видимой области экрана.
Для обеспечения удобного пользовательского опыта сайты должны стремиться к тому, чтобы время отклика страницы составляло не более 2,5 секунд как минимум для 75% посещений.
На скорость загрузки и отображения веб-страницы браузером может влиять множество факторов, и задержки по любому из них могут существенно повлиять на LCP.
Редко когда быстрое исправление одной части страницы приводит к существенному улучшению LCP (показателя загрузки страницы). Для улучшения LCP необходимо проанализировать весь процесс загрузки и убедиться, что каждый его этап оптимизирован.
Понимание вашего показателя LCP
Прежде чем оптимизировать LCP, разработчикам следует попытаться понять, существует ли у них вообще проблема с LCP и каковы масштабы этой проблемы.
Показатель LCP можно измерить с помощью различных инструментов, и не все из них измеряют LCP одинаково. Чтобы понять LCP реальных пользователей, следует рассматривать то, что испытывают реальные пользователи, а не то, что показывают лабораторные инструменты, такие как Lighthouse , или локальное тестирование. Эти лабораторные инструменты могут предоставить много информации для объяснения и улучшения LCP, но следует помнить, что одних только лабораторных тестов может быть недостаточно для полного отражения реального опыта пользователей.
Данные LCP, основанные на информации от реальных пользователей, могут быть получены с помощью инструментов мониторинга реальных пользователей (RUM), установленных на сайте, или с помощью отчета Chrome User Experience Report (CrUX) , который собирает анонимные данные от реальных пользователей Chrome для миллионов веб-сайтов.
Использование данных CrUX LCP в инструментах разработчика Chrome
В панели «Производительность» инструментов разработчика Chrome в режиме реального времени отображается локальный LCP, а в разделе « Аналитика » трассировки производительности — информация о времени выполнения отдельных частей LCP (которую мы объясним чуть позже).
Наложив данные полей на панель «Производительность», вы можете оценить, есть ли у страницы реальные проблемы с LCP, возникающие у пользователей, и адаптировать настройки локальной среды для более эффективного воспроизведения и отладки этих проблем.
Использование данных PageSpeed Insights CrUX LCP
В верхней части страницы, в разделе « Узнайте, с чем сталкиваются ваши реальные пользователи», PageSpeed Insights предоставляет доступ к данным CrUX. Более подробные данные, полученные в ходе лабораторных испытаний, доступны в нижней части страницы, в разделе « Диагностика проблем с производительностью» . Если для вашего сайта доступны данные CrUX, всегда в первую очередь сосредоточьтесь на данных реальных пользователей.
PageSpeed Insights отображает до четырех различных типов данных CrUX:
- Мобильные данные для этого URL
- Данные для настольных компьютеров по этому URL-адресу
- Мобильный интернет для всего региона Origin.
- Данные для настольных компьютеров по всему Origin.
Вы можете переключать эти параметры в элементах управления вверху и в правом верхнем углу этого раздела. Если URL-адрес не содержит достаточно данных для отображения на уровне URL, но содержит данные об источнике, PageSpeed Insights всегда отображает данные об источнике.
LCP для всего исходного сайта может значительно отличаться от LCP отдельной страницы в зависимости от способа загрузки LCP на этой странице по сравнению с другими страницами на этом же сайте. На него также может влиять способ перехода посетителей на эти страницы. Главные страницы, как правило, посещают новые пользователи, поэтому они часто загружаются «в холодном виде», без кэшированного контента, и, следовательно, часто являются самыми медленными страницами на сайте.
Анализ четырех различных категорий данных CrUX поможет понять, является ли проблема с LCP специфичной для данной страницы или же она затрагивает весь сайт. Аналогичным образом, это позволит определить, какие типы устройств имеют проблемы с LCP.
Использование дополнительных метрик PageSpeed Insights CrUX
Тем, кто стремится оптимизировать LCP, следует также использовать показатели First Contentful Paint (FCP) и Time to First Byte (TTFB) , которые являются хорошими диагностическими метриками и могут предоставить ценную информацию о LCP.
TTFB — это время от начала перехода посетителя на страницу (например, до момента получения первых байтов HTML-документа). Высокое значение TTFB может затруднить или даже сделать невозможным достижение показателя LCP в 2,5 секунды.
Высокое значение TTFB может быть вызвано многократными перенаправлениями сервера, посетителями, находящимися далеко от ближайшего сервера сайта, посетителями, находящимися в условиях плохого сетевого соединения, или невозможностью использования кэшированного контента из-за параметров запроса.
После начала отрисовки страницы может произойти первоначальная отрисовка (например, изменение цвета фона), за которой последует появление некоторого контента (например, заголовка сайта). Появление первоначального контента измеряется показателем FCP (Facebook, Facebook, Capture). Разница между FCP и другими метриками может быть очень показательной.
Большая разница между TTFB и FCP может указывать на то, что браузеру необходимо загрузить много ресурсов, блокирующих рендеринг. Это также может быть признаком того, что ему приходится выполнять большой объем работы для отображения значимого контента — классический признак сайта, который в значительной степени полагается на рендеринг на стороне клиента.
Большая разница между FCP и LCP указывает на то, что ресурс LCP либо недоступен для немедленного приоритетного отображения в браузере (например, текст или изображения, управляемые JavaScript, а не имеющиеся в исходном HTML-коде), либо браузер выполняет другую работу, прежде чем сможет отобразить контент LCP.
Использование данных PageSpeed Insights Lighthouse
Раздел Lighthouse в PageSpeed Insights предлагает некоторые рекомендации по улучшению LCP (показателя эффективности использования страницы), но сначала следует проверить, насколько полученный LCP в целом соответствует реальным данным пользователей, предоставленным CrUX. Если Lighthouse и CrUX не совпадают, то CrUX, вероятно, предоставляет более точную картину вашего пользовательского опыта. Прежде чем предпринимать какие-либо действия, убедитесь, что данные CrUX относятся к вашей странице, а не к исходному сайту.
Если и Lighthouse, и CrUX показывают значения LCP, требующие улучшения, раздел Lighthouse может предоставить ценные рекомендации по улучшению LCP. Используйте фильтр LCP, чтобы отображать только аудиты, относящиеся к LCP, следующим образом:
Помимо возможностей для улучшения, имеется диагностическая информация, которая может помочь в диагностике проблемы. Диагностика элемента Largest Contentful Paint (LCP) показывает полезную разбивку различных временных параметров, составляющих LCP:
Типы ресурсов LCP и их подкомпоненты также доступны в CrUX .
Далее мы подробно рассмотрим эти подразделы.
разборка LCP
Оптимизация LCP может оказаться более сложной задачей, если PageSpeed Insights не дает ответа на вопрос, как улучшить этот показатель. В сложных задачах, как правило, лучше разбить их на более мелкие, более управляемые задачи и решать каждую отдельно.
В этом разделе представлена методология разбиения LCP на наиболее важные подкомпоненты, а затем приводятся конкретные рекомендации и лучшие практики по оптимизации каждого из них.
Обычно при загрузке большинства страниц выполняется ряд сетевых запросов, но для выявления возможностей улучшения LCP следует начать с рассмотрения всего двух из них:
- Исходный HTML-документ
- Ресурс LCP (если применимо)
Хотя другие запросы на странице могут влиять на LCP, эти два запроса — а именно, время начала и окончания работы ресурса LCP — показывают, оптимизирована ли ваша страница для LCP.
Для идентификации ресурса LCP можно использовать инструменты разработчика (например, PageSpeed Insights, о которых говорилось ранее, Chrome DevTools или WebPageTest ), чтобы определить элемент LCP . Затем можно сопоставить URL-адрес (если применимо), загруженный этим элементом, с сетевой диаграммой загрузки всех ресурсов, загруженных страницей.
Например, на следующей визуализации эти ресурсы выделены на диаграмме водопада сети при типичной загрузке страницы, где элемент LCP требует запроса изображения для отображения.
Для хорошо оптимизированной страницы желательно, чтобы запрос ресурса LCP начинался как можно раньше, а элемент LCP отображался как можно быстрее после завершения загрузки ресурса LCP. Чтобы наглядно показать, соответствует ли конкретная страница этому принципу, можно разбить общее время LCP на следующие подчасти:
- Время до первого байта (TTFB)
- Время от момента, когда пользователь инициирует загрузку страницы, до момента, когда браузер получает первый байт ответа в виде HTML-документа.
- Задержка загрузки ресурсов
- Время между TTFB и моментом, когда браузер начинает загрузку ресурса LCP. Если элемент LCP не требует загрузки ресурса для отображения (например, если элемент представляет собой текстовый узел, отображаемый с использованием системного шрифта), это время равно 0.
- Продолжительность загрузки ресурсов
- Время, необходимое для загрузки самого ресурса LCP. Если элемент LCP не требует загрузки ресурса для отображения, это время равно 0.
- Задержка отрисовки элемента
- Время между завершением загрузки ресурса LCP и полной отрисовкой элемента LCP.
Значение LCP для каждой страницы можно разбить на четыре подчасти. Между ними нет ни пересечений, ни пробелов. В совокупности они составляют общее время LCP.
При оптимизации LCP полезно попытаться оптимизировать эти подчасти по отдельности. Но также важно помнить, что необходимо оптимизировать их все. В некоторых случаях оптимизация, примененная к одной части, не улучшит LCP, а просто перенесет сэкономленное время на другую часть.
Например, в предыдущей диаграмме водопада сети, если уменьшить размер файла изображения за счет более сильного сжатия или перехода на более оптимальный формат (например, AVIF или WebP), это сократит время загрузки ресурсов , но фактически не улучшит LCP, поскольку время просто переместится в подчасть задержки рендеринга элемента :
Причина этого в том, что на этой странице элемент LCP скрыт до завершения загрузки кода JavaScript, после чего всё отображается сразу.
Этот пример наглядно демонстрирует необходимость оптимизации всех этих подкомпонентов для достижения наилучших результатов LCP.
Оптимальное время выполнения отдельных этапов
Для оптимизации каждой подчасти LCP важно понимать, каково идеальное расположение этих подчастей на хорошо оптимизированной странице.
Из четырех подразделов в названиях двух присутствует слово «задержка». Это указывает на то, что вам нужно максимально приблизить эти значения ко времени к нулю. Два других подраздела связаны с сетевыми запросами, которые по своей природе требуют времени.
Обратите внимание, что эти временные показатели являются рекомендациями, а не строгими правилами. Если время задержки на ваших страницах постоянно находится в пределах 2,5 секунд, то относительные пропорции не имеют особого значения. Но если вы тратите много лишнего времени в любой из этих «задержек», то постоянно укладываться в целевые 2,5 секунды будет очень сложно.
Хороший способ представить себе структуру времени LCP — это:
- Большую часть времени, затрачиваемого на LCP, следует посвятить загрузке HTML-документа и исходного кода LCP.
- Любой период перед запуском LCP, когда один из этих двух ресурсов не загружается, представляет собой возможность для улучшения ситуации .
Как оптимизировать каждую часть
Теперь, когда вы понимаете, как должны располагаться элементы каждого из подразделов LCP на хорошо оптимизированной странице, вы можете начать оптимизировать свои собственные страницы.
В следующих четырех разделах будут представлены рекомендации и лучшие практики по оптимизации каждой части. Они изложены по порядку, начиная с тех оптимизаций, которые, вероятно, окажут наибольшее влияние.
1. Устранить задержку загрузки ресурсов.
Цель этого шага — обеспечить максимально раннюю загрузку ресурса LCP. Хотя теоретически загрузка ресурса может начаться сразу после TTFB, на практике всегда существует некоторая задержка, прежде чем браузеры начнут загрузку ресурсов.
Хорошее эмпирическое правило заключается в том, что ваш ресурс LCP должен начинать загружаться одновременно с первым ресурсом, загружаемым на этой странице. Или, другими словами, если ресурс LCP начинает загружаться позже, чем первый ресурс, то есть возможность для улучшения.
В целом, на скорость загрузки ресурса LCP влияют два фактора:
- Когда ресурс будет обнаружен.
- Какой приоритет отдается данному ресурсу?
Оптимизируйте процесс, как только ресурс будет обнаружен.
Чтобы обеспечить максимально раннюю загрузку ресурса LCP, крайне важно, чтобы он был доступен для сканирования предварительной загрузки браузером в исходном HTML-документе. Например, в следующих случаях браузер может обнаружить ресурс LCP, просканировав HTML-документ:
- Элемент LCP представляет собой элемент
<img>, и его атрибутыsrcилиsrcsetприсутствуют в исходной HTML-разметке. - Для элемента LCP требуется фоновое изображение CSS , но это изображение предварительно загружается с помощью
<link rel="preload">в HTML-разметке (или с помощью заголовкаLink). - Элемент LCP представляет собой текстовый узел, для отображения которого требуется веб-шрифт, загружаемый с помощью
<link rel="preload">в HTML-разметке (или с помощью заголовкаLink).
Вот несколько примеров, когда ресурс LCP не удается обнаружить при сканировании ответа HTML-документа:
- Элемент LCP представляет собой изображение
<img>, которое динамически добавляется на страницу с помощью JavaScript. - Элемент LCP загружается с отложенной загрузкой с помощью библиотеки JavaScript, которая скрывает его атрибуты
srcилиsrcset(часто какdata-srcилиdata-srcset). - Для элемента LCP требуется фоновое изображение, созданное с помощью CSS.
В каждом из этих случаев браузеру необходимо запустить скрипт или применить таблицу стилей — что обычно включает в себя ожидание завершения сетевых запросов — прежде чем он сможет обнаружить ресурс LCP и начать его загрузку. Это никогда не является оптимальным решением.
Чтобы избежать ненужных задержек при загрузке ресурсов, ваш LCP-ресурс должен быть доступен из HTML-кода. В случаях, когда на ресурс ссылаются только из внешнего CSS или JavaScript файла, LCP-ресурс следует предварительно загружать с высоким приоритетом выборки , например:
<!-- Load the stylesheet that will reference the LCP image. -->
<link rel="stylesheet" href="/path/to/styles.css">
<!-- Preload the LCP image with a high fetchpriority so it starts loading with the stylesheet. -->
<link rel="preload" fetchpriority="high" as="image" href="/path/to/hero-image.webp" type="image/webp">
Оптимизировать приоритет, присваиваемый ресурсу.
Даже если ресурс LCP можно обнаружить в HTML-разметке, он все равно может начать загружаться не так рано, как первый ресурс. Это может произойти, если эвристические алгоритмы приоритета сканера предварительной загрузки браузера не распознают важность этого ресурса или если они определяют, что другие ресурсы более важны.
Например, вы можете отложить загрузку изображения LCP с помощью HTML, если установите loading="lazy" для элемента <img> . Использование отложенной загрузки означает, что ресурс не будет загружен до тех пор, пока макет не подтвердит, что изображение находится в области просмотра, и поэтому загрузка может начаться позже, чем это было бы в противном случае.
Даже без отложенной загрузки изображения изначально не загружаются браузерами с наивысшим приоритетом, поскольку они не являются ресурсами, блокирующими отрисовку. Вы можете указать браузеру, какие ресурсы наиболее важны, используя атрибут fetchpriority для ресурсов, которым может быть полезен более высокий приоритет:
<img fetchpriority="high" src="/path/to/hero-image.webp">
Если вы считаете, что элемент <img> с высокой приоритетностью (LCP) является элементом fetchpriority="high" , это хорошая идея. Однако установка высокого приоритета для более чем одного или двух изображений делает использование высоких приоритетов неэффективным в снижении LCP.
Вы также можете понизить приоритет изображений, которые могут отображаться в начале ответа документа, но не видны из-за стилизации, например, изображений в слайдах карусели, которые не отображаются при запуске:
<img fetchpriority="low" src="/path/to/carousel-slide-3.webp">
Снижение приоритета определенных ресурсов может высвободить больше пропускной способности для тех ресурсов, которые в этом нуждаются больше, — но будьте осторожны. Всегда проверяйте приоритет ресурсов в инструментах разработчика и тестируйте изменения с помощью лабораторных и полевых инструментов.
После оптимизации приоритета и времени обнаружения ресурсов LCP, диаграмма потоков сети должна выглядеть следующим образом (при этом ресурс LCP должен запускаться одновременно с первым ресурсом):
2. Устранить задержку рендеринга элемента.
Цель этого шага — обеспечить возможность немедленного отображения элемента LCP после завершения загрузки его ресурса, независимо от того, когда это произойдет.
Основная причина, по которой элемент LCP не сможет отобразиться сразу после завершения загрузки ресурса, заключается в том, что отрисовка блокируется по какой-либо другой причине:
- Отображение всей страницы блокируется из-за таблиц стилей или синхронных скриптов в разделе
<head>, которые всё ещё загружаются. - Загрузка ресурса LCP завершена, но элемент LCP еще не добавлен в DOM (он ожидает загрузки некоторого кода JavaScript).
- Этот элемент скрыт другим кодом, например, библиотекой для A/B-тестирования, которая всё ещё определяет, в каком эксперименте должен участвовать пользователь.
- Основной поток заблокирован из-за длительных задач , и отрисовка должна подождать, пока эти длительные задачи не завершатся.
В следующих разделах объясняется, как устранить наиболее распространенные причины ненужной задержки отрисовки элементов.
Уменьшите или встройте таблицы стилей, блокирующие отрисовку.
Таблицы стилей, загружаемые из HTML-разметки, блокируют отрисовку всего последующего контента, что хорошо, поскольку обычно нежелательно отображать HTML-код без стилей. Однако, если таблица стилей настолько велика, что её загрузка занимает значительно больше времени, чем ресурс LCP, то она будет препятствовать отрисовке элемента LCP — даже после того, как его ресурс завершит загрузку, как показано в этом примере:
Чтобы это исправить, у вас есть два варианта:
- встроить таблицу стилей в HTML, чтобы избежать дополнительных сетевых запросов; или же
- Уменьшить размер таблицы стилей.
В целом, встраивание таблицы стилей рекомендуется только в том случае, если она небольшая, поскольку встроенный контент в HTML не сможет воспользоваться преимуществами кэширования при последующих загрузках страницы. Если таблица стилей настолько велика, что её загрузка занимает больше времени, чем ресурс LCP, то встраивание её вряд ли будет целесообразным.
В большинстве случаев лучший способ гарантировать, что таблица стилей не будет блокировать отрисовку элемента LCP, — это уменьшить его размер так, чтобы он был меньше ресурса LCP. Это должно гарантировать, что он не станет узким местом для большинства посещений.
Вот несколько рекомендаций по уменьшению размера таблицы стилей:
- Удалите неиспользуемые правила CSS : используйте инструменты разработчика Chrome, чтобы найти правила CSS, которые не используются и которые потенциально можно удалить (или отложить).
- Отложите загрузку некритичных CSS-стилей : разделите таблицу стилей на стили, необходимые для первоначальной загрузки страницы, и стили, которые можно загружать постепенно.
- Сжимайте и минимизируйте CSS : для критически важных стилей убедитесь, что вы максимально уменьшаете их размер при передаче .
Отложенная отрисовка или встраивание блокирующего рендеринг JavaScript
Практически никогда не возникает необходимости добавлять синхронные скрипты (скрипты без атрибутов async или defer ) в раздел <head> ваших страниц, и это почти всегда негативно сказывается на производительности.
В тех случаях, когда JavaScript-код необходимо выполнить как можно раньше после загрузки страницы, лучше всего встроить его непосредственно в код, чтобы избежать задержки рендеринга в ожидании следующего сетевого запроса. Однако, как и в случае с таблицами стилей, встраивать скрипты следует только в том случае, если они очень маленькие.
<head> <script src="/path/to/main.js"></script> </head>
<head>
<script>
// Inline script contents directly in the HTML.
// IMPORTANT: only do this for very small scripts.
</script>
</head>Используйте рендеринг на стороне сервера.
Рендеринг на стороне сервера (SSR) — это процесс выполнения логики вашего клиентского приложения на сервере и ответа на запросы HTML-документов с полной HTML-разметкой.
С точки зрения оптимизации LCP, у SSR есть два основных преимущества:
- Ваши изображения будут доступны из исходного HTML-кода (как обсуждалось ранее в шаге 1 ).
- Для отображения содержимого вашей страницы не потребуется выполнение дополнительных запросов JavaScript.
Главный недостаток SSR заключается в том, что он требует дополнительного времени обработки на сервере, что может замедлить время отклика (TTFB). Однако обычно это оправданный компромисс, поскольку время обработки на сервере находится под вашим контролем, в то время как возможности сети и устройств ваших пользователей — нет.
Аналогом SSR является генерация статических сайтов (SSG) или предварительная отрисовка . Это процесс генерации HTML-страниц на этапе сборки, а не по запросу. Если предварительная отрисовка возможна в вашей архитектуре, это, как правило, лучший выбор с точки зрения производительности.
Разбивайте длительные задачи на части.
Даже если вы следовали приведенным выше советам, и ваш JavaScript-код не блокирует отрисовку и не отвечает за рендеринг элементов, он все равно может задерживать LCP.
Наиболее распространенная причина этого — загрузка больших JavaScript-файлов, которые необходимо обработать и выполнить в основном потоке браузера. Это означает, что даже если ваш графический ресурс полностью загружен, ему, возможно, придется подождать, пока завершится выполнение стороннего скрипта, прежде чем он сможет отобразиться.
Сегодня все браузеры отрисовывают изображения в основном потоке, а это значит, что всё, что блокирует основной поток, может привести к ненужной задержке отрисовки элементов .
3. Сокращение продолжительности нагрузки на ресурсы.
Цель этого шага — сократить время, затрачиваемое на передачу байтов ресурса по сети на устройство пользователя. В общем, это можно сделать четырьмя способами:
- Уменьшите размер ресурса.
- Сократите расстояние, которое должен преодолеть ресурс.
- Снизить конкуренцию за пропускную способность сети.
- Полностью исключите использование сетевого времени.
Уменьшите размер ресурса.
Ресурс LCP страницы (если он есть) будет представлять собой либо изображение, либо веб-шрифт. В следующих руководствах подробно описано, как уменьшить размер и того, и другого:
- Отображайте изображение оптимального размера.
- Используйте современные форматы изображений.
- Сжать изображения
- Уменьшите размер веб-шрифта.
Сократите расстояние, которое должен преодолеть ресурс.
Помимо уменьшения размера ресурса, вы также можете сократить время загрузки, разместив серверы как можно ближе к пользователям. И лучший способ сделать это — использовать сеть доставки контента (CDN).
В частности, сети доставки изображений (CDN) особенно полезны, поскольку они не только сокращают расстояние, которое должен преодолеть ресурс, но и, как правило, уменьшают его размер, автоматически реализуя все рекомендации по уменьшению размера, приведенные ранее.
Снижение конкуренции за пропускную способность сети.
Даже если вы уменьшили размер ресурса и расстояние, которое ему необходимо преодолеть, загрузка ресурса все равно может занять много времени, если вы одновременно загружаете множество других ресурсов. Эта проблема известна как конкуренция в сети .
Если вы присвоили ресурсу LCP высокий fetchpriority и начали его загрузку как можно быстрее , браузер постарается предотвратить конкуренцию со стороны ресурсов с более низким приоритетом. Однако, если вы загружаете много ресурсов с высоким fetchpriority загрузки или просто большое количество ресурсов, это может повлиять на скорость загрузки ресурса LCP.
Полностью исключите время, затрачиваемое на использование сети.
Лучший способ сократить время загрузки ресурсов — полностью исключить сеть из процесса. Если вы используете эффективную политику управления кэшированием для предоставления ресурсов, то посетители, которые запросят эти ресурсы повторно, получат их из кэша, что сведет время загрузки ресурсов практически к нулю!
Если ваш ресурс LCP представляет собой веб-шрифт, помимо уменьшения размера веб-шрифта , вам также следует подумать, нужно ли блокировать его отрисовку при загрузке. Если вы установите значение font-display отличное от auto или block , то текст всегда будет виден во время загрузки , и LCP не будет блокироваться при дополнительном сетевом запросе.
Наконец, если ваш ресурс LCP невелик, может быть целесообразно встроить его в виде URL-адреса данных , что также позволит избежать дополнительных сетевых запросов. Однако использование URL-адресов данных имеет свои недостатки, поскольку в этом случае ресурсы не могут быть кэшированы, и в некоторых случаях это может привести к увеличению задержек рендеринга из-за дополнительных затрат на декодирование .
4. Сократить время до получения первого байта.
Цель этого шага — как можно быстрее доставить исходный HTML-код. Этот шаг указан последним, поскольку разработчики зачастую имеют над ним наименьший контроль. Однако это также один из самых важных шагов, поскольку он напрямую влияет на все последующие. На фронтенде ничего не может произойти, пока бэкенд не доставит первый байт контента, поэтому любые действия по ускорению TTFB улучшат и все остальные показатели загрузки.
Распространенной причиной замедления TTFB на сайте, который в остальном работает быстро, являются посетители, переходящие по многочисленным перенаправлениям, например, с рекламных объявлений или сокращенных ссылок . Всегда сводите к минимуму количество перенаправлений, которые приходится ждать посетителю.
Еще одна распространенная причина — невозможность использования кэшированного контента с пограничного сервера CDN, в результате чего все запросы должны направляться обратно на исходный сервер. Это может произойти, если посетители используют уникальные параметры URL-адреса для аналитики — даже если это не приводит к переходу на другие страницы.
Для получения конкретных рекомендаций по оптимизации TTFB обратитесь к руководству по оптимизации TTFB .
Мониторинг сбоя LCP в JavaScript
Информация о времени выполнения всех рассмотренных ранее подкомпонентов LCP доступна вам в JavaScript с помощью комбинации следующих API для анализа производительности:
Многие продукты RUM уже рассчитывают эти подкомпоненты, используя данные API. Библиотека web-vitals также включает эти данные о времени выполнения подкомпонентов LCP в сборку с атрибутами, и ее код можно использовать в качестве справочного материала для расчета этих данных на JavaScript.
Инструменты разработчика Chrome и Lighthouse также измеряют эти подкомпоненты, как показано на предыдущих скриншотах, что избавляет вас от необходимости вычислять их вручную в JavaScript при использовании этих инструментов.
Краткое содержание
LCP — сложный процесс, и на его выполнение может влиять множество факторов. Но если учесть, что оптимизация LCP в первую очередь сводится к оптимизации нагрузки на ресурс LCP, это может значительно упростить задачу.
В общих чертах, оптимизацию LCP можно свести к четырем этапам:
- Убедитесь, что загрузка ресурса LCP начинается как можно раньше.
- Убедитесь, что элемент LCP может отобразиться сразу после завершения загрузки его ресурсов.
- Максимально сократите время загрузки ресурса LCP, не жертвуя при этом качеством.
- Предоставьте исходный HTML-документ как можно быстрее.
Если вы сможете выполнить эти шаги на своих страницах, то можете быть уверены, что обеспечиваете пользователям оптимальную скорость загрузки, и это должно отразиться на ваших реальных показателях LCP (показатель LCP).