
LCP: что это, как измерить и улучшить Largest Contentful Paint
Разбираем, как браузер определяет LCP, почему крупный элемент страницы появляется с задержкой и как исправить проблему без бессмысленной гонки за 100 баллами…
Тема блога
LCP показывает, насколько быстро в видимой области страницы появляется крупнейший значимый элемент контента. Здесь разобраны смысл метрики, нормативные диапазоны, способы измерения и основные причины медленной отрисовки.
Материалы

Разбираем, как браузер определяет LCP, почему крупный элемент страницы появляется с задержкой и как исправить проблему без бессмысленной гонки за 100 баллами…

LCP помогает понять, когда посетитель действительно увидел основной контент первого экрана. Разберём, где смотреть показатель, почему он бывает плохим и какие исправления…
LCP расшифровывается как Largest Contentful Paint. Это одна из метрик Core Web Vitals, которая оценивает скорость отображения крупнейшего содержательного элемента, видимого пользователю в области просмотра страницы. Таким элементом может оказаться изображение, крупный текстовый блок или постер видео. Метрика отсчитывается относительно начала перехода на страницу и показывает момент, когда соответствующий элемент был отрисован.
LCP полезно рассматривать не как абстрактную оценку скорости сайта, а как показатель конкретного этапа загрузки. Страница может начать выводить текст и интерфейс достаточно быстро, но основной крупный контент появится заметно позже. Именно эту задержку и помогает обнаружить Largest Contentful Paint.
Такой фокус отличает LCP от общего балла производительности. Балл Lighthouse или PageSpeed Insights объединяет несколько характеристик и диагностик, тогда как LCP отвечает на более узкий вопрос: когда пользователь увидел крупнейший элемент текущего первого экрана.
Для хорошего пользовательского опыта Google рекомендует стремиться к LCP не более 2,5 секунды. Диапазон от 2,5 до 4 секунд считается требующим улучшения, а значение свыше 4 секунд относится к плохому результату. При оценке реальных пользователей ориентируются на 75 процентиль загрузок отдельно для мобильных и настольных устройств.
Поэтому один удачный лабораторный запуск не означает, что проблема LCP решена для аудитории сайта. Пользователи открывают страницу на разных устройствах, через разные сети и из разных регионов, а серверная и клиентская части сайта также могут работать неодинаково в разные моменты.
Важно сравнивать данные в одинаковых условиях. Если сегодня проверяется мобильный режим с ограниченной производительностью устройства, а после изменения используется десктопный тест без аналогичных ограничений, такое сравнение мало говорит о результате оптимизации.
В процессе загрузки крупнейший кандидат на LCP может меняться. Сначала самым крупным видимым содержимым может быть текстовый блок, затем браузер отрисует большое изображение и уже оно станет новым кандидатом.
Изображение, которое ещё не загрузилось и не было отрисовано, не считается готовым элементом LCP. Аналогичная ситуация возможна с текстом, отображение которого задерживается из за загрузки веб шрифта. Поэтому проблема может находиться не только в размере файла изображения, но и в цепочке ресурсов, необходимых для появления элемента на экране.
Самый крупный элемент не обязательно совпадает с тем содержимым, которое владелец сайта считает самым важным. LCP определяется правилами измерения браузера, поэтому сначала нужно установить фактический элемент метрики на конкретной странице, а уже затем искать причину задержки.
LCP можно анализировать как по реальным пользовательским данным, так и в лабораторных условиях. Для полевых данных применяются Chrome User Experience Report, отчёт Core Web Vitals в Google Search Console и данные PageSpeed Insights при наличии достаточной статистики. Для лабораторной диагностики используются Lighthouse, Chrome DevTools, PageSpeed Insights и другие инструменты производительности.
Эти источники решают разные задачи. Полевые данные показывают, что происходило у реальных посетителей, а лабораторный тест помогает воспроизвести загрузку и исследовать конкретную страницу. Поэтому расхождение между двумя типами данных само по себе не является ошибкой.
На Vagizov.com работа с самим отчётом PageSpeed Insights вынесена в отдельный материал о чтении полевых и лабораторных показателей. Страница LCP должна оставаться сфокусированной именно на Largest Contentful Paint, его элементе и причинах задержки, а не дублировать общее руководство по PageSpeed Insights.
До начала отображения содержимого браузеру необходимо получить ответ и данные страницы. Если сервер долго формирует документ, задержка возникает ещё до загрузки изображения, CSS или других ресурсов первого экрана.
Для сайтов на WordPress причиной могут быть тяжёлые запросы к базе данных, неоптимальный код темы или плагинов, внешние обращения, отсутствие подходящего кеширования и другие серверные ограничения. Однако источник задержки следует подтверждать измерением, а не назначать оптимизацию сервера автоматически каждому сайту.
Даже быстрое изображение не поможет LCP, если браузер узнаёт о нём слишком поздно. Такое происходит, когда критичный ресурс появляется только после выполнения JavaScript, загружается через неудачную последовательность зависимостей или получает слишком низкий приоритет.
Особенно внимательно стоит проверять крупные изображения первого экрана. Если именно такое изображение является элементом LCP, безусловная отложенная загрузка способна задержать его появление вместо ускорения страницы.
Большой объём передаваемых данных, неподходящие размеры изображения, отсутствие адаптивных вариантов и медленная доставка ресурса увеличивают время до его отображения.
Оптимизация должна учитывать фактический размер элемента в интерфейсе и устройство пользователя. Нет смысла передавать чрезмерно большое изображение только ради последующего уменьшения его средствами CSS.
Ресурс может быть уже загружен, но ещё не показан пользователю. Причиной становятся блокирующие стили, выполнение JavaScript, клиентский рендеринг, загрузка необходимых шрифтов или особенности построения интерфейса.
Поэтому совет просто сжать изображения закрывает только часть возможных проблем LCP. Сначала требуется определить, на каком этапе формируется основная задержка.
Первый этап заключается в определении элемента, который действительно формирует LCP на проблемной странице. Это может быть hero изображение, фотография товара, баннер, заголовок или крупный текстовый блок.
Оптимизация второстепенных картинок, скриптов в футере или элементов ниже первого экрана может практически не изменить метрику, если они не задерживают критическую цепочку загрузки.
После определения элемента нужно проследить последовательность от запроса страницы до его появления на экране. Проверяется серверный ответ, момент обнаружения ресурса, его загрузка и последующая отрисовка.
Такой подход позволяет отделить проблему сервера от проблемы изображения, CSS, JavaScript или браузерного рендеринга. В результате исправляется конкретное узкое место, а не весь сайт одновременно.
Если элемент LCP зависит от отдельного файла, важно убедиться, что браузер получает его достаточно рано. Для изображения первого экрана это особенно критично.
Preload и повышение приоритета могут быть полезны для действительно важных ресурсов, но применять их ко множеству файлов подряд не следует. Избыточная приоритизация заставляет критические ресурсы конкурировать друг с другом.
Отложенная загрузка полезна для контента ниже области просмотра, однако изображение, которое сразу видно пользователю и формирует LCP, обычно должно начинать загружаться раньше.
Поэтому автоматическая настройка lazy loading для всех изображений сайта может ухудшить Largest Contentful Paint. Решение принимается исходя из положения изображения и результатов диагностики конкретного шаблона.
Если файл элемента загружен быстро, а отрисовка происходит поздно, дальнейшее сжатие изображения может почти ничего не изменить. Тогда необходимо исследовать ресурсы, блокирующие отображение, выполнение JavaScript, порядок применения стилей и работу шрифтов.
Особенно важно учитывать сайты с большим объёмом клиентского рендеринга. Пользователь может уже получить HTML и необходимые данные, но основной блок появится только после выполнения дополнительной логики в браузере.
FCP фиксирует появление первого содержательного элемента страницы. Им может быть небольшой текст, иконка или другой ранний контент.
LCP относится к крупнейшему содержательному элементу видимой области и поэтому лучше описывает момент появления основной части первого экрана. Быстрый FCP при медленном LCP возможен, если браузер быстро показывает небольшой элемент, но главное изображение или крупный блок появляется значительно позже.
Эти показатели не следует заменять друг другом. Они описывают разные этапы восприятия загрузки страницы.
LCP отвечает за аспект производительности загрузки в наборе Core Web Vitals. Остальные основные метрики оценивают другие свойства пользовательского опыта, поэтому хороший LCP не означает автоматически, что страница проходит все требования Core Web Vitals.
Google рекомендует владельцам сайтов стремиться к хорошим показателям Core Web Vitals как части качественного пользовательского опыта и поисковой оптимизации. При этом улучшение одной метрики само по себе не является гарантией определённой позиции в поисковой выдаче.
Поэтому LCP имеет смысл рассматривать как технический показатель, который помогает обнаружить и исправить проблемы загрузки основного контента, а не как отдельную универсальную SEO тактику.
После изменения сначала следует повторить лабораторную диагностику в сопоставимых условиях и убедиться, что задержка нужного элемента действительно уменьшилась.
Затем результат желательно подтвердить полевыми данными, когда для страницы или сайта накопится достаточная статистика реальных посещений. Такой порядок помогает не делать выводы по одному удачному тесту.
Если LCP остаётся плохим, следует заново проверить сам элемент и этап задержки. После изменений страницы крупнейшим элементом может стать другой блок, поэтому старая причина проблемы не всегда остаётся актуальной.
Если проблема LCP воспроизводится на нескольких ключевых шаблонах и связана одновременно с сервером, темой, изображениями, CSS или JavaScript, точечной правки одного ресурса может быть недостаточно.
Для таких задач на Vagizov.com отдельно представлена услуга оптимизация скорости сайта и Core Web Vitals, где диагностика LCP рассматривается вместе с серверной частью, медиаресурсами, клиентским кодом и проверкой результата после внедрения.