Я только что нашел жесткую лазейку в LCP, из-за которой тяжелая...

Я только что нашел жесткую лазейку в LCP, из-за которой тяжелая картинка вообще не засчитывается как кандидат для LCP, делится Арьен Карел.

1. Запрети серверу отдавать заголовок content-length для изображений.

2. Разбей главное LCP-изображение на чанки и отправь первый кусок размером ниже порога энтропии для LCP (0.05 бит на CSS-пиксель, около 5kB для стандартной hero-картинки).

3. Выжди 800 мс, чтобы прошла первая отрисовка, и только затем отправь остальные чанки.

Вуаля: теперь Chrome проигнорирует твое LCP-изображение.

Почему так?

Chrome отбрасывает низкоконтентные изображения, но он рассчитывает энтропию по тем байтам, которые успел получить к моменту первой отрисовки, и не пересчитывает её после загрузки остатков.

Инсайты комьюнити

— Этот подход с накруткой метрик выходит далеко за пределы LCP: JS-редиректы для TTFB (которые должны обрабатываться на сервере или edge-нодах), полное обновление компонента во избежание CLS, асинхронный CSS для FCP, ранний yield, который не улучшает UX, но влияет на INP, и слишком отложенная загрузка ресурсов. Масса правильных паттернов ловит пессимизацию просто за то, что они отдают качественный UX чуть медленнее, чем голая статика.

— Более простая альтернатива разбиению на чанки: трюк с прозрачностью opacity [Механика не описана].

— Обход метрики не решает проблему: пользователи всё равно видят, что страница тормозит, независимо от нарисованного балла. Прятать hero-изображение за задержкой в 800 мс — это обман метрики, а не улучшение пользовательского опыта.

— Чтобы подтвердить механику Chrome, запиши трейс и отфильтруй по LCP-элементу, чтобы точно увидеть происходящее. Сверь результаты в Google PageSpeed и CrUX — этот сброс может не обойти UX-параметры Chrome.

@MikeBlazerX

📈 "Пушки" — в @MikeBlazerPRO