Глоссарий
LCP
Largest Contentful Paint — время появления крупнейшего подходящего элемента содержимого в видимой области. Это часть оценки загрузки, а не время полной готовности всех функций страницы.
Материал обновлён 21 октября 2026
01
Что такое 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.
02
Что считается LCP-элементом
LCP-кандидатом может быть изображение img, image внутри SVG, постер или первый отображённый кадр видео, 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-шрифт на системный для первого экрана.
03
Пороговые значения
Хорошая оценка LCP — не более 2,5 секунды, промежуточная — более 2,5 и не более 4 секунд, плохая — более 4 секунд. Смотрят 75-й перцентиль загрузок, отдельно для мобильных и настольных устройств; это доля загрузок, а не доля URL сайта.
| Оценка | LCP | Что это значит для бизнеса |
|---|---|---|
| Хорошо | ≤ 2,5 с | Пользователь быстро видит суть страницы, ниже риск отказа на первом экране |
| Нужно улучшить | 2,5–4,0 с | Задержка заметна на мобильных, возможна потеря части органического и рекламного трафика |
| Плохо | > 4,0 с | Высокие отказы, негативный сигнал для Core Web Vitals и UX |
LCP коррелирует с другими метриками, но улучшение LCP не всегда автоматически улучшает INP или CLS. Страница может быстро показать картинку, но «зависнуть» при клике из-за JavaScript — поэтому смотрите весь набор Core Web Vitals, а не только LCP.
Сопоставляйте LCP и обращения по одинаковым типам страниц и устройствам. Не делайте вывод о потерянных заявках из одного порога: состав аудитории, качество предложения и сезон могут меняться одновременно со скоростью.
04
Причины медленного 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.
05
Как улучшить 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 сразу после деплоя.
06
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 по доступности — скорость страницы это часть продукта, а не только задача разработки.
Применение
Примеры и способы проверки
Условные ситуации и расчёты; это не результаты клиентского проекта.
| Ситуация | Условие | Вывод или проверка |
|---|---|---|
| LCP — изображение | Ресурс начинается загружаться поздно | Проверить способ подключения и приоритет |
| LCP — текст | Задержка связана с отображением | Проверить блокирующие ресурсы и шрифты |
Следующий шаг
