Core Web Vitals: как снизить LCP ниже 2,5 секунды

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

1. Что такое LCP и почему порог — 2,5 секунды?

LCP показывает, когда после начала загрузки страницы отрисовывается самый крупный визуальный элемент в области просмотра (обычно это hero-изображение, крупный заголовок или постер видео). В Core Web Vitals хорошим считается значение 2,5 секунды, средним — 2,5–4,0 с, плохим — выше 4,0 с.

У LCP три составляющие: TTFB (время ответа сервера), время загрузки ресурса (скачивание изображения или шрифта) и задержка рендеринга (сколько времени браузеру нужно, чтобы отрисовать элемент). Если оптимизировать, не измеряя эти три части по отдельности, ресурсы обычно тратятся не там, где нужно.

2. Сначала — корректные измерения: lab или field?

Оценка Lighthouse — это лабораторный прогноз, она не отражает реальный опыт пользователей. Для принятия решений используйте полевые данные (CrUX / отчёт Core Web Vitals в Search Console / RUM). Разрыв часто бывает большим: пользователь на 3G может видеть LCP 4,8 с, тогда как Lighthouse на десктопе в вашем офисе показывает 1,9 с.

Три составляющие LCP и целевые значения

Компонент	Формула / измерение	Цель
TTFB	Время ответа сервера (мс)	< 800 мс
Загрузка ресурса	Время скачивания изображения/шрифта	< 700 мс
Задержка рендеринга	Ожидание JS/CSS перед отрисовкой	< 1000 мс

Итого < 2500 мс. Как только вы заполните эту таблицу, станет понятно, за какой рычаг тянуть.

3. 6 самых частых причин медленного LCP и способы их устранения

• Ленивая загрузка hero-изображения: Никогда не применяйте lazy-load к LCP-элементу. Используйте loading="eager" и fetchpriority="high".
• Неправильный формат и размер: перейдите на WebP/AVIF и отдавайте на мобильных размер 1x через адаптивный srcset. JPEG на 2 МБ добавляет в среднем 900 мс–1,5 с дополнительной загрузки на мобильных по сравнению с WebP на 120 КБ.
• Блокировка шрифтами: используйте font-display: swap и preload, чтобы загружать критичный шрифт заранее.
• Блокирующие рендеринг CSS/JS: встраивайте критичный CSS инлайном, остальное откладывайте. Разделяйте крупные JS-бандлы по маршрутам.
• Медленный TTFB: сокращайте его за счёт кэширования на сервере/CDN, edge-кэша и оптимизации запросов к базе данных. Снижение TTFB с 1,2 с до 0,5 с напрямую улучшает LCP.
• Сторонние скрипты: откладывайте чат, A/B-тесты и скрипты таг-менеджера с помощью defer. Каждый лишний тег добавляет 100–300 мс к задержке рендеринга.

4. Пошаговый план действий на 30 дней

Выстройте цикл: измерение → постановка целей → внедрение → проверка.

• Дни 1–3: с помощью RUM разложите распределение LCP по типам страниц (главная, категория, товар, блог). Зафиксируйте значение P75.
• Дни 4–7: определите LCP-элемент (маркер «LCP» на панели Performance в DevTools). Измерьте TTFB, загрузку ресурса и рендеринг по отдельности.
• Дни 8–20: внедрите 2–3 самых результативных пункта из шести перечисленных выше. Обычно быстрее всего дают эффект оптимизация изображений и критичный CSS.
• Дни 21–30: повторно измерьте P75 LCP на тех же страницах. Цель: ≥ 75% пользователей быстрее 2,5 с.

Пример расчёта

LCP главной страницы = 4,1 с. Диагностика: TTFB 1,4 с + загрузка изображения 1,9 с + рендеринг 0,8 с. Что сделали: с edge-кэшем CDN TTFB снизился с 1,4 → 0,6 с; с WebP и правильными размерами загрузка изображения — с 1,9 → 0,5 с. Новый LCP ≈ 0,6 + 0,5 + 0,8 = 1,9 с. Это ниже порога.

Здоровее всего запускать такой цикл измерений и внедрения с командой web design & development, которая ведёт контент и техническую часть вместе, либо в рамках процесса SEO, построенного на аудите. Поскольку ускорение напрямую влияет на конверсию в рекламе, его стоит планировать в одном роадмапе с ad management.

5. Проверка и непрерывность

LCP — не разовая задача. Новые изображения товаров, скрипты и изменения темы могут снова его ухудшить. Поэтому стоит:

• автоматически формировать ежемесячный отчёт P75 в RUM;
• задавать бюджет LCP перед запуском нового типа страниц (например, < 2,2 с);
• измерять влияние на производительность при добавлении сторонних скриптов и убирать лишние.

Если вы хотите управлять этим на уровне организации, подход 360° digital marketing позволяет вести и измерения, и внедрение в одних руках. Ускорение также повышает отдачу от трафика, который вы привлекаете через рекламу, — ведь более быстрая страница означает более дешёвые конверсии.

Давайте вместе оценим текущие Core Web Vitals вашего сайта. Свяжитесь с нами через страницу contact для бесплатного ознакомительного звонка.