LCP (Largest Contentful Paint) — момент, когда в видимой области отрисовался самый крупный контентный элемент: картинка, блок текста или видео. Отсчёт — от начала навигации пользователя, не от «DOMContentLoaded» и не от балла Lighthouse. Это одна метрика загрузки, не отчёт «Основные интернет-показатели». Как Google клеит URL-группы и ставит статус по худшей из трёх — соседний Core Web Vitals. Шире (HTTPS, мобильная страница, перекрытия) — Page Experience. Хаб — техническое SEO.
Справка Search Central: хороший LCP — в пределах 2,5 с с начала загрузки. В отчёте Search Console и в CrUX смотрят 75-й процентиль визитов, мобильные отдельно от компьютера: ≤2,5 с — «хорошо», ≤4 с — «нужно увеличить скорость», >4 с — «плохо». Пороги не средний и не ваш инкогнито. CLS и INP — следующие H1, сюда их шкалы не тащим. TTFB — диагностический кусок LCP и отдельный planned URL, не замена этой метрики.
Какой элемент считается LCP
Спецификация Largest Contentful Paint API ограничивает кандидатов. Это сделано специально, набор могут расширить, полного <svg> сейчас нет.
| Кандидат | Что берётся в размер / время | Что часто путают |
|---|---|---|
<img> |
Видимый или intrinsic размер — меньший; для GIF/APNG — первый кадр | Картинка в CSS-спрайте «на весь экран» как фон |
<image> внутри SVG |
Как изображение | Сам тег <svg> — не кандидат |
<video> |
Постер или первый кадр — что раньше | Автоплей без постера, пока кадр не нарисован |
Фон через url() |
Фоновое изображение блока | CSS-градиент без картинки — не LCP |
| Блочный текст | Наименьший прямоугольник текстовых узлов | Поля, padding, border в размер не входят |
Chromium отсекает то, что человек не считает «содержанием»: элемент с opacity 0; элемент на весь вьюпорт (скорее фон); плейсхолдеры с низкой энтропией. FCP может засчитать плейсхолдер, LCP — нет: разные задачи метрик. Размер считается по видимой части во вьюпорте. Смена размера или позиции после отрисовки новых кандидатов не создаёт: в расчёт идёт исходное положение. Картинка, которая сначала off-screen и потом въезжает, может так и не стать LCP.
Браузер шлёт largest-contentful-paint, как только нарисован первый кадр, и ещё раз, когда кандидат сменился (текст, потом hero). После тапа, скролла или клавиши новые записи не идут: взаимодействие меняет, что видно. Фонновая вкладка: инструменты Google LCP не считают, пока вкладка не в фокусе — это не «поздний LCP пользователя», это другое событие. В поле LCP включает unload предыдущей страницы, установку соединения, редиректы и TTFB: поэтому лаборатория на тёплом localhost часто зеленее CrUX.
Четыре куска, а не «сожмите JPEG»
web.dev раскладывает LCP без дыр и перекрытий: TTFB + задержка до старта загрузки LCP-ресурса + длительность этой загрузки + задержка отрисовки элемента. Если LCP — системный шрифт без картинки, два средних куска равны нулю. Ориентир для хорошо собранной страницы: около 40% на TTFB, <10% на задержку ресурса, около 40% на качку ресурса, <10% на отрисовку. Это пропорции, не миллисекунды: web.dev прямо просит не переводить проценты в абсолют.
Сжать hero в AVIF, но показать его только после JS, — выигрыш уезжает в «задержку отрисовки»: картинка скачалась, экран ещё закрыт. Классический CSR: LCP-ресурс не в первом HTML, браузер узнаёт URL поздно. Тогда чинят не «хостинг», а то, что origin отдаёт документ, см. SSR против CSR. Прелоад LCP-картинки, fetchpriority="high", не lazy на герое выше сгиба, размеры width/height чтобы не путать с CLS — это слой LCP, не общий «ускорить сайт».
Где смотреть факт. Поле: отчёт Core Web Vitals в Search Console и верх PSI (CrUX, 28 дней). Нет данных по URL — PSI показывает origin, это не та же цифра. Лаборатория: Lighthouse / Performance в DevTools, чтобы назвать элемент. CrUX важнее разового прогона. Свой RUM — библиотека web-vitals (onLCP): сырой PerformanceObserver врёт на bfcache, iframe и prerender. Яндекс LCP в кабинете не считает. В Вебмастере своё достижение «скорость сайта»: обезличенные открытия в Яндекс Браузере с мобильной выдачи, обновление не реже раза в месяц, другая величина и другая выборка. Не складывайте шкалу Яндекса с 2,5 с Google.
LCP выполнен, когда 75% полевых визитов шаблона рисуют основной блок ≤2,5 с. Зелёная лаборатория на одном URL этого не заменяет.
На денежных шаблонах сначала находят LCP-элемент в DevTools, потом смотрят, в первом ли HTML его URL. Если героя нет в ответе сервера — это дыра доступа плюс скорость, постановка SEO-аудита сайта, не «ещё один CDN». Карта, как робот вообще получает документ, — рендеринг для поисковиков: LCP измеряет человека в Chrome, не очередь WRS.
Ограничение. Нет замера доли витрин РФ с красным LCP — не выдумываем. Нет формулы «минус N позиций за 4,1 с». Актуальные пороги — справка Search Console; FID в KPI 2026 года не кладут. Не подставляйте балл 0–100 PSI вместо полевого статуса группы.
Частые вопросы
LCP и FCP — это одно и то же?
Нет. FCP — когда на экране появилось хоть что-то (в том числе лоадер). LCP — когда отрисовался самый крупный контентный блок. Большой зазор FCP→LCP обычно значит, что герой не в первом HTML или браузер занят другим, пока основной блок не рисуется.
Почему в Lighthouse 2 секунды, а в Search Console LCP красный?
Лаборатория — один прогон в заданных условиях. Console — 75-й процентиль живых Chrome по группе URL за ~28 дней, с редиректами, 4G и холодным кэшем. Смотрят поле. Лаборатория нужна, чтобы назвать элемент, не чтобы закрыть KPI.
Яндекс смотрит LCP?
В Вебмастере нет отчёта Core Web Vitals. Есть индекс скорости по открытиям в Яндекс Браузере с мобильного поиска — другая метрика и другая выборка. Пороги 2,5 с / 4 с относятся к Google CrUX, их нельзя переносить на шкалу Яндекса.
Достаточно ли сжать главное изображение, чтобы LCP стал зелёным?
Нет, если браузер узнаёт URL героя поздно или показывает его только после JS. Сжатие укорачивает качку ресурса и может просто переложить время в задержку отрисовки. Нужны все четыре куска, и герой — в первом HTML.