LCP больше 2,5 секунд: основные причины и как ускорить главную страницу

LCP это время до отрисовки самого крупного элемента первого экрана, порог 2,5 секунды. Уезжает он обычно из-за трёх вещей: тяжёлой картинки в шапке, медленного ответа сервера и блокирующих стилей со шрифтами. Разбирать надо в этом порядке, а не переделывать главную.

В Search Console прилетело письмо: «У вашего сайта плохой LCP, требуется улучшение». В PageSpeed Insights мобильная версия показывает 4,2 секунды красным цветом. Подрядчик предлагает переделать главную за 80 тысяч рублей. До этого варианта обычно не доходит, потому что у LCP всегда есть две-три конкретные причины, которые ловятся за час и чинятся за день.

В этой статье разберу, что именно меряет LCP, почему он постоянно уезжает за 2,5 секунды и какие приёмы реально работают на главной странице сайта малого бизнеса. Без воды и без советов перейти на Next.js.

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

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

Браузер сам решает, что считать «самым большим», по площади видимой области. Перебирает кандидатов и выбирает тот, который занимает больше всего пикселей экрана. Метрика фиксируется в момент, когда этот элемент стал виден пользователю.

Порог 2,5 секунды Google взял не с потолка. Исследования UX показывают, что после 2,5 секунд ожидания заметно растёт процент отказов. После 4 секунд он скачет резко вверх. Поэтому пороги такие:

• Хорошо: до 2,5 секунды.
• Требует улучшения: от 2,5 до 4 секунд.
• Плохо: больше 4 секунд.

Замер ведётся по 75-му перцентилю реальных пользователей за 28 дней. Если три четверти ваших посетителей видят основное содержимое за 2,5 секунды, метрика зелёная. Если 25 процентов ждут дольше — подкрашивается жёлтым.

В Search Console и PageSpeed это считается отдельно для мобильной и десктопной версии. На мобильном цифра почти всегда хуже из-за слабого процессора и сети 4G.

Почему именно главная страдает чаще всего

На главной обычно тяжёлый hero: большая картинка, видео-фон, слайдер с тремя баннерами. Дизайнер сделал красиво, разработчик не подумал про вес, владелец не проверил. В результате основной элемент LCP — это та самая hero-картинка, которая весит 800 КБ в исходном JPG, ещё и грузится в десятом приоритете.

На внутренних страницах LCP обычно лучше: заголовок и первый абзац рендерятся почти моментально. Картинка под текстом в счёт LCP не идёт, если она вне первого экрана.

Семь самых частых причин, почему LCP уехал

Я веду список того, что нахожу при аудитах. Вот топ-7 за последние два года, в порядке частоты.

1. Тяжёлая hero-картинка без современного формата

Самая частая причина в моей практике. Дизайнер отдаёт PSD, разработчик экспортирует в JPG с качеством 90 или вообще в PNG, картинка весит 600-1500 КБ. На мобильном через 4G такая картинка грузится 2-4 секунды, и ровно эти секунды добавляются к LCP.

Лечится конвертацией в WebP с качеством 75-80. Размер падает в 3-5 раз без видимой потери. Если хочется ещё агрессивнее, AVIF даёт ещё минус 30 процентов, но поддержка в старых браузерах хуже.

Команда для ImageMagick:

convert hero.jpg -quality 80 -resize 1920x hero.webp

Или через cwebp напрямую:

cwebp -q 80 hero.jpg -o hero.webp

После конверсии не забыть про <picture> с фолбэком, иначе IE и старые браузеры покажут битую картинку.

2. Шрифты с CDN, которые блокируют рендер

Если на сайте подключены Google Fonts через стандартный сниппет с fonts.googleapis.com, браузер сначала качает CSS-файл шрифта, потом сами файлы шрифтов, и только потом рендерит текст. На медленной сети это +500-1500 мс к LCP, если ваш LCP-элемент — это заголовок.

Плюс, в России Google Fonts с CDN периодически тормозит из-за блокировок и роутинга. Решение: self-hosted шрифты. Скачайте файлы один раз, положите на свой хостинг, подключите через @font-face с font-display: swap и предзагрузкой основного веса:

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

Дополнительный плюс: соответствие 152-ФЗ. Google Fonts с CDN передаёт IP пользователя в США без согласия, что технически нарушение закона.

3. Render-blocking JavaScript

Любой <script> без async или defer блокирует парсинг HTML до того, как он выполнится. Если у вас в <head> подключены jQuery, Bootstrap, скрипт слайдера и три виджета — браузер сначала качает все их, потом исполняет, и только потом начинает рендерить страницу.

Правило простое: всё, что можно, переносим в defer. Если скрипт нужен только после загрузки — в async. Метрика и пиксели — только async:

<script async src="https://mc.yandex.ru/metrika/tag.js"></script>
<script defer src="/js/main.js"></script>

4. Медленный TTFB

