LCP-оптимизация: почему вы чините не то, что реально тормозит сайт

Смотрите, в чём тут дело: LCP-оптимизация сайта — одна из самых коварных задач в веб-производительности. Вы делаете всё «по учебнику» — сжимаете изображения, подключаете CDN, убираете лишние скрипты. Показатель не двигается. Почему? Потому что браузер с самого начала измерял не тот элемент, а вы оптимизировали не то, что реально влияет на скорость в глазах Google.

Именно этот случай описал Джон Мюллер из Google, сославшись на разбор платформы Nuvemshop — крупного латиноамериканского e-commerce-конструктора. За год команда подняла долю магазинов с хорошим LCP с 57% до 96%. Но сначала им пришлось понять, что они вообще-то чинили не то.

Что такое LCP и почему браузер может ошибиться

LCP (Largest Contentful Paint) — это время, за которое на экране появляется самый крупный видимый элемент: обычно главное изображение или большой блок текста. Это один из трёх показателей Core Web Vitals, которые Google учитывает при ранжировании.

Проблема в том, что браузер сам решает, какой элемент считать «наибольшим». И если на вашем сайте есть карусели, баннеры или анимации с CSS-переходами — он может выбрать совсем не то, что видит пользователь в первые секунды.

На Nuvemshop 85% магазинов использовали карусели на главной странице. CSS-переходы задерживали момент, когда карусель становилась «видимой» для алгоритма LCP-детекции. В итоге браузер фиксировал как LCP другой элемент — баннер ниже по странице, который отображался без задержки перехода. Команда разработчиков год оптимизировала этот баннер. А настоящий виновник — карусель — оставалась нетронутой.

Три реальные причины, по которым LCP определяется неправильно

Кейс Nuvemshop выделил три технических причины. Они встречаются не только в e-commerce — узнаёте ли вы их на своём сайте?

1. CSS-переходы на верхних блоках. Анимация при появлении карусели или баннера откладывает момент, когда браузер «засчитывает» элемент видимым. Детектор LCP смотрит на момент рендера, а не на то, что видит пользователь. Переход заставляет браузер искать другой кандидат — тот, что появился без задержки.
2. Атрибут loading=»lazy» на первом изображении. Ленивая загрузка — отличная практика для картинок ниже линии сгиба. Но если она стоит на главном изображении в верхней части страницы, браузер не начинает его загружать сразу. Это гарантированно ухудшает LCP. Официальная документация Google прямо предупреждает: никогда не ставьте loading=»lazy» на потенциальный LCP-элемент.
3. Отсутствие сигнала приоритета. Браузер загружает ресурсы по своей внутренней очереди. Если ключевое изображение не помечено как высокоприоритетное, оно будет ждать своей очереди среди десятков других запросов.

Три конкретных исправления — и как они работают

Давайте по шагам. Nuvemshop сделала три точечных изменения в коде, которые решили проблему.

1. Убрали CSS-переходы с верхних секций. Блоки в шапке страницы теперь появляются мгновенно, без анимации. Браузер сразу фиксирует их как кандидатов на LCP — и выбирает правильный элемент.

2. Сняли loading=»lazy» с первого изображения. Это выглядит просто:

Было: <img src=»slide-1.webp» loading=»lazy» alt=»Главное фото»>
Стало: <img src=»slide-1.webp» alt=»Главное фото»>

Одно слово — и изображение начинает грузиться сразу при разборе HTML, а не когда до него доходит скролл.

3. Добавили fetchpriority=»high» на ключевое изображение. Этот атрибут сообщает предзагрузчику браузера: «Это важно, тяни первым». Выглядит так:

Было: <img src=»slide-1.webp» alt=»Главное фото»>
Стало: <img src=»slide-1.webp» fetchpriority=»high» alt=»Главное фото»>

Тут есть нюанс: атрибут стоит ставить только на одно-два изображения. Если пометить всё как «высокоприоритетное» — браузер снова потеряет ориентиры, и эффекта не будет.

Четвёртым изменением стало edge-кеширование для снижения задержки сервера — но оно дополняло три основных, а не заменяло их.

Что это изменило — и как читать цифры честно

После всех изменений Nuvemshop сообщает: доля магазинов с хорошим LCP выросла с 57% до 96%, а общий показатель прохождения Core Web Vitals — с 48% до 72%.

Дополнительно компания фиксирует рост конверсии на 8,9% и рост вовлечённости корзины на 8,4% у мобильных пользователей из органического поиска Google. Эти цифры — год к году, не контролируемый эксперимент. Принимать их как доказанную причинно-следственную связь не стоит. Слишком много переменных.

Что точно стоит взять из кейса: Core Web Vitals — это не главный фактор ранжирования. Google неоднократно подчёркивал, что релевантность контента важнее скорости. Но более быстрый сайт — это лучший пользовательский опыт, а значит, больше шансов, что человек не уйдёт до того, как прочитает ваш текст или нажмёт кнопку.

Как проверить, тот ли элемент вы оптимизируете

Если вы занимаетесь SEO-продвижением в 2025–2026 году, регулярная проверка Core Web Vitals уже должна быть частью рутины. Но прежде чем что-то трогать — сначала убедитесь, что вы смотрите на правильный элемент.

Вот короткий чеклист:

• PageSpeed Insights → раздел «Диагностика» покажет, какой именно элемент браузер считает LCP на конкретной странице. Проверьте на мобильных и десктопных версиях отдельно.
• Chrome DevTools → вкладка Performance → запишите загрузку страницы и найдите метку LCP в таймлайне. Вы увидите, на каком элементе она стоит.
• Проверьте страницы разных типов — главную, категорию, карточку товара или отдельный пост. LCP-элемент может быть разным на каждом из них.
• Найдите CSS-переходы на верхних блоках. Если там есть анимация появления — это первый подозреваемый.
• Найдите первое крупное изображение в HTML. Проверьте: нет ли на нём loading=»lazy»? Есть ли fetchpriority=»high»?

Это займёт 15–20 минут. Но именно этот шаг позволяет не тратить время на оптимизацию «не того».

Главный вывод: диагноз важнее лечения

История Nuvemshop — хорошая иллюстрация того, что в технической оптимизации (как и в продажах) первый шаг — правильно поставить диагноз. Можно год сжимать изображения, переезжать на другой хостинг и подключать новые CDN — и не сдвинуться с места, если исходная точка выбрана неверно.

Это, кстати, та же логика, с которой работает видимость контента в AI-поисковиках: сначала нужно понять, как система «видит» ваш материал, а потом уже думать, что менять. Без этого шага любые правки — стрельба в темноте.

Если вы ведёте сайт на конструкторе или CMS с гибкими шаблонами — проверьте прямо сейчас, какой элемент браузер считает вашим LCP. Не угадывайте. Смотрите в инструменты. Это бесплатно и занимает несколько минут.

Разбираю похожие вопросы — про SEO, технический маркетинг и то, что реально влияет на результат — в моём Telegram-канале. Заходите, если хотите без воды и по делу.

По мотивам материала Search Engine Journal «Google’s Mueller Flags A Case On Why LCP Fixes Miss the Target».

100 нейросетей
для экспертов

Подборка, которой реально пользуются — пришлю на почту. Без спама, отписка в один клик.

Для решения
любых задач

Для роста
и эффективности

Для бизнеса
и карьеры

🎁 Заберите 100 нейросетей для экспертов

Получить подборку Соглашаюсь на обработку email и получение писем