LCP: что это, как измерить и улучшить Largest Contentful Paint

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

Largest Contentful Paint (LCP) — одна из трёх метрик Core Web Vitals. Она измеряет время от начала навигации до отрисовки самого крупного подходящего элемента в видимой области страницы. Для хорошего пользовательского опыта Google рекомендует значение не более 2,5 секунды.

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

Как браузер определяет LCP

Браузер отслеживает появление крупных элементов в области, которую пользователь видит без прокрутки, — viewport.

В зависимости от устройства и структуры страницы кандидатом на LCP может стать:

• крупное изображение в первом экране;
• текстовый блок, включая заголовок;
• изображение, установленное через CSS background-image;
• подходящий видеоконтент или его изображение-заставка;
• изображение внутри SVG.

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

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

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

Какие значения LCP считаются нормальными

Значение LCP	Оценка	Интерпретация
До 2,5 с включительно	Хорошо	Основной контент отображается достаточно быстро
Более 2,5 до 4 с включительно	Требуется улучшение	Пользователь заметно дольше ждёт основное содержимое
Более 4 с	Плохо	Основной контент появляется со значительной задержкой

Оценку проводят по 75-му процентилю загрузок страниц (p75), отдельно для мобильных устройств и компьютеров.

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

Чем LCP отличается от FCP, CLS и INP

Эти показатели часто оказываются в одном отчёте, но измеряют разные свойства страницы.

FCP (First Contentful Paint) фиксирует момент первого отображения содержимого страницы. Например, браузер уже нарисовал текст заголовка, хотя главное изображение ещё загружается.

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

CLS (Cumulative Layout Shift) оценивает неожиданные смещения элементов. Страница может иметь хороший LCP, но плохой CLS, если изображение после загрузки сдвигает текст и кнопки.

INP (Interaction to Next Paint) характеризует отзывчивость интерфейса при взаимодействии пользователя с ним.

В актуальном наборе Core Web Vitals находятся LCP, CLS и INP. FCP остаётся самостоятельной диагностической метрикой, но в эту тройку не входит.

Влияет ли LCP на SEO, обход и индексацию

Google официально подтверждает, что Core Web Vitals используются системами ранжирования. Однако хорошая оценка скорости не гарантирует высокую позицию в поиске.

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

Стоит разделять три процесса.

Ранжирование. LCP входит в Core Web Vitals, которые Google учитывает при оценке пользовательского опыта. Но его конкретный вес в алгоритмах для отдельного запроса публично не установлен.

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

Индексирование. Значение LCP выше четырёх секунд само по себе не является запретом на индексирование. Если страница не попадает в индекс, необходимо отдельно проверять доступность, HTTP-ответ, robots.txt, директивы индексирования, каноникализацию и качество содержимого.

Для Яндекса также не следует объявлять порог 2,5 секунды официальным условием ранжирования или индексирования без отдельного подтверждения поисковой системы.

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

Как проверить LCP на сайте

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

Для полноценной проверки полезны три инструмента.

PageSpeed Insights: лабораторные и реальные показатели

Введите адрес страницы в PageSpeed Insights и отдельно изучите мобильную и компьютерную версии.

В результатах могут присутствовать два разных типа данных:

• Полевые данные (field data) — показатели реальных пользователей из Chrome UX Report, если их достаточно.
• Лабораторные данные (lab data) — результат тестового запуска Lighthouse в заданных условиях.

Если лабораторный LCP составляет 1,8 секунды, а полевой — 3,6 секунды, это не обязательно ошибка инструмента.

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

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

Google Search Console: проблема одной страницы или целого шаблона

В разделе «Основные интернет-показатели» можно увидеть группы похожих URL с проблемами LCP, CLS и INP.

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

Нужно учитывать ограничения:

• отчёт использует данные реальных пользователей;
• показатели рассматриваются отдельно для мобильных устройств и компьютеров;
• похожие страницы объединяются в группы;
• отсутствие URL в отчёте не доказывает, что с ним всё хорошо: данных может быть недостаточно.

Для групп URL используются измерения за последние 28 дней. После исправления проблема не обязана исчезнуть из отчёта немедленно.

Chrome DevTools: найти конкретный элемент и задержку

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

Запись загрузки позволяет исследовать LCP, связанные сетевые запросы, загрузку ресурсов и работу основного потока браузера.

Особенно полезны диагностические сведения LCP breakdown и LCP request discovery.

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

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

Почему LCP медленный: четыре составляющие времени

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

