Что это
LCP (Largest Contentful Paint) — метрика Core Web Vitals, которая измеряет время от начала загрузки страницы до момента, когда в области просмотра отрендерился самый крупный элемент контента: изображение, видео-постер, блок с текстом или фоновое изображение через CSS. Реальные данные LCP — это не синтетические замеры из PageSpeed Insights, а показатели из Chrome UX Report (CrUX), которые Google собирает с реальных устройств реальных пользователей за последние 28 дней. Именно эти данные Google использует при оценке страниц в Search Console и при ранжировании.
Почему это важно для SEO
Google официально включил Core Web Vitals, включая LCP, в сигналы ранжирования с июня 2021 года. Порог «хорошего» LCP — до 2,5 секунды. От 2,5 до 4 секунд — «требует улучшения». Свыше 4 секунд — «плохо». Страницы с хорошим LCP по реальным данным получают бонус при прочих равных условиях. Важно: синтетические тесты могут показывать зелёный LCP, а реальные данные — красный, потому что реальные пользователи заходят с медленных мобильных сетей и слабых Android-устройств.
Для Яндекса метрика LCP как таковая не является официальным сигналом ранжирования, однако скорость загрузки напрямую влияет на поведенческие факторы — время на сайте, отказы, глубину просмотра, — которые входят в расчёт ИКС. Медленный LCP (больше 4 секунд на мобильных) означает, что пользователь уходит до того, как увидел контент, и это фиксируется. В нише с высокой конкуренцией разница в 1-2 секунды LCP может определять, кто получает сниппет в Я.Нейро или Турбо-выдаче.
Как проверить вручную
- Google Search Console → Основные интернет-показатели. Откройте раздел «Основные интернет-показатели» (Core Web Vitals). Выберите отчёт для мобильных устройств. Посмотрите, сколько URL попали в группы «Плохо» и «Требует улучшения» по LCP. Это реальные данные CrUX, сгруппированные по шаблонам страниц.
- PageSpeed Insights с разделом «Полевые данные». Откройте pagespeed.web.dev, введите URL. Смотрите блок «Полевые данные» (Field Data) — там LCP из CrUX по конкретному URL за 28 дней. Синтетика в блоке «Лабораторные данные» — это другое, не путайте.
- Screaming Frog + PageSpeed API. В Screaming Frog включите: Configuration → API Access → PageSpeed Insights, укажите API-ключ. После краулинга в колонках появятся реальные данные CrUX, в том числе LCP для каждого URL. Удобно для массового аудита сотен страниц.
- Chrome DevTools → Performance. Нажмите F12, вкладка Performance, запишите загрузку страницы. В таймлайне найдите маркер LCP. Это синтетика, но помогает найти конкретный элемент, который является LCP-кандидатом.
Как исправить
Сначала определите, какой элемент является LCP. В PageSpeed Insights в разделе «Диагностика» будет прямое указание: «LCP-элемент — изображение /images/hero.jpg».
Типичные решения:
- Добавьте
fetchpriority="high"к LCP-изображению и уберитеloading="lazy"с него:
<img
src="/images/hero.webp"
alt="Описание"
fetchpriority="high"
width="1200"
height="600"
>- Предзагружайте LCP-изображение через
<link rel="preload">в<head>:
<link
rel="preload"
as="image"
href="/images/hero.webp"
fetchpriority="high"
>- Переведите изображения в формат WebP или AVIF — экономия 30-60% размера без потери качества.
- Используйте CDN для статики: Cloudflare, Selectel CDN, VK Cloud.
По CMS:
- WordPress: установите плагин Perfmatters или WP Rocket. В настройках укажите LCP-изображение для преднагрузки. Включите WebP через ShortPixel.
- Tilda: в настройках сайта включите «Оптимизация изображений». Для кастомного кода добавьте
fetchpriority="high"через HTML-блок T123. - 1C-Bitrix: в настройках модуля «Главный модуль» включите отложенную загрузку изображений, но для LCP-элемента явно добавьте
fetchpriority="high"через шаблон компонента. - Webflow: в настройках изображения снимите галочку «Lazy load» у hero-изображения. Добавьте preload через Custom Code в Head.
Типичные ошибки
- Lazy load на LCP-элементе. Добавили
loading="lazy"глобально на все изображения — LCP деградировал до 5+ секунд. Правило: первое изображение в области просмотра никогда не должно быть lazy. - Ориентируются только на синтетику. PageSpeed Insights показывает 90 баллов, а реальные данные в Search Console — красная зона. Синтетика измеряет в идеальных условиях; реальные пользователи на мобильных получают другой опыт.
- Фоновое изображение через CSS как LCP-элемент. CSS background-image браузер обнаруживает позже, чем
<img>. Если hero — этоbackground-imageв CSS, замените на тег<img>сfetchpriority="high". - Не накоплена база CrUX. Для новых или малопосещаемых страниц CrUX данных нет — Search Console покажет «недостаточно данных». Синтетика в этом случае — единственный ориентир, но не финальная метрика.
- Сервер медленно отвечает (TTFB > 600 мс). LCP не улучшится без быстрого первого байта — браузер не может рендерить то, что не получил. Сначала оптимизируйте TTFB, потом LCP.
Влияние на разные типы сайтов
Для интернет-магазинов LCP критичен на страницах категорий и карточек товаров: там LCP-элементом обычно является главное фото товара. При медленном LCP на мобильных пользователи уходят до просмотра цены — прямая потеря конверсии. В крупных каталогах на 1C-Bitrix часто встречается ситуация, когда LCP-изображение подключается через слайдер с JavaScript: браузер ждёт выполнения скрипта, прежде чем показать картинку, и реальный LCP улетает за 5 секунд.
Контентные сайты (блоги, медиа) чаще имеют LCP-элементом текстовый блок или иллюстрацию к статье. Здесь проблема — шрифты, загружаемые через Google Fonts или Яндекс.Шрифты: пока шрифт не загрузился, браузер не рендерит текст (FOIT). Решение — font-display: swap и предзагрузка шрифтов. SaaS-продукты и лендинги с одной страницей обычно имеют лучший контроль над LCP, но и здесь видео-постеры и анимированные hero-блоки регулярно становятся причиной плохих реальных данных.