Что такое LCP-элемент и как его найти и оптимизировать

Что такое LCP-элемент?

Когда инструмент производительности показывает, что у страницы медленный Largest Contentful Paint (LCP), следующий полезный вопрос — не просто «Как улучшить LCP?», а: Какой именно элемент формирует LCP?

Этот элемент называется LCP-элементом. Часто это hero-изображение, но им также могут быть заголовок, абзац, CSS-фоновое изображение или видеоконтент. Что ещё важнее, это не просто самый большой DOM-элемент на странице. Браузер применяет определённые правила допустимости, видимости и размера, чтобы определить, какой отрисованный контент станет кандидатом на LCP. (web.dev)

Понимание этой разницы делает диагностику LCP гораздо точнее.

Краткий ответ

LCP-элемент — это элемент контента, связанный с Largest Contentful Paint страницы: самое крупное допустимое изображение, текстовый блок или другой поддерживаемый контент, который браузер отрисовал в пределах viewport во время загрузки.

По мере загрузки страницы этот элемент может меняться. Например, сначала самым крупным отрисованным контентом может быть заголовок, а после загрузки hero-изображения именно оно может стать LCP-элементом. Поэтому браузеры отслеживают последовательность кандидатов на LCP, а не определяют один элемент с самого начала. (web.dev)

INTERNAL LINK: Что такое Largest Contentful Paint?

Что может стать LCP-элементом?

Не каждый видимый DOM-элемент может участвовать в расчёте LCP.

Согласно актуальным рекомендациям по LCP, к основным типам кандидатов относятся:

Тип элемента	Может стать LCP?
`<img>`	Да
`<image>` внутри `<svg>`	Да
Контент `<video>`	Да
CSS `background-image: url(...)`	Да
Текстовый контент блочного уровня	Да
CSS-градиент	Нет
Весь элемент `<svg>`	Как правило, нет

Для видео браузер может использовать poster-изображение или первый отображённый кадр видео в соответствии с правилами расчёта LCP. Для текста кандидатом обычно является блочный элемент, содержащий соответствующие текстовые узлы. (web.dev)

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

Большой декоративный фон, малозначимый placeholder, невидимый элемент или неподдерживаемый тип элемента могут не участвовать в расчёте. Chromium также использует эвристики, призванные исключать контент, который с малой вероятностью представляет значимую часть страницы. (web.dev)

Как браузер выбирает элемент

Представим страницу с такой структурой:

<h1>Build Faster Websites</h1>

<img
  src="/hero.webp"
  alt="Website performance dashboard"
>

Браузер может сначала отрисовать <h1>.

В этот момент заголовок может стать кандидатом на LCP.

Позже загрузится и появится hero-изображение. Если его допустимая отрисованная область больше, чем у предыдущего кандидата, <img> станет новым кандидатом на LCP.

Таким образом, значение LCP развивается по мере появления контента. Новый отрисованный элемент заменяет предыдущего кандидата только в том случае, если он соответствует требованиям и является больше согласно правилам расчёта размера LCP. (web.dev)

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

Как рассчитывается размер LCP

Браузер не просто вычисляет:

CSS width × CSS height

и не выбирает самый большой результат.

При расчёте LCP в первую очередь учитывается та часть допустимого контента, которая действительно видима в пределах viewport. Контент, выходящий за границы viewport или обрезанный, не полностью учитывается в размере LCP. Для изображений, увеличенных сверх их intrinsic dimensions, расчёт также не позволяет искусственному масштабированию создать чрезмерно крупного кандидата на LCP. (web.dev)

Для текста браузер учитывает прямоугольную область, содержащую соответствующий текст, а не весь CSS-бокс вместе с margin, border и padding.

Поэтому огромный <div> с короткой строкой текста не становится LCP автоматически только потому, что сам <div> занимает весь экран.

LCP-элемент может меняться

Распространённое заблуждение — считать, что у каждого URL есть один фиксированный LCP-элемент.

Это не так.

Даже одна и та же страница может иметь разные LCP-элементы в разных посещениях, потому что могут отличаться размеры viewport, responsive-layout, персонализация, начальная позиция прокрутки и видимый контент. В рекомендациях web.dev по полевой диагностике производительности прямо говорится, что не стоит предполагать, будто один и тот же элемент всегда будет кандидатом на LCP для конкретной страницы. (web.dev)

Рассмотрим responsive-главную страницу:

Desktop:
large hero image → LCP

Mobile:
large heading → LCP

Оба результата могут быть корректными.

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

Как найти LCP-элемент

Chrome DevTools

Запишите загрузку страницы в панели Performance в Chrome DevTools.

Chrome показывает маркер LCP на временной шкале производительности. Выбрав его, можно увидеть информацию о событии LCP и исследовать как сам элемент, так и временные компоненты, из-за которых возникла задержка. В актуальной документации DevTools LCP также разбивается на TTFB, resource load delay, resource load time и element render delay, когда это применимо. (developer.chrome.com)

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