Time To First Byte — сколько браузер ждёт первый байт ответа от сервера. Если хостинг тупит 1,5 секунды до того, как HTML вообще полетел — вы уже не уложитесь в 2,5 секунды для LCP, как ни старайся.

Что чинит TTFB:

• Свежий PHP (8.2 или 8.3 в 2026), OPcache включён.
• Кэш страниц в CMS (W3 Total Cache, WP Super Cache, кэш в Битриксе).
• Переход с shared на VPS, если на shared уже всё выжали.
• Для интернет-магазинов — Redis или Memcached для сессий.

На дешёвом shared TTFB часто 800-1500 мс просто из-за нагрузки соседей. На VPS среднего уровня — 100-300 мс.

5. Lazy на hero-картинке

Эта причина бесит особенно. Разработчик в едином порыве оптимизации поставил loading="lazy" на все картинки сайта, включая ту, что в hero на первом экране. Браузер честно ждёт, пока пользователь начнёт скроллить, прежде чем грузить картинку. LCP уезжает за 5 секунд.

Лечится снятием атрибута и добавлением приоритета:

<img
  src="/img/hero.webp"
  width="1200"
  height="600"
  alt="Главное фото на странице"
  fetchpriority="high"
/>

fetchpriority="high" говорит браузеру: эту картинку грузить первой среди равных. Поддержка в Chrome, Edge и Safari — есть. В Firefox добавили в 2024 году.

6. Плохой CDN или его отсутствие

Если ваш сервер в Москве, а пользователь во Владивостоке, время доставки HTML и картинок прибавляет 100-200 мс к каждому ресурсу. Для крупных файлов это набегает.

CDN для российской аудитории: BunnyCDN (есть точки в РФ), Selectel CDN, edge от Timeweb или Beget. Для статики (CSS, JS, картинки) подключение CDN даёт минус 200-500 мс к LCP на удалённых от Москвы регионах.

Не подключайте Cloudflare для российского трафика без размышлений: точек в России у них нет, всё через Амстердам или Франкфурт. Для иностранной аудитории — отлично, для российской — сомнительно.

7. Рендер на клиенте

Если ваш сайт собран на чистом React, Vue или Angular без SSR — браузер сначала качает HTML почти пустой, потом качает бандл JS, исполняет его, делает запросы к API, и только потом рендерит контент. LCP тогда легко уезжает за 4-5 секунд.

Если вы с этим столкнулись на готовом проекте — вариантов немного: либо переходить на SSR/SSG (Next.js, Astro, Nuxt), либо хотя бы сделать prerender для статичных страниц. Большая работа, не ловится оптимизацией картинок.

Для нового проекта малого бизнеса я почти всегда советую Astro или статику — там LCP по умолчанию в норме без всяких усилий.

Как найти LCP-элемент на своей странице

Самый быстрый способ — Chrome DevTools. Открываете страницу, F12, вкладка Performance, кнопка с круглой стрелкой «Reload and record». После записи в timeline появится отметка LCP с миниатюрой того элемента, который браузер считает самым большим.

Альтернативные способы:

• Web Vitals Extension — расширение для Chrome, показывает три метрики в углу. По клику открывает деталку.
• PageSpeed Insights — в отчёте есть секция «Largest Contentful Paint element» с миниатюрой и селектором.
• WebPageTest — детальный waterfall, видно, в какой момент браузер заметил LCP-кандидата.
• Lighthouse в DevTools — то же что PageSpeed, но локально.

Я обычно начинаю с PageSpeed: бесплатно, быстро, видно field data. Если нужно копнуть глубже — перехожу в DevTools.

Селектор LCP-элемента подсказывает причину

Если в PageSpeed ваш LCP — это img.hero, скорее всего проблема в самой картинке: формат, вес, lazy.

Если LCP — это h1.title или абзац — проблема, скорее всего, в шрифтах или TTFB. Текст не может появиться, пока не загружен шрифт или пока сервер не отдал HTML.

Если LCP — это div.banner-bg с фоновой картинкой — не забудьте, что фоновые картинки браузер грузит позже обычных. Лучше вставлять hero как настоящий <img>, а не background.

Что чинить в первый день, а что потом

Сводная таблица приоритетов:

Действие	Время	Эффект на LCP
Конвертация hero в WebP	30 минут	-500-1500 мс
Снять lazy с hero-картинки	5 минут	-300-2000 мс
Добавить fetchpriority high	5 минут	-100-300 мс
Self-hosted шрифты	1-2 часа	-200-800 мс
Перенос JS в defer	1 час	-100-400 мс
Включение кэша страниц в CMS	30 минут	-300-700 мс TTFB
Подключение CDN	2-3 часа	-100-500 мс
Переход на VPS	1 день	-300-800 мс TTFB
Перевод на SSG/SSR	от недели	-1500-3000 мс

В первый день обычно успеваешь пройти первые 5-6 пунктов и снять с проблемы 60-80 процентов веса. Дальше остаётся аккуратная инфраструктурная работа.

