LCP на мобильном - это текст, а не картинка

На нашем сайте LCP-элементом на мобильном оказался подзаголовок первого экрана, а не hero-картинка: на телефоне картинку скрывает display: none, и браузер её просто не видит. Вывод получился неожиданным - скорость упиралась в стили и шрифт, а не в вес изображений, и работа с картинками не сдвинула бы метрику ни на десятую долю секунды.

Стандартный совет по LCP одинаков в половине чек-листов: сожмите картинку, переведите в WebP, поставьте приоритет загрузки. Мы прошли этот путь и оптимизировали hero-изображение по всем правилам - а метрика на мобильном не сдвинулась ни на секунду. Обидно, но факт: элемент, который считает браузер, был вовсе не картинкой. О том, как мы разбирали путь до 5,5 секунды на мобильном PageSpeed, писали отдельно в статье Мобильный PageSpeed 69.

Разбираем по порядку: что такое LCP, как браузер выбирает элемент, почему на телефоне и на компьютере это часто разные узлы, и что делать, когда виноват не вес изображения, а текст и шрифт.

Что такое LCP и как браузер выбирает элемент

LCP, Largest Contentful Paint - один из трёх показателей Core Web Vitals, наравне с INP и CLS. Метрика фиксирует момент, когда на экране появляется самый крупный видимый блок контента: картинка, постер видео, блок с фоном или обычный текст - заголовок, абзац, кнопка с подписью. Ничего сверхъестественного.

Браузер на каждый кадр отрисовки сравнивает площадь всех элементов, которые уже видны на экране, и запоминает самый крупный. Как только ничего крупнее не появляется, значение фиксируется как финальное. Текстовый узел считается наравне с картинкой: если заголовок из трёх строк занимает больше площади, чем миниатюра рядом, LCP-элементом станет заголовок.

Подробный разбор всех трёх метрик Core Web Vitals и того, как их мерить, - в статье Core Web Vitals 2026.

Как узнать свой LCP-элемент

Гадать не нужно. Отчёт называет элемент прямо. В PageSpeed Insights и в Lighthouse под графиком метрик есть строка "LCP element" со ссылкой на конкретный узел разметки. В панели производительности браузера, вкладка Performance, тот же элемент подсвечен на временной шкале меткой LCP.

Мы сняли отчёт по мобильному профилю и увидели там класс .hero__sub - подзаголовок, а не картинку. Не ожидали. Инструмент указывает на конкретный селектор, а не на предположение.

Список инструментов, которыми удобно снимать такие отчёты, - в статье Как проверить скорость сайта.

Почему на мобильном и десктопе это часто разные элементы

Мерить нужно оба профиля отдельно. На широком экране картинка часто занимает больше площади, чем текст рядом, и становится LCP-элементом. На узком вёрстка перестраивается: блоки уходят в колонку, картинка сжимается или прячется, а заголовок с подзаголовком растягиваются на всю ширину и в сумме дают больше пикселей, чем маленькая картинка сбоку.

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

О том, как вёрстка перестраивается между брейкпойнтами и где там чаще всего теряют скорость, - в статье Адаптивная вёрстка.

Что задерживает текстовый LCP

Если LCP-элемент - текст, вес картинок к результату отношения не имеет. Вовсе. Задержка обычно возникает в трёх местах.

Блокирующие стили. Пока браузер не получил и не разобрал CSS, он не может посчитать размеры и положение блоков, а значит не отрисовывает даже готовый текст. Если стили подключены обычным блокирующим <link rel="stylesheet">, весь путь до первой отрисовки идёт через сеть до этого файла.

Шрифт, который приходит третьим запросом. Классическая цепочка: сначала HTML, потом CSS, потом сам шрифт. Пока в разметке стоит подключение к внешнему сервису шрифтов, браузер сначала получает CSS с чужого домена, а из него - ссылку на шрифт со второго чужого домена, и каждое звено добавляет отдельный сетевой цикл. После переноса шрифтов на свой сервер (см. Свои шрифты вместо Google Fonts) цепочка у нас сократилась с двух чужих доменов до одного.

Поведение при подмене шрифта. Пока веб-шрифт не загрузился, браузер либо ждёт и ничего не показывает (font-display: block), либо сразу выводит текст системным шрифтом и подменяет его позже (font-display: swap). В первом случае LCP откладывается до конца загрузки шрифта, во втором текст виден раньше, но потом заметно "прыгает" при смене начертания.

