LCP реальный (Core Web Vitals)

Что это

LCP (Largest Contentful Paint) — метрика Core Web Vitals, которая измеряет время отрисовки самого крупного видимого элемента на странице: обычно это hero-изображение, крупный блок текста или видео-постер. Реальный LCP — это данные из отчёта Chrome User Experience Report (CrUX), собранные на основе фактических посещений пользователей, а не лабораторного теста. Именно эти данные Google использует для ранжирования в рамках Page Experience сигнала.

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

Google официально подтвердил, что Core Web Vitals влияют на ранжирование с мая 2021 года. Пороговые значения: до 2,5 с — хорошо, 2,5–4,0 с — нужно улучшить, свыше 4,0 с — плохо. По данным исследования Backlinko (2023, выборка 11 млн страниц), страницы с хорошим LCP на 24% чаще попадают в топ-3, чем страницы с плохим LCP.

Важен именно реальный LCP, а не лабораторный. PageSpeed Insights может показывать зелёный результат в симуляции, но если реальные пользователи с медленным мобильным интернетом видят страницу за 5+ секунд — Google это фиксирует. CrUX аккумулирует данные за последние 28 дней с реальных устройств Chrome. Для Яндекса прямого аналога Core Web Vitals нет, но скорость загрузки влияет на поведенческие факторы (отказы, глубина просмотра), а значит — на ИКС и ранжирование в результатах Я.Нейро и обычной выдаче.

Как проверить вручную

1. Google Search Console → Основные веб-показатели. Откройте отчёт, выберите мобильные или десктоп. Там видны реальные данные CrUX по группам URL. Красный статус = LCP >4,0 с у значительной доли пользователей.

1. PageSpeed Insights (web.dev/measure). Введите URL. В разделе "Данные о реальных пользователях" смотрите блок "Largest Contentful Paint" — именно верхнюю карточку с реальными данными, не раздел "Диагностика".

1. Chrome DevTools → Performance. Откройте вкладку Performance, нажмите Record, перезагрузите страницу. В таймлайне найдите маркер LCP — он показывает, какой именно элемент стал LCP и в какой момент.

1. Screaming Frog + PageSpeed API. В настройках Screaming Frog подключите Google PageSpeed API (Configuration → API Access → PageSpeed). При сканировании будут подтягиваться лабораторные данные LCP по каждому URL — полезно для массового аудита.

1. Топвизор → Анализ страниц. Позволяет отслеживать Core Web Vitals в динамике для списка URL без ручных проверок.

Как исправить

Шаг 1. Определите LCP-элемент. В Chrome DevTools откройте консоль и выполните:

new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const last = entries[entries.length - 1];
  console.log('LCP element:', last.element, '| time:', last.startTime);
}).observe({ type: 'largest-contentful-paint', buffered: true });

Шаг 2. Оптимизируйте LCP-элемент по типу.

Для изображений — конвертируйте в WebP/AVIF, добавьте fetchpriority="high" и уберите loading="lazy":

<img src="hero.webp" fetchpriority="high" alt="..." width="1200" height="600">

Для текстового блока — убедитесь, что шрифт загружается с font-display: swap и preload:

<link rel="preload" href="/fonts/main.woff2" as="font" type="font/woff2" crossorigin>

Решения по CMS:

• WordPress: плагин Perfmatters или WP Rocket — включите опцию "Preload LCP Image". Дополнительно — Imagify для WebP.
• Tilda: в настройках сайта включите "Оптимизация изображений". Hero-блок выгружайте уже в WebP вручную, Tilda не конвертирует автоматически.
• 1C-Bitrix: в настройках модуля "Веб-аналитика" активируйте CDN. В компонентах вручную добавьте fetchpriority="high" к главному изображению в шаблоне.
• Webflow: в настройках Asset Panel выберите формат WebP. Для hero добавьте кастомный атрибут fetchpriority = high через панель элемента.

Шаг 3. Устраните задержки сервера (TTFB). Если TTFB >600 мс, LCP не будет хорошим независимо от оптимизации изображений. Проверьте через PageSpeed Insights → "Сократите время ответа сервера". Решения: CDN (CloudFlare, Selectel CDN), кэширование на уровне сервера, переход на более быстрый хостинг.

Типичные ошибки

• `loading="lazy"` на hero-изображении. Браузер откладывает загрузку главной картинки — LCP уходит за 4 с. Lazy load ставьте только на изображения ниже первого экрана.
• Нет preload для критического изображения. Браузер обнаруживает его поздно — после парсинга CSS и JS. Добавьте <link rel="preload"> в <head>.
• Ориентация только на лабораторные данные. PageSpeed в режиме симуляции не учитывает реальные условия сети и устройства пользователей. Всегда сверяйтесь с GSC и CrUX.
• Игнорирование мобильного LCP. Google индексирует в mobile-first режиме. Десктопный LCP 1,8 с при мобильном 5,2 с — проблема для ранжирования.
• Подключение сторонних скриптов в `<head>` без `async/defer`. Аналитика, чат-виджеты, пиксели блокируют рендер и задерживают LCP на 1–3 с.

Влияние на разные типы сайтов

Для интернет-магазинов LCP критичен на страницах категорий и карточек товаров: главное изображение товара почти всегда становится LCP-элементом. На крупных каталогах (1 000+ SKU) медленный LCP на мобильных прямо влияет на конверсию — по данным Google, улучшение LCP с 4 с до 2 с снижает показатель отказов на 35%. Турбо-страницы Яндекса здесь не помогут: они отдельный документ и не улучшают LCP основного сайта.

Для контентных сайтов (блоги, медиа) LCP-элементом чаще оказывается первый абзац текста или обложка статьи. Здесь главные рычаги — быстрый TTFB хостинга и отсутствие блокирующих шрифтов. SaaS-лендинги обычно имеют одну-две посадочные страницы — их проще контролировать, но hero-секция с видео-фоном регулярно ломает LCP: заменяйте автовоспроизводимое видео на статичное изображение с имитацией анимации через CSS.