LCP — это время, за которое в видимой части страницы появляется самый большой элемент (обычно крупная картинка, видео, заголовок или герой-блок). Хороший LCP — до 2,5 с, плохой — больше 4 с.
Чаще всего LCP ломают тяжёлые картинки, отсутствие preload для главного hero-изображения, медленный TTFB, render-blocking CSS и JS. Чтобы починить: оптимизировать главное изображение в WebP, добавить preload, вынести критический CSS инлайн, отложить ненужный JS.
Hero-блок главной страницы — большая картинка 1200×600. До оптимизации LCP = 3,4 с (poor). После перевода в WebP + preload — 1,8 с (good).
Бенчмарк
LCP — одна из трёх метрик Core Web Vitals наряду с INP и CLS, и в зачёт идёт 75-й перцентиль по реальным посетителям (поле CrUX в Google), а не цифра из лабораторного PageSpeed. Частая ошибка: в Lighthouse зелёные 1,8 с, а в Search Console раздел «Основные интернет-показатели» горит красным — потому что лаборатория мерит быстрый канал и мощную машину, а живая аудитория сидит на 4G и бюджетных Android. Сверяйтесь с полевыми данными, а не с одним прогоном.
Со временем менялась и сама механика метрики: с 2024 года Google разбил LCP на под-фазы — TTFB, задержку загрузки ресурса, время самой загрузки и задержку отрисовки. Это сразу показывает, где затык. Если в водопаде главная картинка стартует поздно, виноваты preload и приоритеты (fetchpriority="high"); если долгий TTFB — проблема на бэкенде или в кеше, и WebP тут не спасёт. У Яндекса прямого аналога CWV в ранжировании нет, но скорость влияет на отказы и поведенческие, которые он учитывает прямо.
Время до отрисовки крупнейшего блока в первом экране — обычно hero-картинки, видео-постера или заголовка.
TTFB, задержка до загрузки ресурса, его загрузка и задержка отрисовки — узкое место ищут по самой длинной фазе.
Зелёная зона до 2,5 с на 75-м перцентиле реальных пользователей — иначе хуже позиции в Google и выше отказы.