LCP-изображение: как загружать первый экран без лишнего ожидания

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

LCP-изображение первого экрана — это элемент, который браузер считает самым крупным в видимой области и полностью отрисовывает. Проверяйте фактического кандидата в инструменте измерения, а не по весу файла. Уберите lazy с кандидата, задайте размеры, дайте адаптивные варианты и один preload только при позднем обнаружении.

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

Механизм тут не про «скорость сайта вообще». Largest Contentful Paint измеряет момент, когда самый крупный элемент в видимой области полностью отрисован. Если это изображение, браузер должен сначала узнать о нём, скачать файл подходящего размера, декодировать и нарисовать. Каждый шаг может стать узким местом: ссылка спрятана в скрипте, файл весит как обои для рабочего стола, размер не задан и вёрстка прыгает, а на телефоне грузится десктопная версия. Ниже — методика, как найти своё узкое место и что с ним делать, без обещаний фиксированного балла.

Что именно браузер считает главным изображением первого экрана

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

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

Есть и неприятный нюанс: изображение, добавленное через CSS-фон, браузер обнаруживает позже, чем <img> в разметке, потому что сначала должен разобрать стили. Об этом стоит помнить, когда вы решаете, чем именно выводить первый экран. Официальное описание того, как браузер выбирает и когда фиксирует кандидата, есть в материале web.dev об оптимизации LCP — там же перечислены четыре фазы: обнаружение, загрузка, простой до отрисовки и сама отрисовка.

Если ваша задача — проверить загрузку первого экрана, на странице соответствующего направления 404ai можно посмотреть опубликованные возможности и оставить описание текущего процесса. Конкретные подключения, исходные данные и критерии приёмки согласуем отдельно.

Четыре фазы, в которых теряется время

Разложим путь картинки на отрезки, чтобы не гадать, где провал. Первая фаза — обнаружение: браузер должен встретить ссылку на ресурс в разобранном HTML или в CSS, который успел примениться. Вторая — загрузка: запрос уходит, сервер отвечает, файл летит по сети. Третья — простой: ресурс уже есть, но браузер ждёт чего-то ещё, например блокирующего скрипта или основного потока, занятого другой работой. Четвёртая — отрисовка: декодирование и вывод на экран.

Диагностика строится на том, чтобы понять, какая фаза у вас длинная. Если ссылка появляется только после выполнения JavaScript, вы платите за обнаружение — браузер узнаёт о картинке поздно, даже при быстром сервере. Если файл огромный, длинной будет загрузка. Если картинка мелкая, но её вывод ждёт тяжёлый скрипт, вы теряете на простое. Один и тот же симптом «медленно» имеет три разных лечения, и путать их — самая частая ошибка.

Отдельно про размер: когда у изображения не заданы ширина и высота (или их аналоги через CSS), браузер не знает, сколько места зарезервировать. Вёрстка перестраивается после загрузки, элемент «прыгает», а метрика отрисовки сдвигается. Явные размеры или соотношение сторон — не косметика, а условие того, что картинка встанет на место сразу.

Почему lazy-загрузка на первом экране работает против вас

Атрибут loading="lazy" — полезная штука для галерей и подвала, но на главном изображении первого экрана он превращается во вредителя. Смысл lazy в том, чтобы отложить загрузку до момента, когда элемент приблизится к видимой области. Для картинки, которая и так в первом экране, это отложенное обнаружение: браузер узнаёт о ресурсе позже, чем мог бы, и LCP растёт.

Типичная картина: разработчик «оптимизировал» все изображения разом, навесив lazy на каждое, включая герой. Формально страница стала легче при первой загрузке, но главная картинка приходит с задержкой. Проверять надо адресно: у LCP-кандидата не должно быть lazy, у него должен быть высокий приоритет. Остальные изображения ниже первого экрана — пожалуйста, пусть ждут.

Та же логика с fetchpriority. Это подсказка браузеру, что ресурс важен и его стоит запросить раньше конкурирующих. Она не гарантирует мгновенность и не заменяет уменьшение файла, но помогает, когда на старте страницы браузер разрывается между несколькими запросами. Подсказку ставят на само главное изображение, а не на всё подряд.

Ловушка CSS-фона и картинок, спрятанных в скрипте

Два способа вывести первый экран особенно часто портят обнаружение. Первый — background-image в CSS. Браузер должен скачать и разобрать стили, применить их к элементу, и только потом узнает URL фона. Если стили ещё и подключаются скриптом или лежат в отдельном большом файле, цепочка удлиняется. Для декоративных фонов это нормально, для смыслового изображения первого экрана — риск.

Второй — изображение, которое вставляет JavaScript после гидратации или подгрузки данных. Пока скрипт не выполнился, в разметке нет ни <img>, ни ссылки на файл, и браузер физически не может начать загрузку. Это часто случается в одностраничных приложениях и в блоках, которые «оживают» после запроса к API. Лечится не ускорением скрипта, а тем, чтобы главное изображение присутствовало в исходном HTML и не зависело от выполнения кода.

