Измерить LCP (Largest Contentful Paint)

Зачем измерять LCP

LCP (Largest Contentful Paint) — время, за которое браузер отрисовывает самый крупный видимый элемент на экране: hero-изображение, баннер, основной заголовок или крупный блок текста. Google использует LCP как один из трёх Core Web Vitals для оценки скорости загрузки. Если LCP больше 2,5 секунд — страница считается медленной, и это напрямую влияет на ранжирование.

По моему опыту, LCP — самая понятная метрика из трёх Core Web Vitals. Пользователь открывает страницу и ждёт, пока появится основной контент. Если ждать дольше 2,5 секунд — часть аудитории уходит. В коммерческих нишах каждая секунда задержки снижает конверсию на 7-12%. А для Яндекса скорость загрузки тоже входит в поведенческие факторы: медленный сайт получает больше отказов, что снижает позиции.

Целевые значения LCP

• Хорошо: до 2,5 секунд — страница загружается быстро, Google не понижает позиции за скорость
• Требует улучшения: 2,5-4 секунды — жёлтая зона, нужна оптимизация, позиции могут страдать
• Плохо: больше 4 секунд — критическая проблема, прямые потери трафика и позиций в обоих поисковиках

Пошаговая инструкция: как измерить LCP

Шаг 1. Проверьте полевые данные в PageSpeed Insights

Откройте PageSpeed Insights и введите URL страницы. В верхней части отчёта отображаются реальные данные пользователей (CrUX — Chrome User Experience Report). Это полевые метрики — именно их Google учитывает при ранжировании. Если у сайта достаточно трафика из Chrome, вы увидите распределение LCP по зонам: зелёная, жёлтая, красная.

Полевые данные — приоритет. Лабораторный тест может показывать отличные результаты, но если реальные пользователи заходят с медленных смартфонов через мобильный интернет — полевой LCP будет хуже. Именно полевые данные определяют, получит ли сайт бонус за скорость в ранжировании.

Шаг 2. Запустите лабораторный тест в Lighthouse

В Chrome DevTools (F12) перейдите на вкладку Lighthouse. Выберите категорию Performance, режим Mobile и нажмите Analyze. В результатах найдите строку Largest Contentful Paint — это лабораторное значение. Оно полезно для диагностики: лабораторный тест стабилен и воспроизводим, можно сравнивать результаты до и после оптимизации.

Для чистого теста используйте режим инкогнито — расширения браузера искажают результат. Также учитывайте, что мощность вашего компьютера влияет на лабораторные метрики. Для объективности используйте несколько инструментов.

Шаг 3. Определите LCP-элемент

В отчёте Lighthouse раскройте секцию «Largest Contentful Paint element». Там указан конкретный HTML-элемент, который браузер определил как самый крупный видимый. Чаще всего это:

• Hero-изображение в шапке страницы
• Фоновое изображение, заданное через CSS (background-image)
• Крупный блок текста (заголовок H1 или первый абзац)
• Видео-постер или первый кадр встроенного видео

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

Шаг 4. Проверьте данные в Google Search Console

В Search Console откройте отчёт «Основные интернет-показатели» (Core Web Vitals). Здесь собраны данные по всем страницам сайта, сгруппированные по статусу. Отчёт показывает тренд за 90 дней — можно отследить, улучшается ситуация после ваших оптимизаций или ухудшается.

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

Шаг 5. Используйте Web Vitals Extension для быстрого мониторинга

Установите расширение Web Vitals для Chrome. Оно показывает LCP, CLS и INP в реальном времени при обычном просмотре сайта. Удобно для быстрой проверки отдельных страниц без запуска полного аудита.

Основные причины медленного LCP и как их исправить

Медленный ответ сервера (TTFB)

TTFB (Time to First Byte) — время от запроса до первого байта ответа сервера. Если сервер отвечает дольше 600 мс — LCP автоматически будет плохим, потому что браузер даже не начал получать HTML.