Время LCP можно разложить на четыре последовательных этапа.

Этап	Что измеряет	Что проверять
TTFB	Время до первого байта HTML	Сервер, редиректы, кэширование, сеть
Resource load delay	Ожидание начала загрузки LCP-ресурса	Порядок обнаружения изображения, CSS, JavaScript
Resource load duration	Продолжительность загрузки ресурса	Размер, формат, сжатие, доставка
Element render delay	Время от окончания загрузки ресурса до его отображения	Стили, скрипты, блокировка отрисовки

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

Сначала проверяйте задержку начала загрузки

Представим, что главное изображение весит всего 90 КБ, но браузер обнаруживает его спустя полторы секунды после получения HTML.

Дополнительное сжатие на 10–15 КБ в таком случае вряд ли устранит основной источник задержки.

Причина может быть в том, что изображение:

• добавляется в DOM после выполнения JavaScript;
• хранится в data-src до активации скрипта отложенной загрузки;
• загружается как CSS-фон только после обработки таблицы стилей;
• конкурирует с другими ресурсами за сетевой приоритет.

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

Как улучшить LCP на WordPress и других сайтах

Уберите отложенную загрузку у главного изображения

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

Браузеру выгоднее обнаружить и начать загрузку такого ресурса как можно раньше.

Условный пример корректной разметки:

<img
  src="/images/hero-960.webp"
  srcset="/images/hero-480.webp 480w,
          /images/hero-960.webp 960w,
          /images/hero-1440.webp 1440w"
  sizes="(max-width: 768px) 100vw, 960px"
  width="960"
  height="540"
  loading="eager"
  fetchpriority="high"
  alt="Главное изображение страницы"
>

Здесь разные атрибуты решают разные задачи:

• srcset и sizes помогают выбрать подходящий размер изображения;
• width и height позволяют резервировать место и уменьшать риск смещения макета;
• loading="eager" не откладывает загрузку элемента;
• fetchpriority="high" сообщает браузеру о высоком приоритете запроса.

Значения размеров и пути в примере условные: в реальной разметке они должны соответствовать фактическим файлам и макету.

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

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

Устраните задержки из-за CSS и JavaScript

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

Проверьте, не задерживают ли первый экран:

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

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

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

Если LCP-изображение задано через CSS

Изображение в background-image браузер нередко обнаруживает позже, чем обычный элемент <img> в первоначальном HTML.

Когда изображение является содержательной частью страницы, стоит рассмотреть использование обычного HTML-элемента изображения.

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

Ускорьте ответ сервера, если проблема в TTFB

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

Для динамических сайтов, включая WordPress, проверяйте:

• работу серверного и страничного кэша;
• неоправданно длинные цепочки редиректов;
• медленные операции PHP и базы данных;
• географическую удалённость сервера от аудитории;
• задержки при обращении к внешним сервисам.

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

Практический пример: изображение загружается быстро, а LCP плохой

Рассмотрим условную страницу услуги с большим изображением в hero-блоке.

Лабораторная диагностика показывает LCP 3,8 секунды. Сам файл относительно небольшой, и его загрузка занимает менее секунды.

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

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

Для иллюстрации рассмотрим возможное изменение показателей:

Составляющая	До	После
TTFB	0,8 с	0,7 с
Ожидание ресурса	1,4 с	0,2 с
Загрузка ресурса	0,9 с	0,7 с
Задержка отрисовки	0,7 с	0,4 с
Итоговый LCP	3,8 с	2,0 с

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

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

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

Чек-лист проверки LCP после оптимизации

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

Проверка	Критерий
Определён LCP-элемент	Известно, какой элемент влияет на результат на мобильной и десктопной версиях
Проверена загрузка ресурса	Критичное изображение обнаруживается рано и не загружается через lazy
Проверен сервер	TTFB не создаёт основную задержку
Проверена отрисовка	Стили и скрипты не удерживают главный контент скрытым
Проверена адаптивность	Браузер не скачивает чрезмерно крупное изображение на мобильном устройстве
Проверены остальные метрики	Улучшение LCP не сопровождается ухудшением CLS и INP
Проверены реальные данные	Значение p75 стремится к 2,5 секунды или ниже на целевых устройствах

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

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

Что делать с LCP на практике

Начинайте не с установки очередного плагина ускорения, а с диагностики.

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

Цель — LCP не более 2,5 секунды на 75-м процентиле реальных загрузок, без ухудшения других характеристик сайта.

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