LCP может оставаться высоким даже при быстром ответе сервера. Если TTFB уже небольшой, ищите потерю времени после получения HTML: браузер поздно обнаруживает главный элемент, долго загружает его ресурс или не может отрисовать его из-за CSS и JavaScript.
Не начинайте с переноса сайта на другой сервер. Сначала определите LCP-элемент и разложите показатель на этапы — так станет понятно, нужно ли менять изображение, порядок загрузки ресурсов или работу главного потока браузера.
Что означает высокий LCP при хорошем TTFB
LCP (Largest Contentful Paint) показывает, когда в видимой области появился крупнейший блок текста или изображение. По рекомендации web.dev, хорошим считается LCP не более 2,5 секунды для как минимум 75% загрузок отдельно на мобильных и настольных устройствах.
TTFB измеряет только путь до первого байта HTML. После него браузеру ещё нужно найти LCP-ресурс, скачать его, обработать стили и скрипты, построить страницу и вывести элемент на экран. Поэтому быстрый сервер и медленная отрисовка не противоречат друг другу.
Сначала найдите настоящий LCP-элемент
Откройте проблемную страницу в Chrome DevTools, перейдите в Performance, запишите загрузку и откройте событие LCP или подсказку LCP by phase. Зафиксируйте сам элемент и четыре части времени:
- TTFB — ожидание HTML;
- задержка до начала загрузки LCP-ресурса;
- длительность загрузки ресурса;
- задержка между окончанием загрузки и отрисовкой элемента.
Проверяйте именно тот шаблон и устройство, где видна проблема. На телефоне LCP-элементом может стать баннер, а на широком экране — крупный заголовок; один лабораторный запуск не заменяет полевые данные реальных посетителей.
Если общий балл PageSpeed выглядит хорошо, а пользователи всё равно жалуются на скорость, сначала сравните лабораторные и полевые данные.
Если ресурс начинает загружаться поздно
Посмотрите в Network, когда браузер запросил LCP-изображение. Большой промежуток после получения HTML обычно означает, что ресурс нельзя обнаружить сразу.
Проверьте по порядку:
- есть ли изображение в исходном HTML, а не добавляется ли оно только JavaScript;
- не задан ли главный баннер как фоновое изображение во внешнем CSS;
- нет ли у LCP-изображения ленивой загрузки;
- не ждёт ли запрос выполнения виджета, слайдера или клиентского шаблона;
- не стоит ли перед ним длинная цепочка перенаправлений и зависимостей.
Главное изображение лучше объявить обычным <img> с корректными srcset и sizes. Для действительно приоритетного ресурса можно рассмотреть fetchpriority="high" или preload, но не назначать высокий приоритет множеству файлов: они начнут конкурировать между собой.
Если ресурс загружается долго
Когда запрос стартует рано, но занимает большую часть LCP, проверьте размер передаваемого файла и фактические размеры изображения на экране. Не отправляйте мобильному устройству исходник, подготовленный для большого монитора.
Затем проверьте формат, сжатие, кэширование и расстояние до пользователя. CDN может помочь распределённой аудитории, но не исправит слишком тяжёлое изображение или неверно выбранный вариант srcset.
Не оптимизируйте все картинки одновременно. Начните с ресурса, который DevTools назвал LCP, повторите замер в тех же условиях и только после этого переходите к остальным.
Если файл загружен, но элемент появляется поздно
Большая задержка от окончания запроса до отрисовки указывает на блокировку рендера. В этот момент сеть уже могла закончить работу, а браузер всё ещё занят.
Ищите четыре причины:
- блокирующие таблицы стилей или синхронные скрипты в
<head>; - длинные задачи JavaScript на главном потоке;
- появление LCP-элемента только после выполнения клиентского кода;
- скрытие блока до инициализации слайдера, эксперимента или веб-шрифта.
В Performance проверьте участок перед LCP: длинные задачи видны на дорожке Main. Для текстового LCP отдельно посмотрите загрузку шрифта и правила font-display; для изображения — не удерживает ли его класс вроде opacity: 0 до завершения скрипта.
Удалять JavaScript вслепую не нужно. Разделите длинную задачу, отложите некритичный код и убедитесь, что первый экран может появиться без ожидания аналитики, чата или другого стороннего виджета.
Как проверить исправление
Повторите запись с теми же параметрами устройства и сети. Сравнивайте не только итоговый LCP, но и изменённый этап: запрос должен начинаться раньше, файл — загружаться быстрее, а задержка рендера — уменьшаться.
После лабораторной проверки наблюдайте полевые данные по важным шаблонам страниц. Изменения в панели реальных пользователей появляются не мгновенно, а разные URL могут иметь разные LCP-элементы.
Также сохраните отдельный контроль доступности и времени ответа. Мониторинг времени ответа помогает заметить серверный сбой, но не измеряет работу браузерного рендера — эти два вида наблюдений дополняют друг друга.
Короткий порядок действий
- Подтвердите проблему на нужном URL и типе устройства.
- Найдите LCP-элемент и самый длинный этап метрики.
- При позднем старте сделайте ресурс обнаруживаемым из HTML.
- При долгой загрузке уменьшите и правильно выберите файл.
- При задержке рендера проверьте CSS, главный поток, шрифты и клиентскую отрисовку.
- Повторите сопоставимый тест и дождитесь полевых данных.
Web-Puls можно использовать для регулярного контроля доступности и времени ответа сайта, чтобы отделять серверные инциденты от проблем отрисовки. Если такой базовый контроль ещё не настроен, добавьте сайт в мониторинг и продолжайте проверять LCP инструментами браузера.