LCP практически: как ускорить главный элемент первого экрана

LCP (Largest Contentful Paint) — это время, через которое на экране появляется самый крупный значимый элемент: чаще всего большая картинка первого экрана, заголовок H1 или баннер. Если LCP больше 2,5 секунды, пользователь воспринимает сайт как «медленный», даже если технически он уже работает.

01Что такое LCP и какие значения считаются нормой

LCP появилась в наборе Core Web Vitals, чтобы заменить расплывчатые «загрузка страницы» и «время до интерактивности» одной понятной цифрой: момент, когда самый большой элемент на видимой области экрана становится видимым.

Ориентиры по LCP:

• ≤ 2,5 секунды — хорошо, страница ощущается быстрой.
• 2,5–4,0 секунды — требует улучшения.
• > 4,0 секунд — плохо, ощущается как тормоз.

Важно: PageSpeed Insights показывает не одну цифру, а реальные данные пользователей из Chrome (поле «полевые данные») и лабораторный замер (Lighthouse). Решает поле — это то, что Google и Яндекс реально видят у ваших посетителей. Лабораторная цифра — для быстрых проверок.

02Как понять, какой элемент является LCP на вашей странице

Это первая и самая частая ошибка: оптимизируют «всё подряд», не понимая, какой элемент тянет метрику вниз. Узнать его легко.

• Chrome DevTools → Performance. Запишите загрузку страницы — на таймлайне появится отметка «LCP» рядом с конкретным элементом.
• Lighthouse в DevTools. В отчёте Performance в разделе «Largest Contentful Paint element» прямо подсвечивается виновник.
• PageSpeed Insights. В блоке «Аудит» раскройте «Самая большая отрисовка контента» — будет HTML-сниппет элемента.

Чаще всего LCP-элементом оказывается одно из трёх: большая картинка героя на первом экране, видеопостер или крупный заголовок H1 с подзаголовком. Дальше тактика зависит от того, что именно стало LCP.

03Если LCP — это картинка

В 80% случаев на типовых сайтах LCP-элемент — это большая картинка первого экрана. Тогда работают четыре приёма (в порядке убывания эффекта):

1. Современный формат и правильный размер

Переведите ключевые изображения в WebP или AVIF. Картинка героя 1920×1080 в JPEG может весить 400 КБ, в WebP — 90 КБ при том же качестве. Это пример порядка цифр — у вас может быть иначе, но выигрыш почти всегда заметный.

Параллельно проверьте, что вы не отдаёте картинку 4000 пикселей шириной для блока, который физически 1200 пикселей. Используйте `srcset` и `sizes`, чтобы браузер сам выбирал нужный вариант для разрешения экрана.

2. fetchpriority=”high” на главную картинку

Браузер по умолчанию считает изображения менее приоритетными, чем CSS и JS. Атрибут `fetchpriority=”high”` у тега “ главного изображения говорит браузеру: грузи это в первую очередь.

3. Никакого lazy-loading у LCP-картинки

Это самая болезненная и частая ошибка. Контент-менеджер ставит `loading=”lazy”` на все изображения «для скорости» — и LCP вместо 1,5 секунды становится 4. Картинка первого экрана должна грузиться сразу, без `loading=”lazy”`.

4. Preload в head

`<link rel=”preload” as=”image” href=”hero.webp”>` в шапке страницы — даёт браузеру понять про важную картинку ещё до того, как он встретит её в HTML. Особенно полезно, если картинка ставится фоном через CSS.

04Если LCP — это текст

Чаще такое бывает на длинных лонгридах или одностраничниках, где первый экран — большой H1 без картинки. Здесь тормозит не сам текст, а блокирующие ресурсы перед ним.

• Уберите блокирующий CSS. Перенесите критический CSS первого экрана inline в `<style>` в head, остальное — через `media` или асинхронно.
• Уберите блокирующий JS из head. Скрипты аналитики, чатов, виджетов оплат — все они должны быть `async` или `defer`, а лучше — в конце body.
• Шрифты. Подключайте только нужные начертания, ставьте `font-display: swap`, чтобы текст рендерился временным шрифтом, не дожидаясь загрузки кастомного.

05Серверная часть: TTFB и время первого байта

LCP не может быть меньше TTFB (Time To First Byte) — времени, через которое сервер начал отвечать. Если сам сервер думает 1,5 секунды, никакая работа с картинками не даст вам LCP в 2 секунды.

Что обычно помогает:

• Кэширование на стороне сервера. Для WordPress — серверный кэш или плагины (WP Rocket, LiteSpeed Cache). Подробнее — в разделе про скорость.
• CDN. Особенно если посетители географически распределены или вы продаёте по всей РФ.
• Адекватный хостинг. Дешёвый шаред-хостинг с overselling — главная причина высокого TTFB у малого бизнеса.
• Чистка плагинов и тяжёлых тем. Чем больше код, который выполняется при каждом запросе, тем дольше сервер собирает HTML.

06Чего делать НЕ нужно

Несколько популярных «оптимизаций», которые на LCP либо не влияют, либо делают хуже:

• Минификация HTML вручную. Эффект на LCP — десятки миллисекунд, времени отнимает много.
• Удаление jQuery ради «лёгкости» темы, после которого сайт неделю не работает. Если jQuery не блокирующий — не трогайте.
• Перевод картинки в base64 в HTML. Увеличивает размер HTML, ухудшает кэшируемость.
• Lazy-load на всё подряд. Особенно на картинку первого экрана — это прямой путь к плохому LCP.

07Как замерить эффект и не обмануться

Любую правку проверяйте дважды: в инкогнито с очищенным кэшем (для лабораторного замера) и через несколько дней в полевых данных PageSpeed Insights. Полевые данные обновляются с задержкой — Chrome копит выборку 28 дней.

Тестируйте на 4G-профиле и среднем телефоне, а не на ноутбуке с гигабитным интернетом. Реальный мобильный пользователь увидит цифры в 2–3 раза хуже, чем ваш десктоп. Подробнее о Core Web Vitals в целом — в нашем материале «Core Web Vitals», общий разбор ускорения сайта — в статье «Как ускорить загрузку сайта».

Официальная документация по теме — Справка Яндекс.Вебмастера.