Проверка простая: откройте исходный код страницы (не инспектор после выполнения скриптов, а именно первоначальный ответ сервера) и поищите ссылку на главную картинку. Если её там нет — вы платите за обнаружение, и никакое сжатие это не компенсирует.

Изображение первого экрана: карточка LCP-изображения

Чтобы не спорить вкусами, заведите один рабочий документ на каждое ключевое изображение первого экрана. Он дисциплинирует и разработку, и приёмку. Ниже — условная форма, которую можно скопировать в трекер или вики.

Форма нужна не ради бюрократии. Когда картинку меняет контент-менеджер, а разметку правит разработчик, без общей карточки легко получить свежую фотографию на 4 МБ поверх настроенного srcset. Карточка делает видимым разрыв между «мы договорились» и «что реально в продакшене».

Размер имеет значение: как не отдавать телефону десктопный файл

Самая частая причина тяжёлой загрузки — один файл на все устройства. Телефон с экраном 390 пикселей по ширине получает изображение, рассчитанное на монитор 1920, и тратит трафик и время на пиксели, которые не покажет. Решение — адаптивные изображения: атрибуты srcset и sizes подсказывают браузеру, какой вариант выбрать под текущий экран и плотность пикселей. Подробный разбор синтаксиса и типичных ошибок — в руководстве MDN по адаптивным изображениям.

Ключевое слово — «подсказывают». Браузер сам решает, какой файл взять, исходя из ширины вьюпорта, плотности и собственных эвристик. Ваша задача — дать разумный набор вариантов и честно описать, сколько места изображение занимает в раскладке через sizes. Если sizes врёт, браузер выберет не тот файл: например, посчитает, что картинка во всю ширину, и на телефоне возьмёт слишком крупный вариант.

Практика: готовьте 3–4 размера, а не десяток. Слишком большой набор усложняет поддержку и почти не даёт выигрыша. Формат — современный (WebP или AVIF) с разумным запасным вариантом, если аудитория старая. И не забывайте, что «сжали в фотошопе на глаз» — не измерение: вес и визуальное качество проверяются на реальных экранах.

Preload: один полезный, несколько — вредных

<link rel="preload"> говорит браузеру: этот ресурс понадобится скоро, начни его грузить раньше. Для LCP-изображения, которое иначе обнаруживается поздно (например, выводится через CSS или подключается в конце разметки), один аккуратный preload может сэкономить заметное время. Но у инструмента есть цена: preload конкурирует за пропускную способность с другими важными запросами.

Отсюда типичная ошибка — несколько preload на разные изображения первого экрана, шрифты и скрипты одновременно. Браузер начинает грузить всё «важное» сразу, приоритеты размываются, и главная картинка снова ждёт. Правило простое: preload только для настоящего LCP-кандидата, и только если без него обнаружение запаздывает. Если картинка уже стоит в начале HTML обычным <img>, дополнительный preload часто не нужен и может даже навредить дублирующим запросом.

Для адаптивных изображений preload должен уметь выбирать вариант так же, как это сделал бы <img>: с атрибутами imagesrcset и imagesizes. Иначе вы предзагрузите один файл, а браузер потом возьмёт другой — двойная работа вместо ускорения.

Два условных эпизода: где именно терялось время

Эпизод первый, «тяжёлый герой». Условный производитель мебели держит на главной фотографию гостиной во весь экран. Файл — PNG на 2,8 МБ, один на все устройства, выводится через <img> без srcset, размеры не заданы. На десктопе с быстрым интернетом терпимо, на мобильном в метро картинка приходит через несколько секунд, а до её появления вёрстка прыгает. Здесь длинная фаза — загрузка, плюс сдвиг из-за отсутствия размеров. Лечение: современный формат, набор размеров под мобильный и десктоп, явные ширина и высота, fetchpriority="high". Никакого lazy на этом изображении. После правок проверяем не «на глаз», а замером на типичном мобильном профиле.

Эпизод второй, «невидимая картинка». Условный сервис по аренде велосипедов собрал главную на React. Баннер с велосипедом вставляется компонентом после загрузки данных о ближайших точках. В исходном HTML картинки нет. Файл при этом небольшой и хорошо сжат, но браузер узнаёт о нём поздно, после выполнения скриптов и запроса к API. Длинная фаза — обнаружение. Лечение другое: вынести главное изображение в статическую разметку или в серверный рендер первого экрана, чтобы ссылка на файл была в первом ответе сервера. Сжатие тут почти не поможет, потому что проблема не в весе.

Эти два эпизода специально про разное. Одинаковый симптом «картинка появляется поздно» требует противоположных действий: в первом случае уменьшать и адаптировать файл, во втором — раньше о нём сообщать. Если перепутать, можно неделю сжимать изображение, которое и так лёгкое, и не сдвинуться.

Как отделить лабораторное измерение от полевого

Есть два разных взгляда на скорость. Лабораторный — когда вы запускаете аудиты в контролируемых условиях: фиксированное устройство, эмуляция сети, повторяемые прогоны. Он удобен для отладки и сравнения «до/после», потому что условия одинаковы. Полевой — когда собираются реальные данные от посетителей с их устройствами, сетями и поведением. Он показывает, что чувствуют люди, но шумит и зависит от того, кто именно зашёл.