Проверьте TTFB в Lighthouse (секция «Server Response Time»). Решения по приоритету:

• Серверное кеширование страниц. Для WordPress — плагины WP Super Cache, W3 Total Cache или LiteSpeed Cache (если сервер на LiteSpeed). Кешированная страница отдаётся за 50-100 мс вместо 500-2000 мс.
• Object Cache (Redis или Memcached). Кеширует результаты запросов к базе данных. На сайтах с большим количеством плагинов это может ускорить генерацию страницы в 3-5 раз.
• CDN (Content Delivery Network). Раздаёт статику (CSS, JS, изображения) с ближайшего к пользователю сервера. Для российской аудитории хорошо работают Cloudflare, а также CDN от Selectel и VK Cloud.
• Переход на более быстрый хостинг. Если TTFB стабильно выше 1 секунды даже с кешем — проблема в хостинге. Связка nginx + PHP-FPM + Redis на VPS даёт TTFB 50-200 мс для WordPress.

Пример из практики: на одном проекте перевод с shared-хостинга на VPS с nginx и Redis уменьшил TTFB с 1800 мс до 120 мс. LCP упал с 4,2 до 1,8 секунд на мобильных. Это было самое результативное изменение за весь проект — ни одна оптимизация изображений не дала бы такого эффекта при медленном сервере.

Тяжёлые изображения — главная причина плохого LCP

Если LCP-элемент — изображение (а это в 70-80% случаев), оптимизация картинки даёт самый быстрый результат.

Конвертация в современные форматы. WebP весит на 25-35% меньше JPEG при том же качестве. AVIF — ещё на 20% меньше WebP, но поддержка браузеров пока неполная. Для WordPress используйте плагины ShortPixel, Imagify или EWWW Image Optimizer — они конвертируют автоматически и отдают WebP/AVIF через тег <picture> или правила .htaccess.

Правильные размеры. Hero-баннер шириной 1920px не нужен на мобильном экране 375px. Используйте атрибут srcset для отдачи разных размеров изображения разным устройствам. Для LCP-изображения на десктопе достаточно ширины контейнера, на мобильных — ширины экрана.

Целевой вес. Hero-изображение не должно весить больше 100-150 КБ. Если после сжатия в WebP картинка весит 300+ КБ — уменьшите разрешение или повысьте степень сжатия. Качество 75-80% в WebP визуально не отличается от 100%, но весит в 2-3 раза меньше.

Предзагрузка LCP-изображения. Добавьте в <head> страницы:

<link rel="preload" as="image" href="/path/to/hero.webp" type="image/webp">

Это сообщает браузеру: «Начни загрузку этого изображения сразу, не дожидаясь парсинга CSS и HTML.» Предзагрузка может улучшить LCP на 200-500 мс.

Атрибут fetchpriority=»high». Добавьте к LCP-изображению:

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

Этот атрибут повышает приоритет загрузки изображения в очереди браузера. И обязательно: не ставьте loading="lazy" на LCP-изображение — это задержит его загрузку и резко ухудшит метрику.

Пример до/после: PNG-баннер 1920×800, вес 820 КБ, LCP 3,8 с. После: WebP 1200×500 с srcset, вес 95 КБ, preload + fetchpriority=»high». LCP стал 1,6 с. Разница — 2,2 секунды только за счёт оптимизации одного изображения.

Critical CSS — убираем блокировку рендеринга

Браузер не начнёт отрисовку, пока не загрузит и не обработает весь CSS. Если файл стилей весит 200 КБ, а для первого экрана нужно только 15 КБ — остальные 185 КБ блокируют отрисовку впустую.

Решение — Critical CSS: вынести стили первого экрана в инлайновый блок <style> прямо в HTML, а остальной CSS загружать асинхронно. Для WordPress это делают плагины Autoptimize (с опцией Critical CSS) или WP Rocket. Ручной способ — использовать Critical от Addy Osmani.

Некритичный CSS загружайте отложенно:

