Вы открываете свой сайт, и первые мгновения экран пустой. Потом проступает шапка, потом текст, и только через пару секунд догружается большая картинка вверху страницы. Вот это ощущение «ну когда же уже» поисковики научились измерять цифрой. Цифра называется LCP.
LCP (Largest Contentful Paint, в переводе «отрисовка крупнейшего видимого элемента») показывает, за сколько секунд на экране появляется самый большой блок контента: hero-картинка (главное изображение первого экрана), крупный заголовок или видео-превью. Google считает хорошим результат до 2,5 секунды. Всё, что дольше, тянет вниз и позиции в выдаче, и желание посетителя остаться.
В этой статье разберём LCP по косточкам: из каких частей он складывается, как найти на своей странице тот самый «крупнейший элемент», который тормозит загрузку, и что конкретно чинить под каждую причину. Будет таблица «причина → решение», пошаговый разбор в Chrome DevTools (встроенные инструменты разработчика в браузере), чек-лист на вечер и отдельный блок про WordPress и Тильду.
LCP — одна из трёх ключевых метрик Core Web Vitals (набор показателей скорости и удобства от Google). Что такое сами Core Web Vitals, как их измерять и с чего вообще начинать ускорение сайта, мы подробно разобрали в обзорной статье про Core Web Vitals. Здесь не будем повторять основы, сосредоточимся только на LCP.
Если же медленный LCP — лишь часть общей задачи «привести сайт в порядок», держите рядом наш разбор технического аудита сайта: скорость там идёт в связке с битыми ссылками, индексацией и микроразметкой.
Статья пригодится не только разработчикам. Если у вас сайт на WordPress или Тильде и PageSpeed показывает красное, базовые вещи вы почините сами по этому материалу. А если хотите разобраться в вёрстке и оптимизации всерьёз — загляните в подборку курсов по frontend-разработке: там собраны программы, где скорость сайта разбирают руками на реальных проектах.
КурсыСравнение 84 курсов по frontend-разработкеЦены, школы, длительность, рассрочка
Что такое LCP простыми словами
Представьте секундомер, который запускается в момент, когда человек кликнул по ссылке на ваш сайт. Браузер начинает загружать страницу: сначала приходит код, потом стили, картинки, шрифты. Секундомер останавливается ровно тогда, когда на видимой части экрана отрисовался самый крупный элемент. Время на табло — это и есть LCP.
Видимая часть экрана называется первым экраном или вьюпортом (viewport) — то, что человек видит без прокрутки. LCP смотрит только на неё. Если у вас огромная картинка в подвале сайта, на метрику она не влияет: пользователь до неё ещё не доскроллил.
Крупнейшим элементом браузер может посчитать:
- большое изображение (чаще всего именно hero-картинка вверху);
- фоновое изображение блока, заданное через CSS;
- видео с картинкой-обложкой (poster);
- крупный блок текста — заголовок или первый абзац, если картинок на первом экране нет.
Чаще всего виновата именно картинка. Поэтому большая часть работы над LCP — это работа с главным изображением страницы. Но не всегда: на текстовых страницах (статья в блоге, карточка услуги без фото) крупнейшим элементом окажется заголовок, и тогда тормозить будут шрифты или стили.
Запомните главное. LCP засекает один момент: когда на первом экране появился самый заметный кусок контента. Полная загрузка страницы и последняя иконка в футере на метрику не влияют. Оптимизировать нужно путь именно до этого одного элемента.
Какой LCP считается хорошим
Чтобы понять, нужно ли вообще улучшать показатель LCP, сверьтесь с порогами Google. Они одинаковые с 2021 года, когда метрика стала фактором ранжирования:
| Значение LCP | Оценка | Что делать |
|---|---|---|
| до 2,5 сек | Хорошо (good) | Можно оставить как есть |
| 2,5–4 сек | Требует улучшения | Уже теряете позиции, пора чинить |
| больше 4 сек | Плохо (poor) | Срочно, это бьёт и по SEO, и по конверсии |
Важный нюанс: порог 2,5 секунды считается по 75-му процентилю реальных визитов. Простыми словами — у трёх из четырёх посетителей страница должна укладываться в 2,5 секунды. Поэтому нельзя один раз открыть сайт у себя на быстром интернете, увидеть «1,2 сек» и успокоиться: у человека с дешёвым телефоном и мобильным интернетом цифра будет совсем другой.
Тут всплывает разница между двумя типами данных, на которой многие спотыкаются:
- Лабораторные данные (lab) — тест в стерильных условиях, как в Lighthouse или при разовой проверке PageSpeed. Удобно для отладки: меняешь что-то и сразу видишь результат.
- Полевые данные (field) — то, что получают живые посетители с разных устройств и сетей. Их собирает Google в отчёте CrUX (Chrome User Experience Report), и именно по ним поисковик оценивает сайт.
Бывает, что в лаборатории LCP красивый, а в поле — красный. Причина обычно в мобильных пользователях со слабым интернетом. LCP на телефоне почти всегда хуже десктопного: слабее процессор, медленнее сеть, картинки те же. Поэтому ориентируйтесь в первую очередь на мобильные полевые данные — они и для Google главные.
Из чего складывается LCP — четыре части
Большинство статей советуют «сожмите картинки и поставьте кеш» и на этом останавливаются. Но без понимания, из чего состоит LCP, вы будете чинить наугад. Google разложил метрику на четыре последовательных отрезка, и сумма всех четырёх — это полное время LCP.
| Часть LCP | Что это | Типичная доля | Что чинит |
|---|---|---|---|
| 1. TTFB | Время до первого байта — пока сервер думает и отдаёт первый кусок ответа | ~40 % | Хостинг, кеш, CDN, бэкенд |
| 2. Задержка до загрузки ресурса | Пауза между ответом сервера и началом скачивания hero-картинки | до 10 % | preload, fetchpriority, отказ от загрузки картинки скриптом |
| 3. Загрузка ресурса | Сколько качается сам файл картинки или шрифта | ~40 % | Сжатие, webp/avif, размеры, CDN |
| 4. Задержка рендера | Пауза между «файл скачан» и «элемент нарисован на экране» | до 10 % | Критический CSS, отказ от блокирующего JS |
Логика простая: вода течёт по трубе, и узким местом может оказаться любой отрезок. Можно идеально сжать картинку (часть 3), но если сервер отвечает две секунды (часть 1), LCP всё равно будет плохим. Поэтому сначала смотрят, какой отрезок самый длинный, и чинят именно его, а не всё подряд.
Разберём на цифрах. Допустим, PageSpeed показал LCP 4,2 секунды и такую разбивку: TTFB — 1,8 сек, задержка до загрузки — 0,2 сек, загрузка hero-картинки — 2,0 сек, задержка рендера — 0,2 сек. Видно сразу: два толстых отрезка — сервер и картинка. Сжатие изображения с 2 МБ до 300 КБ срежет третью часть примерно до 0,6 секунды, а кеширование уронит TTFB до 0,4. Итог — около 1,4 секунды вместо 4,2. А вот если бы вы в этой ситуации полезли возиться со шрифтами и критическим CSS, то потратили бы вечер и сдвинули LCP на жалкие 0,1 секунды, потому что эти отрезки и так короткие.
Чините самый длинный отрезок. 80 % результата дают одна-две правки по самой толстой части LCP. Остальные пять оптимизаций имеют смысл, только когда главные узкие места уже расшиты.
Первая часть, TTFB, заслуживает отдельного разговора: это про скорость самого сервера, хостинг и кеширование. Если PageSpeed подсвечивает у вас именно «сократите время ответа сервера», читайте отдельный материал про то, как уменьшить TTFB: там разобраны хостинг, Redis, OPcache и нюансы WordPress. Здесь же сосредоточимся на частях со второй по четвёртую — это фронтовая работа, и её результат виден быстрее всего.
Как найти LCP-элемент на своей странице
Прежде чем что-то оптимизировать, нужно понять, какой именно элемент браузер считает крупнейшим. Чинить вслепую — значит сжимать картинку из подвала, пока тормозит заголовок вверху. Есть два рабочих способа.
Способ 1 — PageSpeed Insights
Откройте PageSpeed Insights (бесплатный сервис Google), вставьте адрес страницы и запустите проверку. В блоке диагностики найдите пункт «Largest Contentful Paint element» — Google прямо покажет, какой элемент он засёк, с его кодом и картинкой-превью. Это самый быстрый способ для тех, кто не хочет лезть в инструменты разработчика.
Заодно посмотрите там же разбивку LCP на те самые четыре части — PageSpeed показывает, сколько процентов времени съел каждый отрезок. Это сразу подсказывает, куда копать.
Способ 2 — Chrome DevTools
Способ для тех, кто хочет видеть всё своими глазами. DevTools — встроенные в браузер инструменты разработчика, открываются клавишей F12 или сочетанием Ctrl+Shift+I (на Mac — Cmd+Option+I).
- Откройте свою страницу в Chrome, нажмите F12.
- Перейдите на вкладку Performance (Производительность).
- Нажмите кнопку перезагрузки со стрелкой внутри панели — она запишет весь процесс загрузки.
- В получившейся ленте найдите блок Timings и маркер LCP. Кликните по нему.
- Внизу в деталях будет строка «Related Node» — наведите на неё, и нужный элемент подсветится прямо на странице.
В свежих версиях Chrome в панели Performance есть ещё раздел Insights, где LCP уже разложен на четыре части с миллисекундами — не нужно считать самому. Это удобнее любого онлайн-сервиса, потому что вы тестируете на своём устройстве и видите живую картину.
Для тех, кто пишет код, есть и третий путь — библиотека web-vitals от Google. Она через JavaScript-интерфейс PerformanceObserver отдаёт значение LCP и его элемент прямо в коде, чтобы собирать метрику с реальных пользователей. Но для большинства задач хватает первых двух способов.
Сначала диагностика, потом лечение. Потратьте пять минут на PageSpeed или DevTools и узнайте свой LCP-элемент и самую длинную из четырёх частей. Это сэкономит часы бессмысленной оптимизации того, что и так быстрое.
Почему LCP плохой — причины и решения
Теперь к сути. Ниже — сводная таблица типичных причин плохого LCP и того, чем их лечить. Под таблицей разберём каждую причину подробнее.
| Причина | Какая часть LCP страдает | Решение |
|---|---|---|
| Медленный сервер или хостинг | TTFB | Кеш, CDN, нормальный хостинг |
| Тяжёлая hero-картинка | Загрузка ресурса | webp/avif, сжатие, правильные размеры |
| Lazy-load на главной картинке | Задержка до загрузки | Убрать lazy с hero-элемента |
| Блокирующие CSS и JS | Задержка рендера | Критический CSS, defer для скриптов |
| Медленные шрифты | Загрузка и рендер | font-display, preload шрифта |
| Картинку поздно «нашли» | Задержка до загрузки | preload + fetchpriority |
Медленный сервер
Если самой длинной частью оказался TTFB, никакая работа с картинками не поможет — браузер просто ждёт ответа сервера. Лечится кешированием страниц, подключением CDN (сеть серверов по миру, которая отдаёт контент с ближайшего к пользователю узла) и переездом на хостинг побыстрее. Что такое CDN и как он сокращает путь до пользователя, мы разобрали в статье про сети доставки контента. Глубокий разбор серверной части — в материале про TTFB, ссылка была выше.
Тяжёлая hero-картинка
Самая частая причина. Дизайнер отдал картинку шириной 4000 пикселей и весом 3 мегабайта, её залили как есть, и теперь браузер качает эти мегабайты на каждом заходе. Что делать:
- Перевести в современный формат. Форматы webp и avif сжимают картинку в 3–7 раз без видимой потери качества. Один и тот же кадр в PNG может весить 2,3 МБ, а в webp — 300 КБ.
- Отдавать правильный размер. Если картинка на экране занимает 800 пикселей, незачем грузить файл на 4000. Используйте атрибут
srcset, чтобы телефон получал маленькую версию, а десктоп — большую. - Сжимать. Прогоните изображение через сжатие — на глаз разницы не видно, зато вес падает ещё на четверть.
Lazy-load на главной картинке — частая ошибка
Lazy loading (отложенная, или ленивая, загрузка) — приём, при котором картинки подгружаются по мере прокрутки: пока пользователь до них не доскроллил, браузер их не трогает. Для изображений внизу страницы это правильно и полезно. Но многие плагины и темы по умолчанию вешают lazy-load на все картинки, включая hero на первом экране.
Получается абсурд: главный элемент, по которому считается LCP, браузер откладывает «на потом». Он добавляет лишнюю задержку перед загрузкой ровно той картинки, которую нужно показать первой. Google формулирует это жёстко: никогда не ставьте loading="lazy" на LCP-изображение.
Проверьте код своей hero-картинки. Если там есть loading="lazy" — уберите его именно у неё. В WordPress это часто делается настройкой плагина оптимизации (исключить первый экран из lazy-load) или галочкой «exclude above-the-fold».
Блокирующие CSS и JS
Render-blocking (блокирующие отрисовку) ресурсы — это стили и скрипты, которые браузер обязан загрузить и обработать, прежде чем он вообще начнёт что-то рисовать. Пока в <head> висит тяжёлый файл стилей или синхронный скрипт, экран остаётся белым, и LCP растёт.
Что помогает:
- Критический CSS. Это небольшой кусок стилей, который нужен только для отрисовки первого экрана. Его встраивают прямо в HTML, а основной файл стилей подгружают следом. Браузер рисует первый экран сразу, не дожидаясь всего CSS. Что такое CSS и как он устроен — в нашем разборе языка стилей CSS.
- Атрибут
deferдля скриптов. Он говорит браузеру: «загрузи этот JavaScript в фоне и выполни, когда страница построится». Скрипт перестаёт блокировать отрисовку. - Убрать лишнее. Сторонние виджеты, чаты, счётчики, баннеры — каждый тянет свой скрипт. Что не нужно на первом экране, грузите позже или удаляйте.
Медленные шрифты
Если LCP-элемент — текст (крупный заголовок), то узким местом становится шрифт. Браузер скачивает файл шрифта, и пока он этого не сделал, текст либо не виден (FOIT — вспышка невидимого текста), либо мелькает системным шрифтом (FOUT). Оба варианта Google засчитывает как задержку.
- Свойство
font-display: swapразрешает браузеру сразу показать текст системным шрифтом и заменить его на ваш, когда тот догрузится. Текст виден мгновенно. - preload шрифта. Тег
<link rel="preload">для файла шрифта говорит браузеру скачать его раньше остального — полезно, если шрифт нужен для LCP-заголовка. - Не подключайте десять начертаний, если используете два. Каждый файл — это лишние килобайты.
Картинку поздно «нашли»
Браузер ищет ресурсы для загрузки, сканируя HTML сверху вниз. Если hero-картинка спрятана глубоко (например, подгружается скриптом или задана фоном в CSS), браузер находит её поздно и начинает качать с опозданием. Это и есть задержка до загрузки ресурса, часть 2 из таблицы выше. Два инструмента:
- preload (предзагрузка). Тег
<link rel="preload" as="image">в<head>заранее сообщает браузеру: «вот эта картинка важная, начинай качать сразу». Особенно нужно для фоновых изображений из CSS, которые иначе обнаруживаются поздно. - fetchpriority (приоритет загрузки). Атрибут
fetchpriority="high"на теге картинки поднимает её в очереди загрузки выше остальных. А второстепенным ресурсам можно поставитьfetchpriority="low", чтобы они не отнимали канал у главной картинки.
На практике связка простая: на hero-изображение ставим fetchpriority="high" и убираем с него loading="lazy". Вот как выглядит правильный тег главной картинки:
<img src="hero.webp" width="1200" height="600"
alt="Главный экран"
fetchpriority="high">Обратите внимание: тут нет loading="lazy", зато есть fetchpriority="high" и заданы width и height — размеры заодно помогают с другой метрикой, сдвигом макета. А если hero задан фоном через CSS и браузер находит его поздно, добавьте в <head> предзагрузку:
<link rel="preload" as="image"
href="hero.webp"
fetchpriority="high">Двух-трёх таких правок часто хватает, чтобы сбросить LCP на полсекунды без всякого переписывания сайта.
Чек-лист «улучшаем LCP за вечер»
Если хочется результата без чтения всей теории, идите по порядку. Каждый шаг проверяйте повторным запуском PageSpeed.
Шаг 1 — узнайте свой LCP-элемент и узкую часть. PageSpeed Insights покажет и сам элемент, и какая из четырёх частей съедает больше всего времени. Без этого шага дальше идти бессмысленно.
Шаг 2 — снимите lazy-load с hero. Самая дешёвая победа. Найдите главную картинку первого экрана, уберите у неё loading="lazy", добавьте fetchpriority="high".
Шаг 3 — облегчите главную картинку. Переведите в webp или avif, отдавайте размер под экран, сожмите. Цель — уложить hero в 200–400 КБ.
Шаг 4 — разберитесь с сервером. Если самой длинной частью оказался TTFB, включите кеширование страниц и подключите CDN. На большинстве сайтов это даёт самый заметный прирост.
Шаг 5 — уберите блокирующие ресурсы. Настройте критический CSS, повесьте defer на тяжёлые скрипты, выкиньте виджеты, без которых первый экран живёт.
Шаг 6 — почините шрифты. Добавьте font-display: swap, сделайте preload шрифта для заголовка, уберите лишние начертания.
Шаг 7 — перепроверьте по полевым данным. Лабораторный тест покажет результат сразу, а вот полевые данные CrUX обновляются неделями. Через две-три недели после правок загляните в Search Console и убедитесь, что у живых пользователей LCP тоже позеленел.
Три ошибки, из-за которых LCP не двигается
Часто человек делает вроде бы всё по списку, а цифра стоит на месте. Обычно причина в одной из трёх вещей.
Чинят не тот элемент. Сжали все картинки на странице, кроме той единственной, которую браузер считает LCP-элементом. Или вообще LCP — это заголовок, а человек воюет с изображениями. Отсюда правило: сначала найти элемент через PageSpeed или DevTools, потом чинить.
Смотрят на лабораторные данные вместо полевых. После правок лабораторный тест сразу показывает зелёный, человек радуется. Но Google ранжирует по полевым данным CrUX, а они обновляются неделями. Данные в Search Console подтянутся не сразу, это нормально, откатывать правки в панике не нужно.
Гонятся за идеальной единицей. LCP 1,8 секунды — это уже зелёная зона, вылизывать её до 0,9 ради красоты смысла мало. Силы лучше пустить на другие страницы, где LCP всё ещё в красном. Цель — увести из красной зоны весь сайт, а не выбить рекорд на одной странице.
LCP на WordPress и Тильде
Большинство сайтов в рунете живут на готовых платформах, поэтому разберём два самых частых случая отдельно — тут многое чинится без программиста.
WordPress
На WordPress почти всё решается плагинами оптимизации (FlyingPress, WP Rocket, LiteSpeed Cache и похожие). Что включить:
- кеширование страниц — чтобы сервер не собирал страницу заново на каждый заход (бьёт по TTFB);
- исключение первого экрана из lazy-load — ищите настройку «exclude above-the-fold images» или поле для исключений, куда вписывают hero-картинку;
- автоматическую конвертацию в webp — большинство плагинов умеют отдавать webp вместо тяжёлых JPEG и PNG;
- генерацию критического CSS и отложенную загрузку остального;
- preload для главного изображения — в продвинутых плагинах это отдельная галочка.
Отдельная боль WordPress — медленный бэкенд из-за тяжёлых тем и десятков плагинов. Если TTFB не лечится кешем, посмотрите через плагин Query Monitor, какие запросы к базе тормозят. Заодно полезно прогнать сайт через технический аудит — он вскрывает и проблемы со скоростью, и сопутствующие ошибки.
КурсыСравнение 21 курса по WordPressЦены, школы, длительность, рассрочка
Тильда
С Тильдой сложнее: это закрытый конструктор, и доступа к коду почти нет. Что в ваших руках:
- не грузите в hero-блок гигантские картинки — сжимайте их до загрузки на сайт, Тильда не всегда оптимизирует за вас;
- отдавайте картинки в webp, если позволяет блок;
- не ставьте на первый экран тяжёлые анимации, видео-фоны и слайдеры с десятком изображений — каждый элемент удлиняет загрузку;
- уберите лишние сторонние скрипты из настроек проекта.
На конструкторах потолок оптимизации ниже, чем на своём коде, но базовые вещи — лёгкая hero-картинка и чистый первый экран — вытягивают LCP в зелёную зону и на Тильде.
Где научиться фронтенду и оптимизации
Разовые правки по чек-листу выше дадут результат уже сегодня. Но чтобы понимать, как браузер строит страницу и почему она тормозит, нужна система. Скорость сайта — это часть работы фронтенд-разработчика, и на нормальных курсах её разбирают вместе с вёрсткой, JavaScript и инструментами сборки.
Мы собрали подборку курсов по frontend-разработке — от коротких интенсивов по вёрстке до годовых программ с трудоустройством. У каждого есть рейтинг, отзывы и цена, чтобы выбрать под свой уровень и бюджет.
| Курс | Школа | Стоимость со скидкой | В рассрочку | Длительность | Обзор курса от Checkroi |
|---|---|---|---|---|---|
| Веб-вёрстка Перейти на сайт курса |  Skillbox | 145 881 ₽ | 2818 ₽/мес. | 3 месяца | Обзор курса |
| Frontend-разработчик с нуля Перейти на сайт курса |  Нетология | 120 700 ₽ | 5385 ₽/мес. | 10 месяцев | Обзор курса |
| Frontend-разработчик Мастер Перейти на сайт курса |  GeekBrains | 264 780 ₽ | 7355 ₽/мес. | 24 месяца | Обзор курса |
| Профессия «Frontend-разработчик с нуля до PRO» Перейти на сайт курса | Skillbox | 137 500 ₽ | 4911 ₽/мес. | 10 месяцев | Обзор курса |
| Профессия: Frontend-разработчик Перейти на сайт курса |  ProductStar | 89 088 ₽ | 36 ₽/мес. | 8 месяцев | Обзор курса |
| Онлайн-курс Frontend-разработчик Перейти на сайт курса |  Бруноям | 63 900 ₽ | 5325 ₽/мес. | 8 месяцев | Обзор курса |
| Факультет frontend-разработки Перейти на сайт курса | GeekBrains | 179 600 ₽ | 4989 ₽/мес. | 12 месяцев | Обзор курса |
| Фронтенд-разработчик Перейти на сайт курса |  Синергия | 97 356 ₽ | 4057 ₽/мес. | 6 месяцев | Обзор курса |
| Мидл фронтенд-разработчик Перейти на сайт курса |  Практикум | 116 000 ₽ | 18 500 ₽/мес. | 5 месяцев | Обзор курса |
| Интенсив: фронтенд-разработка с ИИ Перейти на сайт курса |  Компьютерная академия TOP | Бесплатно | 4560 ₽/мес. | 3 месяца | Обзор курса |
Больше программ — в полном каталоге курсов по Frontend-разработке
Если пока не готовы вкладываться в обучение, начните с малого: прогоните сайт через PageSpeed, найдите LCP-элемент и снимите с него lazy-load. Дальше — по чек-листу. А общую картину по скорости и остальным метрикам всегда можно освежить в статье про Core Web Vitals.
![Обложка: Что такое E E A T и как улучшить эти факторы в [current year]](https://selcdn.checkroi.ru/wp-content/uploads/og-images/og-cover-77886-1781094522.webp "Статья: Что такое E-E-A-T и как улучшить эти факторы в 2026")
![Обложка: Как убрать сдвиг макета и улучшить CLS (Cumulative Layout Shift) в [current year]](https://selcdn.checkroi.ru/wp-content/uploads/og-images/og-cover-77891-1781094498.webp "Статья: Как убрать сдвиг макета и улучшить CLS (Cumulative Layout Shift) в 2026")
![Обложка: Как улучшить INP (Interaction to Next Paint) в [current year]](https://selcdn.checkroi.ru/wp-content/uploads/og-images/og-cover-77885-1781094486.webp "Статья: Как улучшить INP (Interaction to Next Paint) в 2026")
![Обложка: Как уменьшить TTFB (время до первого байта) в [current year]](https://selcdn.checkroi.ru/wp-content/uploads/og-images/og-cover-77892-1781094414.webp "Статья: Как уменьшить TTFB (время до первого байта) в 2026")
![Обложка: Как ускорить сайт и улучшить Core Web Vitals в [current year]](https://selcdn.checkroi.ru/wp-content/uploads/og-images/og-cover-77863-1781090788.webp "Статья: Как ускорить сайт и улучшить Core Web Vitals в 2026")