Путать их опасно. Можно получить зелёный лабораторный отчёт и при этом терять мобильных посетителей на медленных сетях. И наоборот: полевые данные «плохие» из-за небольшой доли очень медленных устройств, а типичный пользователь доволен. Для задачи с изображением первого экрана разумно сначала воспроизвести проблему в лаборатории на профиле, похожем на вашу аудиторию, найти фазу, а потом подтвердить полевыми данными, что правка помогла реальным людям.

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

Изображение первого экрана на экране сотрудника

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

Хороший интерфейс загрузки делает правильное поведение лёгким, а неправильное — заметным. Показывайте требования к файлу рядом с полем: рекомендуемый формат, максимальный вес, соотношение сторон. После загрузки выводите фактический вес и размеры, а не только превью. Если файл заметно тяжелее нормы, предупреждайте до сохранения, а не после. Автоматически генерируйте набор размеров из одного исходника — тогда контент-менеджеру не нужно помнить про адаптивность.

Отдельно — подсказка о том, какое изображение на странице считается главным. Если в шаблоне первый экран занимает конкретное поле, назовите его понятно: «Изображение первого экрана (загружается первым, не откладывается)». Так человек поймёт, почему именно к этому полю особые требования, и не будет ставить сюда случайный тяжёлый файл «на пробу».

Изображение первого экрана: исключения и проверка условий

Не всё решается одинаково. Вот несколько случаев, где нужно думать, а не применять чек-лист вслепую.

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

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

Много изображений одного размера. Когда в первом экране сетка из нескольких одинаковых карточек, «главное» может меняться от прогона к прогону. Гоняться за каждым бессмысленно; разумнее выровнять вес и приоритеты всех кандидатов, чтобы ни один не тянул одеяло.

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

Сторонние виджеты. Чат, баннер или рекомендательный блок могут грузиться раньше вашей картинки и забирать канал. Проверьте, не конкурирует ли главное изображение с чужими скриптами, которые можно отложить.

Как проверить первый экран: пошаговый практикум

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

Шаг первый — определить кандидата. Откройте страницу на типичном для аудитории мобильном профиле и посмотрите, какой элемент браузер считает самым крупным в первом экране. Зафиксируйте это в карточке из раздела выше. Если кандидат — не то изображение, которое вы считали главным, разберитесь почему: возможно, оно обрезано или перекрыто.

Шаг второй — проверить обнаружение. Посмотрите исходный HTML: есть ли ссылка на файл в первом ответе сервера? Нет ли loading="lazy" на кандидате? Не выводится ли картинка через CSS-фон или скрипт? Это отвечает на вопрос, платите ли вы за позднее обнаружение.

Шаг третий — проверить вес и адаптивность. Какой файл реально скачивается на мобильном? Совпадает ли он с тем, что вы ожидали по srcset и sizes? Сколько он весит и в каком формате? Если телефон получает десктопный вариант — правьте набор размеров.

Шаг четвёртый — проверить размеры в разметке. Заданы ли ширина и высота (или соотношение сторон)? Прыгает ли вёрстка до появления картинки? Если да — резервируйте место.

Шаг пятый — проверить приоритеты. Сколько preload на странице? Все ли они нужны? Не конкурирует ли главное изображение с шрифтами и скриптами, которые можно отложить?

Шаг шестой — сравнить до и после. Сделайте замер в лаборатории на одном и том же профиле до правок и после, затем подтвердите полевыми данными. Не меняйте несколько вещей сразу, иначе не поймёте, что сработало.

Этот порядок важен: сначала обнаружение, потом вес, потом размеры и приоритеты. Если начать с сжатия, а проблема в скрытой за скриптом картинке, вы потратите время впустую.

Что сверить в документации, прежде чем что-то менять

Прежде чем править продакшен, полезно свериться с первоисточниками по конкретным механизмам. Материал web.dev об оптимизации LCP разбирает фазы и типичные причины задержек — удобно как карта для диагностики. Руководство MDN по адаптивным изображениям объясняет синтаксис srcset и sizes и то, как браузер выбирает вариант. Если изображение первого экрана важно и для поиска по картинкам, стоит заглянуть в рекомендации Google по изображениям — но это про индексацию и отображение в поиске, а не про скорость отрисовки, и путать эти задачи не стоит.

Один шаг, с которого стоит начать

Вся эта методика сводится к одной проверке, которую можно сделать сегодня. Откройте главную на типичном для вашей аудитории мобильном профиле, найдите изображение, которое браузер считает главным в первом экране, и ответьте на три вопроса: есть ли ссылка на него в исходном HTML, не стоит ли на нём lazy, и какой файл реально скачивается — мобильный или десктопный. Эти три ответа покажут, теряете ли вы на обнаружении, на весе или на обоих сразу, и избавят от слепой оптимизации всего подряд.

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

Смежный вопрос разобран отдельно: Кэширование сайта: быстро показать правильную версию.