Чек-лист действий перед звонком разработчику

Если вы владелец и хотите проверить очевидное до того, как просить помощь:

• Открыть hero-картинку в браузере, посмотреть её размер. Если больше 200 КБ — это уже подозрительно.
• Через DevTools на вкладке Network посмотреть, сколько весит главная страница в сумме. До 1,5 МБ нормально, больше 3 МБ почти всегда тормозит.
• Глянуть, есть ли у hero-картинки в HTML атрибут loading="lazy". Если есть — попросить убрать.
• Прогнать PageSpeed для главной и для одной типовой внутренней страницы. Сравнить LCP.

Если эти простые проверки уже выявили проблему — можно справиться самому или дать подрядчику чёткое ТЗ вместо абстрактного «ускорьте сайт». Цены на готовые пакеты по ускорению — в тарифах.

Когда LCP уже хороший, но Google всё равно недоволен

Бывает: чините, чините, в lab data все 95+ баллов, а Search Console упрямо показывает «требует улучшения». Причины:

• Field data инертен. Метрика основана на реальных данных за 28 дней. После правок ждите минимум 2-3 недели, прежде чем оценивать.
• 75-й перцентиль. Если у вас старая мобильная аудитория с дешёвыми устройствами — даже на оптимизированном сайте 25 процентов будут видеть LCP больше 2,5 с просто из-за слабого процессора.
• Региональная разница. У пользователя из села с медленным мобильным интернетом LCP всегда будет хуже, чем в Москве на офисном Wi-Fi.
• Типы страниц. Search Console показывает агрегат по группам. Если у вас одна группа главных страниц с разной сложностью — даже одна тяжёлая может тянуть статистику вниз.

Что делать. В Search Console смотрите разбивку по группам URL. Найдите ту, что в красной зоне, гляньте конкретные страницы. Часто оказывается, что 2-3 шаблона из 10 виноваты во всей плохой статистике, и достаточно поправить именно их.

Реальный кейс: с 4,8 до 1,9 секунды за один день

Сайт автомастерской на WordPress, главная с тремя слайдами hero-баннера. PageSpeed мобильный показывал LCP 4,8 с, что красная зона.

Разбор. Hero весит 1,2 МБ JPG, шрифт через Google Fonts с CDN, lazy стоит на всех картинках включая первый слайд. Кэш страниц не настроен, OPcache на хостинге выключен.

Что сделали за день:

• Конвертировали все три баннера в WebP, получилось по 180-220 КБ.
• Перенесли шрифт на свой хостинг, добавили preload основного веса.
• Сняли lazy с первого слайда, поставили fetchpriority high.
• Включили WP Super Cache в простом режиме.
• Попросили хостера включить OPcache.

Результат через 30 минут после правок. Lab LCP 1,9 с. TTFB 280 мс (было 1100). Размер главной 940 КБ (было 2,8 МБ). Через две недели field data в Search Console подтянулся до 2,1 с по 75-му перцентилю — в зелёной зоне.

Итого: один день работы, без переверстки, без смены хостинга. Стоимость для клиента — 6 тысяч рублей по часовой ставке.

Когда без подрядчика не обойтись

Самостоятельно вы можете:

• Сжать картинки и поменять формат.
• Снять lazy с hero и добавить fetchpriority.
• Скачать шрифты с Google и положить себе.
• Включить кэш в админке CMS, если он есть штатно.
• Проверить PageSpeed после каждого шага.

Не справитесь сами:

• Перевод JS на defer/async, если на сайте куча самописных скриптов.
• Настройка OPcache, Redis, Memcached на хостинге.
• Оптимизация запросов к базе для тяжёлых страниц.
• Внедрение CDN с правильными правилами кеша.
• Переезд на новый стек.

Если первый список вас уже пугает — смело пишите через форму. Аудит LCP плюс реализация правок до зелёной зоны обычно занимает 1-2 дня и стоит 8-15 тысяч рублей в зависимости от сложности. Другие материалы по теме — в рубрике speed.

Частые вопросы

Что такое LCP простыми словами

Время, за которое посетитель видит главное на первом экране: большую картинку, заголовок или блок. Пока этот элемент не отрисован, страница ощущается пустой.

Как найти элемент, по которому считается LCP

В PageSpeed Insights и в инструментах разработчика он подсвечивается явно. Чаще всего это картинка в шапке, реже крупный заголовок или блок с фоном.

Что чинить в первую очередь

Картинку первого экрана: сжать, отдать в современном формате, убрать с неё отложенную загрузку и задать приоритет. Это самый быстрый выигрыш, часто в секунду и больше.

Почему LCP плохой при быстром сервере

Потому что сервер отдаёт HTML быстро, а дальше браузер ждёт шрифт и стили. Блокирующие ресурсы в шапке добавляют к LCP столько же, сколько тяжёлая картинка.