JavaScript

Largest Contentful Paint API также позволяет получить сам элемент-кандидат.

const observer = new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const latest = entries[entries.length - 1];

  console.log("LCP element:", latest.element);
  console.log("LCP time:", latest.startTime);
  console.log("LCP size:", latest.size);
});

observer.observe({
  type: "largest-contentful-paint",
  buffered: true,
});

LargestContentfulPaint.element ссылается на соответствующий DOM-элемент, а performance entry также содержит данные, например о его размере и времени. (developer.mozilla.org)

Однако в production Real User Monitoring корректный расчёт финального значения LCP включает больше edge case’ов, чем простое использование произвольной записи observer. web.dev рекомендует при необходимости применять такие инструменты, как библиотека web-vitals, поскольку она учитывает ряд особенностей конкретной метрики. (web.dev)

Почему элемент важен

Если вы знаете, что LCP равен 4 секундам, это говорит о проблеме с производительностью загрузки.

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

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

Если это текст, причина может быть в времени ответа сервера, render-blocking CSS, web fonts или JavaScript, задерживающем появление текста.

Если JavaScript создаёт LCP-элемент только после hydration или другого клиентского процесса, одно лишь сжатие ресурса может почти ничего не изменить — более серьёзная проблема может заключаться в том, что браузер слишком поздно обнаруживает или отрисовывает контент. В рекомендациях Google по оптимизации LCP эти задержки разделяются отдельно, потому что улучшение одного компонента не обязательно улучшит итоговый LCP, если узким местом остаётся другой. (web.dev)

INTERNAL LINK: Как оптимизировать Largest Contentful Paint

LCP-элемент и LCP-ресурс

Эти термины связаны, но означают не одно и то же.

LCP-элемент — это отрисованный элемент контента, например:

<img src="/hero.webp" alt="">

LCP-ресурс — это внешний ресурс, необходимый для его отрисовки:

/hero.webp

У LCP на основе изображения обычно есть LCP-ресурс.

А у текстового LCP, использующего системный шрифт, отдельного LCP-ресурса может не быть вовсе. Поэтому Chrome не показывает этапы загрузки ресурса в LCP timing breakdown, если загружать отдельный ресурс не требуется. (developer.chrome.com)

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

Распространённые заблуждения

«Hero-изображение всегда является LCP-элементом.» Нет. Такое встречается часто, но реального кандидата браузер определяет по допустимому отрисованному контенту.

«Самый большой DOM-узел становится LCP.» Нет. LCP использует правила допустимости и визуального размера контента, а не просто размеры DOM-элемента. (web.dev)

«У моей страницы есть один постоянный LCP-элемент.» Не обязательно. Кандидат может меняться в зависимости от viewport, пользователя, контента и условий загрузки страницы. (web.dev)

«Оптимизация файла LCP-изображения всегда исправляет LCP.» Нет. На итоговый результат также могут сильнее влиять обнаружение ресурса, TTFB, render-blocking работа, JavaScript и element render delay. (web.dev)

FAQ

Всегда ли LCP-элемент — это изображение?

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

Может ли H1 быть LCP-элементом?

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

Может ли CSS background image стать LCP?

Да, изображение, загружаемое через CSS url(), может участвовать в расчёте. Сам CSS-градиент кандидатом на LCP-изображение не является. (web.dev)

Может ли LCP-элемент меняться во время загрузки?

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

Влияет ли LCP-элемент напрямую на SEO?

LCP является одной из метрик Core Web Vitals, и Google указывает, что Core Web Vitals используются его ranking systems. Однако хорошие показатели Core Web Vitals не гарантируют высокие позиции, а Google прямо рекомендует оценивать page experience комплексно, а не воспринимать одну метрику как отдельную формулу ранжирования. (developers.google.com)

Итог

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

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

Источники

W3C Web Performance Working Group — Largest Contentful Paint, Working Draft, July 13, 2026. (w3.org) W3C specification
Philip Walton and Barry Pollard — Largest Contentful Paint (LCP), web.dev, updated September 4, 2025. (web.dev) web.dev LCP documentation
Philip Walton and Barry Pollard — Optimize Largest Contentful Paint, web.dev, updated March 31, 2025. (web.dev) LCP optimization guide
Chrome for Developers — Performance Insights, Chrome DevTools documentation. (developer.chrome.com) Chrome DevTools performance documentation
web.dev — Debug Performance in the Field, guidance on identifying real-user LCP candidates. (web.dev) Field performance debugging guide
MDN Web Docs — LargestContentfulPaint: element property. (developer.mozilla.org) MDN LargestContentfulPaint.element
Google Search Central — Understanding Core Web Vitals and Google Search results, updated December 10, 2025. (developers.google.com) Google Search Central Core Web Vitals documentation

Что такое LCP-элемент и как его найти и оптимизировать