Core Web Vitals и LCP: 5 узких мест, которые ломают лендинг быстрее дизайна

Core Web Vitals и LCP: 5 узких мест, которые ломают лендинг быстрее дизайна

LCP почти всегда упирается не в «тяжелый сайт», а в один доминирующий элемент: hero-картинку, фон, крупный заголовок или блок с видео. Давайте разберем под капотом: если этот элемент грузится поздно, весь экран выглядит «медленным», даже когда остальная страница уже готова.

Проверьте по порядку:
• не тянете ли вы hero как огромный JPG вместо WebP/AVIF;
• не мешает ли этому изображению lazy-load — для первого экрана он обычно вреден;
• не блокирует ли рендер шрифт: лучше preload для ключевого начертания и font-display: swap;
• не уехал ли LCP-элемент внизу DOM, где он ждет чужие скрипты;
• не грузится ли фон через CSS, если тот же контент можно отдать обычным img.

Что по производительности? Самый частый анти-паттерн — когда первый экран собран из трех слоев: фон, полупрозрачная маска и тяжелый текстовый блок с иконками. Браузер сначала ищет CSS, потом шрифты, потом картинку. В итоге LCP растет, хотя визуально «всего лишь красивый герой».

Вердикт для продакшена: сначала найдите реальный LCP-элемент, затем ускоряйте именно его. Сократите размер, снимите лишние блокировки, уберите lazy-load с первого экрана и проверьте, не тащит ли он за собой цепочку зависимостей. Если один элемент решает первую секунду, оптимизировать надо его, а не весь лендинг сразу.