Как помогает предзагрузка и что не стоит предзагружать

<link rel="preload"> для файла шрифта переносит его загрузку в начало страницы, а не оставляет ждать, пока браузер доберётся до нужного правила в CSS. Без предзагрузки шрифт стартует позже, чем мог бы.

Частая ловушка - предзагружать все начертания подряд. Каждый preload конкурирует за канал с остальными критичными файлами первого экрана: предзагрузите восемь файлов шрифта разом, и браузер потянет их параллельно с CSS и разметкой, а отрисовка отложится уже по другой причине.

Мы предзагружаем только два начертания, видимых на первом экране: обычное для текста и жирное для заголовка. Остальные грузятся обычным образом, когда до них доходит очередь в CSS.

Когда LCP всё-таки картинка

Текстовый LCP - не универсальное правило, а частный случай конкретной вёрстки. На странице каталога с широким баннером или крупной обложкой товара LCP-элементом почти всегда остаётся изображение. Тогда работают обычные приёмы:

• Указывать реальные width и height или aspect-ratio в CSS, чтобы браузер резервировал место под картинку заранее, не дожидаясь загрузки файла.
• Использовать современный формат, WebP или AVIF: при том же визуальном качестве файл заметно легче.
• Ставить fetchpriority="high" и loading="eager" на LCP-картинку, если она точно попадает в первый экран, а всё, что ниже, грузить отложенно.
• Не грузить одну и ту же тяжёлую картинку для мобильного и десктопного экрана: srcset и sizes отдают браузеру только тот размер, который нужен на конкретном устройстве.

Официальное определение метрики и актуальные пороги значений собраны в документации Google Search Central.

Скрытая картинка не участвует в LCP вообще

Отдельный случай. Если элемент скрыт через display: none, у него нет площади и бокса в раскладке. Для браузера он не существует. В LCP попасть он не может, даже если файл продолжает грузиться в фоне.

Здесь легко наступить на вторые грабли: раз скрытая картинка не влияет на LCP, ей иногда оставляют обычную немедленную загрузку - рассуждение "она всё равно не в счёт". Но браузер узнаёт, что элемент скрыт, только после применения стилей, а запрос на файл к этому моменту уже мог уйти в сеть и съесть часть канала у того, что действительно видно. Верное решение - loading="lazy" даже для картинки, скрытой лишь на части экранов: раз она никогда не попадает во вьюпорт на телефоне, запрос на неё там просто не произойдёт.

Чек-лист: как проверить LCP на своём сайте

Порядок, которым проверяем сами:

1. Снять отчёт отдельно для мобильного и десктопного профиля - в PageSpeed Insights или локально через Lighthouse.
2. Найти строку с LCP-элементом и открыть его в инструментах разработчика: убедиться, что это тот узел, который вы ожидали.
3. Если элемент - текст: проверить путь до стилей и шрифта, посчитать число запросов до первой отрисовки текста, добавить preload только для начертаний первого экрана.
4. Если элемент - картинка: проверить размеры, формат, fetchpriority и корректность srcset.
5. Проверить, не участвует ли в LCP на другом брейкпойнте скрытый через display: none элемент - и не уходит ли на него сетевой запрос раньше времени.
6. Повторить проверку на обоих профилях после правок: изменение под десктоп почти никогда не чинит мобильный результат само по себе.

Где чаще всего теряют время на оптимизации LCP

LCP не привязан к картинке по умолчанию. Это просто самый крупный видимый элемент, и на мобильном вёрстка часто отдаёт эту роль тексту. Прежде чем сжимать hero-картинку, стоит открыть отчёт и увидеть, какой элемент браузер выбрал на самом деле: это экономит недели работы над тем, что на результат не влияет. У нас разница была ровно в этом - мобильный упирался в шрифт и стили, десктопный в картинку, и лечились они разными правками.

Если разбираетесь, почему собственный сайт медленный не там, где ожидали, дальше стоит сравнить оба профиля вживую и понять, где реально теряются секунды. В услуге Корпоративные сайты скорость первого экрана - часть техзадания с самого начала, а не доработка после сдачи проекта.