Глоссарий

LCP

LCP (Largest Contentful Paint) — метрика Core Web Vitals, которая показывает, через сколько секунд после начала загрузки страницы пользователь видит её главный содержательный элемент. Это не абстрактный «полный load», а момент, когда на экране появляется то, ради чего человек пришёл: крупное изображение, заголовок, видеопревью или текстовый блок. Для бизнеса LCP — один из первых факторов доверия: медленное появление контента воспринимается как «сайт не работает» и увеличивает отказы. LCP входит в набор Core Web Vitals вместе с INP и CLS; подробнее о метриках и порогах — в глоссарии CTR Agency.

Что такое LCP

Largest Contentful Paint измеряет время от момента перехода пользователя на URL до отрисовки самого крупного видимого элемента контента в области просмотра (viewport). Браузер фиксирует несколько кандидатов по мере загрузки и выбирает наибольший по площади видимой части. Когда элемент полностью отрисован (для изображений — когда загружены пиксели, для текста — когда отрисован шрифт), фиксируется финальное значение LCP.

LCP отвечает на вопрос «когда пользователь понял, что страница загружается и несёт пользу?». В отличие от метрики First Contentful Paint (FCP), которая может сработать на мелком логотипе или спиннере, LCP привязан к существенному контенту. Имен поэтому Google включил LCP в Core Web Vitals как показатель воспринимаемой скорости.

Пороговые значения для LCP: до 2,5 секунды — хорошо, 2,5–4 секунды — требует улучшения, более 4 секунд — плохо. Оценка идёт по 75-му перцентилю field data за 28 дней. На мобильных устройствах и медленных сетях LCP чаще «проседает», поэтому оптимизацию нужно проверять именно на типичной аудитории, а не только на офисном Wi‑Fi.

Что считается LCP-элементом

Кандидатами на роль LCP-элемента могут быть следующие типы контента в viewport: элемент <img> (включая внутри <svg>), <image> внутри SVG, видео с poster, блок с фоновым изображением через CSS url(), или текстовый узел в блочном элементе (заголовок, абзац). Элементы за пределами видимой области, а также изображения с нулевой непрозрачностью или размером, не учитываются.

На типовой посадочной LCP-элементом часто становится hero-изображение или крупный H1 с подзаголовком. В интернет-магазине на карточке товара — главное фото. В статье блога — обложка или первый крупный абзац. Если above-the-fold занят слайдером, LCP может «перепрыгивать» между слайдами по мере смены — это усложняет оптимизацию и аргумент в пользу статичного hero вместо тяжёлого карусельного блока.

Чтобы узнать LCP-элемент на конкретной странице, используйте PageSpeed Insights (раздел «Диагностика»), Lighthouse или Chrome DevTools → Performance → Timings → LCP. Зная элемент, можно точечно сжать изображение, убрать lazy load с above-the-fold, вынести критический CSS или заменить web-шрифт на системный для первого экрана.

Пороговые значения

Google привязывает LCP к трём зонам качества. Для отчётов Search Console и CrUX используется распределение по визитам: доля URL в зелёной зоне должна быть не менее 75%.

LCP коррелирует с другими метриками, но улучшение LCP не всегда автоматически улучшает INP или CLS. Страница может быстро показать картинку, но «зависнуть» при клике из-за JavaScript — поэтому смотрите весь набор Core Web Vitals, а не только LCP.

Для e-commerce и лидогенерации полезно сопоставлять LCP по URL с конверсией в аналитике. Часто категории и карточки с LCP > 3 с на мобильных теряют больше заявок, чем «красивая», но медленная главная.

Причины медленного LCP

Медленный LCP почти всегда имеет несколько совместных причин. Медленный ответ сервера (TTFB) — пользователь ждёт HTML: слабый хостинг, отсутствие кеша, тяжёлые запросы к базе, географическая удалённость сервера от аудитории. Блокирующие ресурсы в head — CSS и JS без defer/async задерживают первую отрисовку.

Тяжёлый LCP-ресурс — неоптимизированное изображение, отсутствие современных форматов (WebP, AVIF), загрузка полноразмерного файла для маленького блока на экране. Lazy loading на первом экране — распространённая ошибка: атрибут loading=»lazy» на hero-картинке откладывает LCP.

Клиентский рендеринг — если основной контент появляется только после выполнения большого JS-бандла (типично для некоторых SPA и конструкторов), LCP сдвигается на секунды. Web-шрифты без оптимизации блокируют отрисовку текста; FOIT/FOUT увеличивают LCP для текстовых hero-блоков. Сторонние скрипты — A/B-тесты, персонализация, теги рекламы — конкурируют за bandwidth и main thread.

Как улучшить LCP

Оптимизация LCP начинается с идентификации LCP-элемента и измерения TTFB. Если сервер отвечает дольше 600–800 мс, сначала настраивают кеширование (страницы, объектный кеш, CDN), оптимизируют БД и рассматривают более быстрый тариф хостинга. Параллельно сокращают цепочку редиректов и включают HTTP/2 или HTTP/3.

Для изображений-LCP: сжатие без потери качества для hero, responsive srcset и sizes, форматы WebP/AVIF с fallback, явные width и height для предотвращения CLS, preload для критического изображения через <link rel="preload" as="image">. Не используйте lazy load на above-the-fold.

Для текстового LCP: inline критический CSS, font-display: swap или optional, подмножества шрифтов, ограничение количества начертаний. Для JS: defer некритичных скриптов, code splitting, удаление неиспользуемого кода, отложенная загрузка виджетов чата и аналитики после LCP. После правок проверяйте field data в Search Console через 28 дней и lab data в Lighthouse сразу после деплоя.

LCP и хостинг

Хостинг напрямую влияет на TTFB и стабильность LCP под нагрузкой. На shared-хостинге с перегруженным соседством сайт может «плавать» по скорости: в lab-тесте всё хорошо, в пиковые часы CrUX ухудшается. Для коммерческих проектов с трафиком из SEO и рекламы разумны VPS, managed WordPress или облако с autoscaling, CDN у пользователя и кеш на edge.

География сервера и CDN важна для региональной аудитории: если клиенты в Москве, а origin в США без CDN, TTFB и LCP растут. SSL, сжатие Brotli/Gzip, keep-alive и правильные cache-control для статики снижают время до LCP. На WordPress и CMS часто помогают object cache (Redis), плагины полностраничного кеша и оптимизация тяжёлых плагинов.

Хостинг не заменит оптимизацию фронтенда: быстрый сервер с четырёхмегабайтным hero всё равно даст плохой LCP. Но без адекватной инфраструктуры даже идеальный код упрётся в потолок. При выборе тарифа закладывайте мониторинг LCP и SLA по доступности — скорость страницы это часть продукта, а не только задача разработки.