Largest contentful paint: зачем нужно, как проверить и настроить для SEO

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

Именно этот момент помогает оценивать Largest Contentful Paint, или LCP. В русской документации Google используется формулировка «отрисовка самого крупного контента»: метрика измеряет, когда в видимой области экрана появился крупнейший подходящий элемент. Хорошим ориентиром считается LCP до 2,5 секунды для 75-го процентиля загрузок; от 2,5 до 4 секунд показатель требует улучшения, свыше 4 секунд считается плохим.

LCP показывает момент, когда «витрина» действительно открылась

Largest Contentful Paint легко спутать с общей скоростью загрузки. Но он не отвечает на вопрос, когда браузер скачал абсолютно всё — счётчики, чат, изображения ниже первого экрана и остальные ресурсы.

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

• большая фотография товара;
• hero-изображение сайта услуг;
• крупный текстовый блок;
• постер видео;
• фоновое изображение, если оно подходит под критерии метрики.

Поэтому две внешне похожие страницы способны иметь совершенно разный LCP.

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

FCP и LCP — это не одно и то же

First Contentful Paint показывает момент появления первого содержимого: текста, картинки или другого отображаемого элемента. LCP — когда появился крупнейший значимый элемент первого экрана.

Бытовая аналогия простая: FCP — в магазине включили свет и открыли дверь. LCP — покупатель наконец увидел главную витрину с товаром.

Поэтому хороший FCP ещё не означает хороший Largest Contentful Paint. Страница может очень быстро показать шапку и пару строк текста, а затем несколько секунд заставлять посетителя ждать основное изображение. PageSpeed Insights именно поэтому показывает FCP и LCP отдельно.

Что LCP означает для SEO — без магии вокруг зелёной оценки

LCP входит в Core Web Vitals вместе с INP и CLS. Google прямо указывает, что Core Web Vitals используются его системами ранжирования, но одновременно подчёркивает важное ограничение: хороший результат Core Web Vitals не гарантирует высокие позиции. Поиск продолжает в первую очередь стремиться показать наиболее релевантный контент.

Это важное различие для бизнеса.

Если две страницы одинаково хорошо отвечают на запрос, удобство может оказаться одним из дополнительных преимуществ. Но превращать задачу в «добьём PageSpeed до 100 — и получим топ-3» неправильно.

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

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

Почему LCP медленный: четыре разных проблемы вместо одной «тяжёлой картинки»

Самая частая ошибка — увидеть плохой LCP и сразу начать пережимать изображения.

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

Для владельца бизнеса их удобнее читать так:

Где потеряно время	Что происходит на сайте	Понятный пример
Ответ сервера	Браузер долго ждёт саму страницу	клиент пришёл в ресторан, но официант ещё даже не принёс меню
Ресурс обнаружен слишком поздно	HTML уже получен, но браузер поздно узнаёт о главной картинке	склад открыт, но никто не сказал сотруднику, какой товар вынести
Ресурс долго скачивается	Картинка или другой крупный файл слишком тяжёлый	нужный диван нашли, но его везут на витрину на грузовике из соседнего города
Ресурс загружен, но не показывается	CSS, JavaScript или другая логика задерживает отрисовку	товар уже стоит за занавесом, но занавес почему-то ещё не открывают

Эти проблемы требуют разных решений. Быстрый CDN не исправит hero-картинку, которую браузер обнаруживает только после выполнения JavaScript. А перевод изображения в WebP мало поможет, если сервер несколько секунд формирует HTML.

Здесь LCP становится нормальной задачей технического SEO: не «ускорить всё», а найти конкретное узкое место в цепочке загрузки.

Как проверить Largest Contentful Paint и не сделать вывод по одному тесту

Для владельца сайта достаточно понимать два вида измерений.

Полевые данные показывают, что происходило у реальных пользователей. PageSpeed Insights получает такие данные из Chrome UX Report, если статистики достаточно. Search Console также использует реальные пользовательские данные и объединяет похожие URL в группы.

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

