LCP: четыре фазы, одна доминирующая стоимость

Команда подключает CDN, сжимает hero-картинку — и LCP почти не двигается. Проблема была не в размере картинки — браузер обнаруживал её поздно, после выполнения JS-бандла. Фикс — один атрибут в HTML. LCP ломается четырьмя разными способами, и только один фикс работает на каждую фазу.

Что измеряет LCP и когда он срабатывает.

Largest Contentful Paint — время отрисовки самого крупного contentful-элемента, видимого во вьюпорте во время загрузки. «Контент» — конкретный список: <img>, постер <video>, фоновое изображение через url(), блочные элементы с текстом. Браузер наблюдает за элементами по мере их отрисовки, обновляет кандидата на «самый крупный» и финализирует LCP на первом взаимодействии пользователя (после того как пользователь взаимодействует, дальнейшая «загрузка» уже не загрузка). На большинстве страниц LCP-элемент — hero-картинка или главный заголовок.

Четыре фазы.

Время LCP — это сумма четырёх последовательных частей. Фикс разный для каждой.

1. TTFB — время до первого байта от сервера. Причины: медленный SSR, нет CDN, медленный запрос к базе на пути рендера. Фикс: кеш, CDN, вынести медленные загрузки данных с пути рендера (streaming SSR с Suspense-границей).

2. Resource load delay — зазор между TTFB и началом загрузки LCP-картинки браузером. Причина: браузер обнаруживает картинку поздно — она ссылается только в CSS или инжектируется JS, не в начальном HTML, preload-сканер её не видит. Фикс: поместить LCP-картинку в начальный HTML как обычный <img> с fetchpriority="high" или <link rel="preload">.

3. Resource load time — сколько сама LCP-картинка скачивается. Причина: огромный файл, неправильный формат, не сжата. Фикс: правильный формат (AVIF, WebP), корректный размер для вьюпорта через srcset, сжатие.

4. Element render delay — зазор между окончанием скачивания картинки и её отрисовкой. Причина: render-blocking CSS или JS всё ещё занимает главный поток после готовности картинки. Фикс: инлайн критического CSS, defer некритичного JS.

Preload-сканер — почему обнаружение решает всё.

Браузеры запускают вторичный парсер — preload-сканер — который обгоняет основной HTML-парсер в поиске ресурсов для загрузки, даже пока основной парсер заблокирован скриптом. Именно поэтому <img> в начальном HTML грузится рано: сканер видит его и немедленно стартует загрузку. И именно поэтому картинка, ссылающаяся только в CSS (background-image) или инжектируемая JS, грузится поздно: сканер её не видит — картинка не обнаруживается, пока CSS не парснется или JS не выполнится.

Глубинная причина, почему «поместить LCP-картинку в HTML» работает: только в HTML preload-сканер может её найти без ожидания. fetchpriority="high" затем поднимает ту загрузку выше других ранних ресурсов; <link rel="preload"> — тяжёлая артиллерия для ресурсов, которые сканер всё равно не видит.

Самая частая самонанесённая LCP-регрессия.

Добавление loading="lazy" на hero-картинку. Lazy loading существует для defer-а картинок ниже сгиба — тех, до которых пользователь ещё не доскроллил. Применить его к hero означает сказать браузеру отложить загрузку ровно той картинки, которую таймит метрика LCP. Результат — почти всегда большой resource load delay, которого раньше не было. Никогда не lazy-load-ьте LCP-элемент.