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.#LCP #CWV #SiteSpeed
@MikeBlazerX
📈 "Пушки" — в @MikeBlazerPRO