Отсюда возникает распространённая ситуация:

«Я запустил PageSpeed — сегодня LCP 2,2 секунды. Почему Search Console всё ещё ругается?»

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

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

Для сайта логика та же: смотрите отдельный тест для поиска причины, а полевые данные — чтобы понять, сталкиваются ли с проблемой реальные посетители.

Если Search Console вообще не показывает Core Web Vitals для части сайта, это также не означает автоматически «всё хорошо». Google прямо указывает, что для отчёта нужен достаточный объём реальных данных, а сам отчёт не является полным списком всех URL сайта.

Interaction to Next Paint отвечает уже на другой вопрос

LCP показывает, насколько быстро пользователь увидел основной контент. Interaction to Next Paint, или INP, оценивает, насколько быстро страница реагирует на взаимодействия. Для хорошего пользовательского опыта Google рекомендует INP менее 200 мс.

Поэтому сайт способен пройти LCP и всё равно раздражать клиентов.

Например, карточка товара появляется быстро — отличный LCP. Покупатель нажимает «Выбрать размер», а интерфейс заметно подвисает — это уже область INP.

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

Mixed content может выглядеть как проблема загрузки, но это отдельная история

На HTTPS-странице иногда остаются изображения, скрипты, стили или другие ресурсы, запрашиваемые через HTTP. Это называется mixed content.

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

Но из этого не следует, что существует отдельный «штраф за mixed content, который портит LCP». Правильнее рассматривать безопасность ресурса и LCP отдельно, а затем проверять, не мешает ли заблокированный или неправильно подключённый ресурс нормальной отрисовке первого экрана.

Что исправлять после диагностики

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

Если долго отвечает сервер — проверяют серверную обработку, кеширование, запросы к базе и инфраструктуру.

Если главный ресурс обнаруживается слишком поздно — выясняют, почему браузер не видит его сразу в HTML. Особенно подозрительна ситуация, когда главное изображение первого экрана отложено lazy loading или появляется только после выполнения JavaScript.

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

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

fetchpriority="high" или preload тоже не являются волшебными ускорителями. Они нужны там, где браузеру действительно стоит раньше узнать о критичном ресурсе; бездумное повышение приоритета всему подряд заставляет важные ресурсы конкурировать друг с другом. Официальные рекомендации Chrome также советуют использовать preload избирательно.

Пример: интернет-магазин уже «загрузился», но покупателю всё ещё нечего покупать

Возьмём условный магазин мебели.

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

В лабораторном тесте условный LCP получается 4,4 секунды.

Можно было бы начать с CDN, смены сервера или очередного плагина «ускорения WordPress». Но диагностика показывает другое: основная потеря происходит между получением HTML и началом загрузки фотографии.

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

Допустим, после изменений лабораторный LCP стал 2,1 секунды. Это хороший сигнал, что конкретное узкое место устранено. Но он не доказывает, что позиции или продажи автоматически вырастут. Следующий шаг — дождаться реальных пользовательских данных и проверить, подтвердилось ли улучшение вне тестовой среды.

Как принять работу и понять, что проблему действительно исправили

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

Вместо «ускорьте сайт» задайте пять вопросов:

1. Какой элемент сейчас является LCP на проблемной странице?
2. Какое значение показывают реальные пользователи, если для URL достаточно данных?
3. Какая из четырёх частей LCP создаёт основную задержку?
4. Что конкретно было изменено и почему именно это должно устранить найденную причину?
5. Что показывают повторный лабораторный тест и полевые данные после накопления новой статистики?

И ещё один важный критерий: проверяйте не только главную страницу.

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

Largest Contentful Paint полезен именно тогда, когда превращается из абстрактной «метрики Google» в простой вопрос: сколько приходится ждать клиенту, прежде чем он увидит главный контент страницы?

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