Покупатель открывает карточку товара, а главное изображение появляется через четыре секунды — на медленной мобильной сети и все шесть. За это время половина уходит. LCP на карточках товара — обычно самое слабое место магазина по скорости: страница тяжёлая, картинка крупная, вокруг неё гора скриптов. И именно карточка — это страница, на которой принимают решение о покупке.
Разберём, как оптимизировать Largest Contentful Paint на карточке товара в 1С-Битрикс: что является LCP-элементом, как ускорить загрузку главного изображения через preload и приоритеты, зачем WebP и AVIF, как использовать композитный сайт и не сломать всё ленивой загрузкой. Системно скорость мы поднимаем в рамках аудита и оптимизации проекта.
Коротко
- LCP-элемент карточки — почти всегда главное изображение товара; на нём и фокус оптимизации.
- Грузите главную картинку с высоким приоритетом (preload, fetchpriority=high), никакого lazy на ней.
- Отдавайте изображения в WebP/AVIF под нужный размер экрана через srcset — меньше вес, быстрее LCP.
- Композитный сайт отдаёт разметку мгновенно; сторонние скрипты откладывайте, чтобы не блокировать отрисовку.
Что такое LCP и почему он важен
Largest Contentful Paint — метрика Core Web Vitals, которая измеряет время до отрисовки самого крупного элемента контента в видимой области. Проще говоря, это момент, когда пользователь увидел главное на странице. Хорошим считается LCP до 2,5 секунды, плохим — свыше 4.
Для магазина LCP важен вдвойне. Во-первых, это фактор ранжирования: поисковики учитывают Core Web Vitals. Во-вторых, это прямая конверсия — чем дольше грузится карточка, тем больше людей уходят, не дождавшись. Карточка товара — конечная точка воронки, и её медлительность обходится дороже всего. Поэтому LCP карточек оптимизируют прицельно, отдельно от главной и каталога.
Что является LCP-элементом на карточке
Прежде чем оптимизировать, надо понять, что именно является LCP-элементом. На карточке товара кандидатов несколько, но чаще всего это главное изображение из галереи.
| Элемент | Насколько вероятно LCP | Что делать |
|---|---|---|
| Главное фото товара | Очень часто | Приоритет, preload, оптимизация формата |
| Крупный заголовок H1 | Иногда | Быстрый шрифт, без блокировки рендера |
| Баннер/промоблок | Редко | Оптимизировать как изображение |
| Блок цены крупным шрифтом | Редко | Не в динамике композита |
Определяют LCP-элемент инструментами измерения — они прямо показывают, какой элемент был засчитан. Дальше вся оптимизация фокусируется на нём: нет смысла ускорять то, что не влияет на метрику. В подавляющем большинстве случаев путь один — ускорить главное изображение товара.
Почему карточка товара тормозит
Карточка — самая нагруженная страница магазина, и причин медленного LCP много:
- Тяжёлое главное изображение. Крупное фото в неоптимизированном JPEG на несколько мегабайт.
- Галерея грузится целиком. Все изображения галереи загружаются сразу, конкурируя с главным.
- Скрипты в head. Синхронные скрипты аналитики и чатов блокируют отрисовку.
- Динамика без композита. Цена и наличие ждут ответа сервера, откладывая рендер.
- Нет приоритизации. Браузер не знает, что главная картинка важнее прочих ресурсов.
Понимание причин задаёт план: облегчить и приоритизировать главное изображение, отделить динамику, отсрочить второстепенное. Дальше пройдёмся по каждому рычагу.
Оптимизация главного изображения
Раз LCP-элемент — главное фото, начинают с него. Базовые меры:
- Правильный размер. Изображение генерируется под реальный размер отображения, а не отдаётся исходник 4000px, ужатый стилями.
- srcset и sizes. Несколько вариантов под разные ширины экрана, чтобы телефон не грузил десктопный размер.
- Сжатие. Разумное качество без визуальных потерь — вес падает без ущерба картинке.
- Явные размеры. width/height или aspect-ratio, чтобы место под картинку резервировалось и не было сдвигов (CLS).
В 1С-Битрикс изображения товаров ведутся в торговом каталоге, и ресайз удобно делать средствами платформы или на этапе обмена. Заранее подготовленные размеры избавляют от тяжёлых оригиналов на фронте. Это фундамент — без облегчённой картинки остальные приёмы дают меньше.
Preload и приоритеты загрузки
Даже лёгкую картинку браузер начнёт грузить не сразу — сначала он разбирает HTML и доходит до неё по очереди. Ускорить это помогают приоритеты:
- Preload главного изображения. Тег
<link rel="preload" as="image">в head заставляет браузер начать загрузку картинки заранее. - fetchpriority=high. Атрибут на теге img явно повышает приоритет главного фото над остальными ресурсами.
- Согласование с srcset. В preload указывают imagesrcset/imagesizes, чтобы предзагрузился именно нужный размер, а не лишний.
- Только LCP-элемент. Preload ставят на одну главную картинку, а не на всю галерею, иначе приоритеты размоются.
Эти приёмы часто дают самый заметный выигрыш по LCP при минимальных усилиях. Главное — не переусердствовать: если предзагружать всё подряд, приоритеты теряют смысл, и браузер снова не понимает, что важнее.
Форматы WebP и AVIF
Формат изображения напрямую влияет на вес, а вес — на LCP. Современные форматы WebP и AVIF дают то же визуальное качество при заметно меньшем размере файла, чем классический JPEG. Переход с тяжёлого JPEG на WebP нередко срезает вес картинки в разы, а AVIF сжимает ещё сильнее.
Отдавать современные форматы удобно через тег <picture> с несколькими источниками и фолбэком на JPEG для старых браузеров. В 1С-Битрикс конвертацию в WebP можно организовать на уровне обработки изображений или инфраструктуры. Важно, чтобы LCP-картинка отдавалась в лёгком формате — это один из самых недооценённых рычагов. Про инфраструктурную часть ускорения мы писали в статье про хостинг и BitrixVM.
Ленивая загрузка без вреда для LCP
Ленивая загрузка (loading="lazy") — отличный инструмент, но с одной оговоркой: её нельзя ставить на LCP-элемент. Если пометить главное изображение товара как lazy, браузер отложит его загрузку до последнего, и LCP резко ухудшится. Это одна из самых частых и обидных ошибок.
Правильная схема простая: главное фото грузится жадно и с высоким приоритетом (loading="eager", fetchpriority="high"), а всё, что ниже первого экрана — остальные фото галереи, блоки отзывов, рекомендации, — грузится лениво. Так первый экран отрисовывается быстро, а тяжёлый контент внизу не мешает. Баланс между жадной загрузкой главного и ленивой остального и есть суть оптимизации.
Композитный сайт и кэш карточки
Композитный сайт — штатный механизм Битрикс, который резко ускоряет отдачу страниц. Он кэширует статическую часть карточки и отдаёт её мгновенно из кэша, а динамические блоки (цена группы клиента, наличие по складу, корзина) догружает отдельным запросом. Для LCP это выгодно: разметка и место под главное изображение появляются сразу, и браузер раньше берётся за картинку.
Ключевой нюанс: LCP-картинка не должна оказаться в динамической части, которая ждёт ответа сервера. Главное изображение — в статике композита, а «плавающие» данные (персональная цена, остаток) — в догружаемой части. Тогда пользователь видит товар мгновенно, а цифры подтягиваются следом. Подробно про механику кэширования и композита — в статьях про кэш на Redis/Memcached и D7-ORM.
Критический CSS и порядок ресурсов
LCP страдает и от того, как загружаются стили и шрифты. Если весь CSS блокирует рендеринг, отрисовка главного элемента ждёт загрузки стилей. Приёмы, которые помогают:
- Критический CSS. Стили первого экрана инлайнят или грузят первыми, остальное — асинхронно.
- Шрифты без блокировки. font-display: swap и preload ключевых шрифтов, чтобы текст не ждал загрузки шрифта.
- Минимум блокирующих ресурсов в head. Всё, что не нужно для первого экрана, откладывается.
- Сжатие и HTTP/2. Ресурсы отдаются сжатыми, соединение переиспользуется.
Смысл прост: до момента отрисовки главного элемента браузер не должен тратить время на второстепенное. Чем меньше блокирующих ресурсов до LCP, тем раньше он наступает.
Сторонние скрипты и их отсрочка
Аналитика, чаты, виджеты рекомендаций, пиксели — всё это конкурирует за сеть и процессор с главным изображением. Особенно вредны синхронные скрипты в head: они блокируют разбор страницы и откладывают отрисовку. Правило — сторонние скрипты не должны стоять на пути LCP.
Практика: подключать сторонние скрипты с defer или async, а тяжёлые виджеты (чаты, рекомендации) инициализировать после взаимодействия пользователя или по таймауту после загрузки. Тогда карточка отрисовывается быстро, а «обвес» подгружается, когда покупатель уже видит товар. Это заметно улучшает LCP на реальных устройствах, где процессор слабее, чем в тесте.
Измерение LCP на реальных данных
Оптимизировать вслепую нельзя — нужно измерять. И важно различать лабораторные и полевые данные. Лабораторный тест показывает LCP в идеальных условиях, а полевые данные (RUM) — реальный опыт покупателей на их устройствах и сетях.
Для магазина смотрят 75-й перцентиль LCP отдельно по типу страницы «карточка товара»: главная и каталог могут быть быстрыми, а карточки — медленными. Измеряют до и после каждого изменения, чтобы видеть эффект. Такой прицельный замер показывает, что тормозит именно у покупателей, а не в синтетическом тесте на быстром канале. Про организацию надёжного деплоя изменений без регрессий — в статье про CI/CD на Битрикс.
Частые ошибки
- lazy на главном изображении. LCP-картинку помечают ленивой, и метрика рушится.
- Тяжёлый оригинал. Отдают изображение 4000px, ужатое стилями до 600px.
- Нет preload/priority. Браузер не знает, что главная картинка важнее, и грузит её в порядке очереди.
- Старый формат. Тяжёлый JPEG вместо WebP/AVIF.
- Синхронные скрипты в head. Аналитика и чаты блокируют отрисовку главного элемента.
- LCP в динамике композита. Главная картинка ждёт ответа сервера вместе с ценой и наличием.
- Замеряют только в лаборатории. Полевые данные по карточкам не смотрят, реальный опыт неизвестен.
Чек-лист внедрения
- LCP-элемент определён. Инструментами подтверждено, что это главное изображение товара.
- Картинка облегчена. Правильный размер, srcset/sizes, сжатие, явные width/height.
- Приоритет задан. Preload и fetchpriority=high для главного фото, eager вместо lazy.
- Современный формат. WebP/AVIF через picture с фолбэком.
- Остальное — лениво. Галерея, отзывы, рекомендации грузятся с loading=lazy.
- Композит настроен. Разметка и LCP-картинка в статике, динамика догружается отдельно.
- Скрипты отсрочены. Сторонние скрипты с defer/async или по взаимодействию.
- Замер на полевых данных. 75-й перцентиль LCP по карточкам отслеживается до и после.
Вывод
LCP на карточке товара почти всегда упирается в одно — скорость показа главного изображения. Определите LCP-элемент, облегчите картинку, отдайте её в WebP/AVIF нужного размера и грузите с высоким приоритетом через preload, а не лениво. Всё остальное на странице должно уступать ей дорогу.
Добавьте композитный сайт для мгновенной отдачи разметки, отсрочьте сторонние скрипты и измеряйте результат на реальных данных по карточкам. На 1С-Битрикс все эти рычаги доступны штатно и аккуратной доработкой — а быстрая карточка напрямую конвертируется в заказы и в позиции по Core Web Vitals.
