Паветта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 и выше отказы.
Элементом, по которому считается метрика, обычно оказывается крупная картинка первого экрана, фоновое изображение или большой блок текста. Определить его можно в инструментах разработчика: панель производительности подсвечивает элемент прямо на странице. Дальше становится понятно, что чинить: картинку, шрифт или ответ сервера.
Порядок работ идёт от источника задержки. Сначала ускоряют ответ сервера, потому что TTFB входит в метрику целиком. Потом уменьшают саму картинку: современный формат, правильные размеры под экран и предварительная загрузка. В конце убирают то, что блокирует отрисовку: тяжёлые стили и шрифты, которые грузятся до первого экрана.
Частые вопросы
Какой элемент считается главным на странице?
Самый крупный видимый элемент в области первого экрана: обычно изображение, фон блока или большой заголовок. Браузер выбирает его сам, поэтому конкретный элемент удобнее смотреть в панели производительности инструментов разработчика.
Как измерить метрику правильно?
По данным реальных пользователей из отчётов о скорости, потому что лабораторный тест показывает один прогон на быстром канале. Ориентируются на семьдесят пятый процентиль. Полевые данные обновляются с задержкой, поэтому эффект правок виден через несколько недель.
Влияет ли скорость на позиции?
Влияет как один из факторов и сильнее всего на мобильных, где разница в скорости заметнее. При равном качестве контента быстрая страница получает преимущество, но медленная страница с лучшим ответом на запрос обгоняет быструю пустышку.
Что чаще всего портит показатель?
Тяжёлое изображение первого экрана без оптимизации и предварительной загрузки, медленный ответ сервера, блокирующие стили и шрифты. Ленивая загрузка, повешенная на главную картинку, тоже ухудшает результат: её оттуда нужно снимать.