«Ускорьте сайт» - один из самых бесполезных советов, потому что непонятно, что именно ускорять. Можно неделю сжимать скрипты и не сдвинуть главную метрику ни на десятую долю секунды, если проблема была в одной картинке на первом экране. Largest Contentful Paint, или LCP, как раз показывает, где искать.
Коротко
Что разберём
- Какие значения LCP считаются хорошими
- Четыре части метрики и что исправлять в каждой
- Кейс: лендинг с нескольких мегабайт до 200 КБ
Чаще всего хватает трёх действий
- Убрать lazy-load с первого экрана
- Перевести тяжёлые картинки в WebP
- Включить кэш страниц
Содержание
Что такое LCP и почему он важен
LCP - время, за которое на экране появляется самый крупный элемент первого экрана: главная картинка, баннер, видео-обложка или большой блок текста. Для посетителя это момент, когда страница «загрузилась» и её можно читать.
LCP входит в Core Web Vitals - набор метрик Google, которые описывают качество загрузки и работы страницы:
| Метрика | Что измеряет | Хорошо |
|---|---|---|
| LCP | скорость загрузки основного контента | до 2.5 с |
| INP | отзывчивость на действия пользователя | до 200 мс |
| CLS | стабильность макета при загрузке | до 0.1 |
Промежуток между 2.5 и 4 секундами требует улучшения. Оценивается 75-й перцентиль загрузок: в порог должны уложиться не меньше трёх четвертей посещений. Мобильные устройства и компьютеры оцениваются отдельно, и на мобильных результат почти всегда хуже.
Как измерить LCP
PageSpeed Insights
Показывает полевые данные (реальные посетители Chrome за последние 28 дней, если трафика достаточно) и лабораторные (симуляция загрузки на медленном устройстве). Решения принимайте по полевым, диагностику ведите по лабораторным.
Chrome DevTools, вкладка Performance
Запишите загрузку страницы и найдите отметку LCP: браузер покажет, какой именно элемент стал крупнейшим.
Отчёт Core Web Vitals в Search Console
Группирует страницы сайта по статусу «хорошо», «требует улучшения», «плохо» по данным реальных пользователей.
Первым делом узнайте, какой элемент является LCP, иначе оптимизация идёт вслепую.
Из чего складывается LCP: четыре части
Google разбивает время LCP на четыре последовательные части. Это самый полезный инструмент диагностики: он показывает, на каком этапе теряется время.
Если LCP 4 секунды, а TTFB занимает 3 из них, сжатие картинок почти ничего не даст. Если же сервер отвечает за 300 миллисекунд, а картинка весит несколько мегабайт, проблема очевидна. Ниже - что исправлять в каждой части.
1Время ответа сервера
TTFB - фундамент: пока браузер не получил HTML, он ничего не знает о картинках и стилях.
Кэш страниц
WordPress без кэша на каждый запрос запускает PHP и обращается к базе данных. Кэш страниц отдаёт готовый HTML и сокращает TTFB в разы.
Расстояние до посетителя
Сервер в Европе для аудитории в Азии добавляет сотни миллисекунд на каждый запрос. CDN вроде Cloudflare отдаёт статику с ближайшего узла, а в некоторых конфигурациях кэширует и HTML. Как подключить домен к Cloudflare, мы разобрали в отдельной инструкции.
Ресурсы сервера
Если процессор и память постоянно загружены, сервер отвечает медленно. Проверьте нагрузку командами htop и free -h.
Цепочки редиректов
Каждый редирект, например http → https → www, - это ещё один полный запрос до начала загрузки страницы.
2Задержка загрузки: браузер поздно узнаёт о картинке
Самая недооценённая часть. Картинка может весить 50 килобайт, но начать загружаться через секунду после HTML. Типичные причины:
- Lazy-load на картинке первого экрана. Атрибут
loading="lazy"откладывает загрузку до момента, когда браузер убедится, что картинка видна. Для изображений ниже первого экрана это правильно, для LCP-картинки - вредно. - Картинка задана фоном в CSS. Браузер найдёт её только после загрузки и разбора файла стилей.
- Картинку вставляет JavaScript, например слайдер. Пока скрипт не загрузится и не выполнится, браузер о ней не знает.
Решение - дать браузеру узнать о LCP-картинке как можно раньше и загрузить её в приоритете:
<img src="/img/hero.webp" width="1200" height="630"
fetchpriority="high" alt="Описание картинки">Если картинка всё же задана фоном или подгружается скриптом, добавьте предзагрузку в <head>:
<link rel="preload" as="image" href="/img/hero.webp" fetchpriority="high">3Длительность загрузки: вес картинки
Здесь работает простое правило: чем меньше байт, тем быстрее загрузка, особенно на мобильном интернете.
Современные форматы
WebP обычно заметно легче PNG и JPEG при сопоставимом качестве, AVIF ещё легче. Оба поддерживаются всеми современными браузерами.
Размер под экран
Картинка шириной 4000 пикселей для блока шириной 800 - это лишние мегабайты. Используйте srcset, чтобы телефон получал уменьшенную версию.
Разумное качество
Для фотографий качество 75-85 в WebP визуально почти неотличимо от исходника.
Конвертировать можно одной командой, утилитой cwebp из пакета libwebp или ImageMagick:
# libwebp
cwebp -q 80 hero.png -o hero.webp
# ImageMagick
magick hero.png -quality 80 hero.webp4Задержка отрисовки: картинка загружена, но не показана
Если картинка давно загружена, а на экране её нет, браузер ждёт что-то ещё:
- Блокирующие CSS и JavaScript. Скрипты в
<head>без атрибутовdeferилиasyncостанавливают отрисовку страницы, пока не загрузятся и не выполнятся. - Веб-шрифты. Если LCP-элемент - текстовый блок, а шрифт грузится долго, текст может быть скрыт. Правило
font-display: swapпоказывает текст системным шрифтом до загрузки основного. - Тяжёлые сторонние скрипты. Чаты, виджеты и десяток счётчиков соревнуются за основной поток браузера. Подключайте их после загрузки основного контента.
LCP в WordPress
У сайтов на WordPress есть свои особенности, и часть работы движок уже делает сам. Современные версии WordPress пропускают атрибут loading="lazy" для изображений, которые, вероятно, окажутся на первом экране, и добавляют fetchpriority="high" картинке-кандидату в LCP.
Тема и плагины могут сломать это поведение: проверяйте итоговый HTML, а не настройки.
Кэш страниц обязателен
Без него TTFB на недорогом сервере легко съедает половину бюджета в 2.5 секунды. Кэширующий плагин или кэш на уровне веб-сервера отдаёт готовый HTML.
Слайдеры первого экрана
Плагины слайдеров часто грузят все изображения сразу и показывают первое только после выполнения JavaScript. Одна статичная картинка почти всегда быстрее.
Конструкторы страниц
Визуальные конструкторы добавляют десятки килобайт стилей и скриптов на каждую страницу. Для лендинга с жёстким требованием к скорости лёгкая тема или статичная страница выигрывают.
Картинки в медиатеке
WordPress создаёт несколько размеров при загрузке и подставляет srcset автоматически, но исходник всё равно стоит загружать разумного размера и в современном формате.
LCP, INP и CLS: как они связаны
Три метрики Core Web Vitals измеряют разные вещи, но исправления часто пересекаются:
- CLS ухудшается при неаккуратной оптимизации LCP. Картинка без размеров загружается быстрее, но сдвигает текст. Всегда задайте
widthиheightилиaspect-ratio. - INP страдает от тех же тяжёлых скриптов, которые задерживают отрисовку. Отложенная загрузка сторонних виджетов помогает обеим метрикам.
- Шрифты влияют и на LCP, и на CLS. Подмена системного шрифта основным может сдвинуть строки. Метрики шрифтов в
@font-faceсокращают этот сдвиг.
Поэтому после каждой оптимизации LCP проверяйте все три метрики, а не одну.
Кейс: лендинг весом 200 килобайт
Разберём на примере лендинга Kesyio, на котором мы сами проводили оптимизацию.
Что было. Скриншоты демо-сайтов в PNG и логотип в высоком разрешении: для одностраничного лендинга это несколько мегабайт картинок, которые мобильный посетитель скачивает при первом визите.
Что сделано. Скриншоты переведены в WebP, логотип сжат:
| Картинка | Было | Стало |
|---|---|---|
| Первый скриншот демо-сайта | 4.5 МБ, PNG | около 70 КБ, WebP |
| Второй скриншот демо-сайта | 1.5 МБ, PNG | около 60 КБ, WebP |
| Логотип | около 650 КБ | 4.5 КБ |
Логотип в шапке, который виден на первом экране, загружается без lazy-load и с fetchpriority="high". Атрибут loading="lazy" оставлен только для картинок ниже первого экрана.
Что получилось. Вся страница весит около 204 КБ. Для сравнения с сервисами той же тематики: одна популярная страница весит 126 КБ, другая - около 890 КБ. Картинки перестали быть узким местом, и дальнейшие улучшения LCP упираются уже во время ответа сервера, а не в вес ресурсов.
Самые большие выигрыши дают не тонкие настройки, а два-три грубых исправления. Одна картинка на 4.5 мегабайта перевешивает любые оптимизации скриптов.
Частые ошибки
Атрибут стоит на всех картинках подряд, включая первый экран.
Lazy-load только ниже первого экрана
Или видео вместо одной оптимизированной картинки.
Одна статичная картинка
LCP от этого не страдает, но макет прыгает при загрузке и портит CLS.
Укажите width и height или aspect-ratio
Вместо двух, а каждое начертание - отдельный файл.
Два начертания
Симуляция медленного телефона не всегда совпадает с реальными посетителями.
Проверяйте полевые данные
Порядок работ
Отмечайте пункты, отметки сохранятся в этом браузере.
Как это устроено в Kesyio
Готовый HTML на вашем сервере
Сайты в Kesyio разворачиваются на вашем собственном сервере, а домены подключаются через Cloudflare, который отдаёт статику с ближайшего к посетителю узла.
Корпоративные сайты в Kesyio статичные: сервер отдаёт готовые HTML-файлы без запуска PHP и обращений к базе данных, поэтому время ответа сервера у них определяется в основном сетью.
Для сайтов на WordPress стоит подключить кэш страниц, об этом - в инструкции как развернуть WordPress на своём сервере.
Вопросы и ответы
Какой LCP считается хорошим?
До 2.5 секунды для 75% посещений. От 2.5 до 4 секунд - требует улучшения, больше 4 секунд - плохо. Мобильные и десктопные посещения оцениваются отдельно.
Влияет ли LCP на позиции в поиске?
Core Web Vitals входят в сигналы оценки удобства страницы, но содержание и соответствие запросу важнее. Быстрая страница с нерелевантным текстом не обойдёт медленную с хорошим ответом. На конверсию и стоимость рекламного клика скорость при этом влияет напрямую.
Почему PageSpeed Insights показывает разные результаты при каждом запуске?
Лабораторный замер зависит от нагрузки на сервер и сеть в момент проверки. Сравните несколько запусков и опирайтесь на полевые данные, которые усредняют реальные посещения за 28 дней.
Нужно ли переходить на AVIF, если уже есть WebP?
Не обязательно. Переход с PNG или JPEG на WebP даёт основной выигрыш. AVIF экономит ещё часть байт, но медленнее кодируется. Имеет смысл для крупных изображений первого экрана.
Помогает ли CDN, если сервер уже быстрый?
Да, если посетители далеко от сервера. CDN сокращает сетевую задержку для статики, а при кэшировании HTML - и для самой страницы.
Итог
- LCP складывается из четырёх частей: ответа сервера, задержки загрузки картинки, самой загрузки и отрисовки.
- Найдите LCP-элемент, посмотрите, какая часть занимает больше всего времени, и исправляйте именно её.
- В большинстве случаев хватает трёх действий: убрать lazy-load с первого экрана, перевести тяжёлые картинки в WebP и включить кэш страниц.