<link rel="stylesheet" href="style.css" media="print" onload="this.media='all'">

Этот приём говорит браузеру: «Загрузи файл, но не блокируй рендеринг.» После загрузки атрибут media переключается на all, и стили применяются.

JavaScript — убираем блокирующие скрипты

Синхронный JavaScript блокирует парсинг HTML. Каждый <script src="..."> без атрибута defer или async останавливает рендеринг, пока скрипт не загрузится и не выполнится.

• defer — скрипт загружается параллельно с HTML, выполняется после полного парсинга. Подходит для большинства скриптов.
• async — скрипт загружается параллельно и выполняется сразу после загрузки, не дожидаясь парсинга. Подходит для независимых скриптов (аналитика, виджеты).

Сторонние скрипты (Яндекс Метрика, чат-виджеты, рекламные пиксели) особенно опасны для LCP, если загружаются синхронно. Перенесите их загрузку после события DOMContentLoaded или используйте загрузку по взаимодействию: скрипт чата загружается только после первого скролла или клика пользователя.

Веб-шрифты

Загрузка кастомных шрифтов может блокировать отрисовку текста на 1-3 секунды. Если LCP-элемент — текстовый блок (заголовок H1), медленная загрузка шрифта напрямую увеличивает LCP.

Решения:

• Добавьте font-display: swap в объявления @font-face — текст сразу отрисуется системным шрифтом, а после загрузки перерисуется кастомным.
• Предзагрузите критические шрифты: <link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>
• Если шрифт подключается с Google Fonts — добавьте <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin> в head для ускорения DNS-резолвинга.
• Используйте формат WOFF2 — он сжат на 30% лучше, чем WOFF, и поддерживается всеми современными браузерами.

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

• Оптимизировать только лабораторные метрики. Google учитывает полевые данные CrUX. Можно получить 100 баллов в Lighthouse на мощном компьютере и при этом иметь красный LCP в Search Console — если реальные пользователи заходят с бюджетных смартфонов через 3G.
• Ставить lazy loading на LCP-изображение. Атрибут loading="lazy" отложит загрузку главного элемента, и LCP резко ухудшится. Lazy loading — только для изображений ниже первого экрана.
• Игнорировать мобильную версию. Google оценивает Core Web Vitals отдельно для мобильных и десктопных устройств. На мобильных LCP почти всегда хуже из-за медленного процессора и сети. Mobile-first индексирование означает, что мобильные метрики приоритетнее.
• Не учитывать разный LCP-элемент на разных устройствах. На десктопе LCP-элемент может быть hero-изображением 1920×800, а на мобильном — заголовком H1. Оптимизировать нужно оба варианта.
• Оптимизировать всё, кроме сервера. Никакое сжатие изображений не поможет, если сервер отвечает 2 секунды. Всегда начинайте с TTFB — это фундамент.
• Предзагружать слишком много ресурсов. Preload конкурирует за пропускную способность. Если предзагрузить 10 файлов, ни один не загрузится быстро. Предзагружайте только LCP-изображение и критический шрифт — максимум 2-3 ресурса.

Что проверить в итоге

• LCP в полевых данных PageSpeed Insights ниже 2,5 секунд для мобильных и десктопных.
• В Search Console нет страниц со статусом «Плохо» по LCP.
• LCP-элемент определён и оптимизирован: если изображение — сжато в WebP/AVIF, имеет fetchpriority=»high» и preload.
• TTFB сервера не превышает 600 мс (в идеале — до 200 мс с кешем).
• Серверное кеширование настроено и работает (проверьте заголовок X-Cache или HIT/MISS).
• Critical CSS инлайнится для первого экрана, некритичный CSS загружается отложенно.
• Все скрипты загружаются с defer или async, синхронных блокирующих скриптов нет.
• Шрифты используют font-display: swap и preload для критических начертаний.
• Сторонние скрипты не блокируют рендеринг первого экрана.
• На LCP-изображении нет атрибута loading=»lazy».