Изображения товаров в 1С-Битрикс: загрузка, обмен и оптимизация

Фотография — это то, по чему покупатель решает, стоит ли вообще открывать карточку. В интернет-магазине товар нельзя потрогать, поэтому картинка берёт на себя работу и продавца, и витрины: показывает, что это, в каком виде, с какими деталями. И одновременно фото — это самая тяжёлая часть страницы: именно изображения чаще всего раздувают вес каталога, роняют скорость и портят показатели Core Web Vitals. Получается вилка: картинки должны быть крупными и качественными, чтобы продавать, и лёгкими, чтобы быстро грузиться. Разрешается эта вилка не «на глаз», а настройками: ресайзом, форматами, ленивой загрузкой и грамотным обменом с 1С.

В этой статье разберём изображения товаров в 1С-Битрикс без общих слов: как система хранит картинки каталога, чем детальная картинка отличается от превью, как собрать галерею на свойстве «Больше фотографий» (MORE_PHOTO), как работает ресайз в Битрикс через CFile::ResizeImageGet и параметры компонентов, какие ставить размеры и качество, как отдавать WebP-товары и не проваливать LCP главного фото, как включить lazy-load и адаптивные srcset, как наложить водяной знак, как назвать файлы и прописать alt под SEO, как связать цвет торгового предложения с его фотографией, как массово загрузить фото из папки и по URL, и, главное, как настроить обмен картинок с 1С так, чтобы переносить только изменённые снимки и не затирать загруженные вручную. Материал — выжимка из наших внедрений по разработке каталога товаров на 1С-Битрикс, где работа с фото закладывается в основу витрины.

Почему фото товара — это деньги

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

Но у той же картинки есть обратная сторона — вес. На типичной странице каталога изображения занимают львиную долю всех байтов, которые грузит браузер. Если выводить тяжёлые оригиналы, страница будет открываться секундами, а поисковик зафиксирует плохие Core Web Vitals — в первую очередь LCP (время отрисовки самого крупного элемента, которым как раз обычно и является главное фото товара). Медленный каталог хуже ранжируется и хуже конвертирует одновременно.

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

Как Битрикс хранит изображения

Чтобы уверенно работать с картинками, важно понимать модель хранения. В 1С-Битрикс любой загруженный файл — не важно, фото товара, иконка раздела или картинка новости — регистрируется в единой таблице файлов (модуль «Главный», API — класс CFile). У файла есть числовой идентификатор, имя, размеры, физический путь на диске и служебные поля. Поля картинок элемента инфоблока (детальная и превью) хранят как раз такой идентификатор файла, а не «путь к картинке» напрямую.

Практических следствий из этого несколько:

• Один механизм на всё. Ресайз, водяные знаки, кэш уменьшенных копий работают одинаково для любых картинок, потому что все они проходят через CFile.
• Оригинал и копии — разные файлы. Когда вы просите превью 300×300 из фото 2000×2000, оригинал остаётся на месте, а рядом создаётся отдельный уменьшенный файл, который и отдаётся браузеру.
• Физически файлы лежат на диске. Оригиналы обычно хранятся в служебной папке загрузок (/upload/), уменьшенные копии — в подпапке ресайза. Это важно для бэкапов и переноса сайта.
• Удаление управляется ссылками. Файл, на который больше никто не ссылается, ядро умеет вычищать; но при неаккуратном обмене «осиротевшие» файлы могут накапливаться и раздувать диск.

Иными словами, картинка товара в Битриксе — это не просто «загруженный jpg», а запись в таблице файлов плюс набор порождённых из неё уменьшенных копий. Понимание этой связки объясняет почти всё дальнейшее: и как работает ресайз, и почему WebP отдаётся отдельным файлом, и откуда берётся вес папки /upload/.

Детальная картинка и превью

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

Превью (PREVIEW_PICTURE)

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

Детальная картинка (DETAIL_PICTURE)

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

Как их обычно заполняют

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

Галерея: свойство «Больше фотографий» (MORE_PHOTO)

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

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

Как галерея собирается в карточке:

• Главное фото — детальная картинка (DETAIL_PICTURE) — становится первым, активным кадром.
• Остальные кадры — значения свойства MORE_PHOTO — идут миниатюрами под главным фото.
• Клик по миниатюре меняет активное большое изображение; часто добавляют зум и просмотр в модальном окне.
• Порядок снимков в галерее задаётся порядком значений множественного свойства — им можно управлять при загрузке.

Штатный компонент детального просмотра bitrix:catalog.element умеет всё это «из коробки»: в его параметрах указывают, какое свойство считать галереей (по умолчанию как раз MORE_PHOTO), и он выводит связку «большое фото + миниатюры» со сменой кадра. Разработчику остаётся оформить это по дизайну и, при необходимости, подключить библиотеку зума/слайдера.

Ресайз: CFile::ResizeImageGet и компоненты

Мы уже несколько раз сказали «ресайз» — разберём, что это технически. Ресайз — это создание из оригинала уменьшенной (или вписанной в заданные габариты) копии нужного размера. В Битриксе за это отвечает метод ядра CFile::ResizeImageGet. Он берёт файл по идентификатору, создаёт копию под заданные ширину и высоту, кэширует её на диске и возвращает путь к готовой уменьшенной картинке.

У метода есть режимы вписывания, и выбор режима — важное решение для аккуратной витрины:

Самое важное на практике: вручную ResizeImageGet вызывать приходится редко. В подавляющем большинстве случаев ресайзом управляют параметры компонентов каталога. Когда вы в настройках bitrix:catalog.section (список товаров) или bitrix:catalog.element (карточка) задаёте ширину и высоту изображений превью и детальной, компонент под капотом сам вызывает ResizeImageGet с этими габаритами и выбранным режимом. То есть «настроить ресайз» для контент-менеджера и интегратора — это чаще всего «задать размеры картинок в параметрах компонента», а не писать код.

Прямой вызов метода нужен, когда картинку выводят в нестандартном месте (кастомный блок, письмо, выгрузка), где нет готового компонента. Тогда в шаблоне вызывают CFile::ResizeImageGet с нужными размерами, режимом и, при необходимости, водяным знаком, и подставляют полученный путь в тег изображения.

Какие размеры превью и детальных задавать

Частый вопрос — «какие пиксели ставить». Универсального числа нет, но есть рабочая логика: размер уменьшенной копии задают под реальный размер места на странице, где картинка показывается, с запасом на дисплеи высокой плотности (Retina).

Ход рассуждения такой:

1. Померить место вывода. Посмотреть в макете, какого размера плитка товара, миниатюра галереи, главное фото карточки в пикселях на десктопе и на мобильном.
2. Заложить плотность экрана. Для чёткости на Retina-экранах уменьшенную копию делают крупнее места вывода (ориентировочно в полтора-два раза), чтобы картинка не была мыльной.
3. Не переусердствовать. Отдавать фото 2000×2000 в плитку 300×300 бессмысленно — это тот самый тяжёлый оригинал на витрине, который убивает скорость.
4. Согласовать с адаптивом. Для мобильного и десктопа готовят разные размеры и отдают их через srcset (об этом ниже), а не грузят один большой файл на всех.

Ориентировочная раскладка, от которой удобно отталкиваться (точные числа подгоняют под макет):

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

Качество и вес: настройка JPEG

Размер в пикселях — не единственный рычаг веса. Второй — качество сжатия. Для JPEG качество задаётся числом (условно от 0 до 100 процентов): чем выше, тем меньше артефактов сжатия, но тем тяжелее файл. В Битриксе качество ресайза настраивается глобально (в настройках модуля «Загрузка файлов») и может переопределяться в параметрах ресайза.

Практические ориентиры:

• Рабочий диапазон — примерно 80–85 процентов. В этом коридоре разница с «максимальным» качеством почти незаметна глазу, а вес заметно ниже.
• Выше 90 процентов — обычно перебор. Файл тяжелеет ощутимо, визуальной пользы почти нет.
• Ниже 70 процентов — рискованно. На фото товара появляются заметные артефакты, особенно на однотонных фонах и градиентах, — это уже вредит восприятию.
• Для миниатюр можно жёстче. Маленькие превью терпят более сильное сжатие, чем крупное фото на карточке.

Важно понимать взаимосвязь: итоговый вес картинки складывается из размера в пикселях и качества сжатия и формата. Нельзя вытянуть скорость только качеством, если при этом в плитку 300×300 отдаётся копия 1500×1500. Сначала правильный размер под место, потом разумное качество, потом современный формат — в такой последовательности рычаги дают максимум эффекта.

WebP и скорость: LCP главного фото

Третий рычаг веса — формат. Классический JPEG хорош, но существуют современные форматы, которые при том же визуальном качестве весят заметно меньше. Главный из них для интернет-магазина — WebP. Перевод картинок каталога в WebP — одна из самых результативных мер по скорости, потому что изображения — основная масса байтов страницы.

Как это устроено на практике:

• WebP отдаётся браузерам, которые его понимают. Современные браузеры поддерживают формат; для остальных нужен запасной JPEG. Реализуют это тегом <picture> с несколькими <source> или на уровне сервера/CDN, который сам отдаёт WebP по заголовку Accept.
• Копии генерируются, как и обычный ресайз. Рядом с JPEG-копией кладётся WebP-версия того же размера, и в разметку подставляется нужный вариант.
• Оригинал остаётся исходным форматом. WebP — это формат отдачи уменьшенных копий, а не хранения мастер-файла.

Отдельно про LCP главного фото

LCP (Largest Contentful Paint) — метрика Core Web Vitals, измеряющая, когда отрисовывается самый крупный элемент экрана. На карточке товара это почти всегда главное детальное фото. Значит, именно от его веса и способа загрузки напрямую зависит, «зелёный» у вас LCP или нет. Отсюда практические правила по главному фото:

• Не откладывать его в lazy-load. Ленивая загрузка полезна для картинок ниже экрана, но главное фото карточки в первом экране грузят сразу, иначе LCP проседает.
• Наоборот, повысить приоритет. Главному фото задают приоритетную загрузку (атрибут fetchpriority="high"), чтобы браузер тянул его первым.
• Отдать в WebP и в точном размере. LCP-картинку особенно важно не раздувать: правильный размер плюс WebP дают самый быстрый рендер.
• Указать размеры. У тега изображения проставляют width и height (или CSS-размеры), чтобы не было скачка вёрстки (CLS) при загрузке.

Связь фото и Core Web Vitals мы подробно разбираем в отдельном материале про Core Web Vitals интернет-магазина, а общий подход к разгону витрины — в услуге по ускорению сайта на 1С-Битрикс.

Lazy-load и адаптивные картинки (srcset)

Две браузерные техники дают львиную долю ускорения каталога почти бесплатно: ленивая загрузка и адаптивные изображения.

Lazy-load (ленивая загрузка)

Идея простая: не грузить картинки, которых пользователь пока не видит. На странице каталога с десятками товаров браузер по умолчанию тянет все изображения сразу, хотя ниже первого экрана их ещё не видно. Атрибут loading="lazy" на теге изображения говорит браузеру подгружать картинку только по мере прокрутки к ней. Это резко снижает объём загрузки при открытии страницы и ускоряет первый экран. Единственное исключение — картинки первого экрана и, в частности, LCP-фото карточки: их в lazy не отправляют.

Адаптивные картинки (srcset)

Вторая техника — отдавать разным экранам разные размеры одной картинки. Для этого в теге изображения используют атрибут srcset (набор вариантов разного размера) и sizes (подсказка, какого размера место на текущем экране). Браузер сам выбирает подходящий файл: телефону отдаётся маленькая копия, десктопу с Retina — крупная. Без этого мобильный пользователь скачивает десктопные размеры и зря тратит трафик и время.

Что это даёт вместе:

• Меньше байтов при открытии — грузится только видимое (lazy) и только нужного размера (srcset).
• Быстрее первый экран и лучше LCP — браузер не отвлекается на невидимые и негабаритные картинки.
• Экономия мобильного трафика — телефон не тянет десктопные изображения.
• Совместимость со всем — это стандартные атрибуты, работают везде без библиотек.

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

Водяные знаки на картинках

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

Как это работает: при генерации уменьшенной копии в параметры ресайза передаётся описание водяного знака. Знаком может быть:

• Картинка-логотип (обычно полупрозрачный PNG) — накладывается в заданном месте кадра.
• Текст — например, адрес сайта; задаётся шрифт, размер, цвет, прозрачность.

Настраивают положение (угол или центр), прозрачность и отступы. Практические правила, которые мы соблюдаем:

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

Alt и имена файлов для SEO

Картинки товаров — это ещё и источник трафика из поиска по картинкам, и фактор доступности. Две вещи, которые прямо влияют на SEO изображений, — атрибут alt и имя файла.

Атрибут alt

alt — это текстовое описание картинки. Его читают программы экранного доступа (доступность для незрячих) и поисковые роботы (понимание, что на фото). Хороший alt для товара — это осмысленное описание с названием товара, а не пустая строка и не «фото1». В Битриксе alt можно брать из специальных полей картинки (описание файла) или формировать в шаблоне из названия товара и характеристик. Главное — чтобы alt был осмысленным и не спамным: описывайте, что на фото, естественным языком.

Имена файлов

Имя файла картинки тоже участвует в ранжировании и в целом влияет на «чистоту» каталога. smartphone-samsung-galaxy-black.webp лучше, чем IMG_20230617_0042.jpg. Осмысленные латинские имена файлов (транслит названия товара) помогают поиску по картинкам и делают выгрузки понятнее. При массовой загрузке и обмене имена часто задаются автоматически — стоит проследить, чтобы схема именования была осмысленной, а не случайной.

Оба фактора — alt и имена — это часть более широкой темы оптимизации картинок под поиск. Полный разбор с приоритетами и нюансами мы вынесли в отдельную статью про оптимизацию изображений под SEO в 1С-Битрикс; здесь фиксируем: осмысленный alt и человеческие имена файлов — обязательный минимум для каждого фото каталога.

Зум и мобильная галерея

Галерея — это не только набор картинок, но и способ их рассматривать. Два ключевых сценария — зум на десктопе и свайп на мобильном.

Зум

Зум позволяет разглядеть детали: фактуру ткани, разъёмы, надписи. Реализуют его по-разному: увеличение области под курсором при наведении, открытие крупной версии в модальном окне по клику, отдельная «лупа». Важный момент для скорости: крупную версию под зум грузят по действию пользователя (навёл/кликнул), а не сразу при открытии карточки. Иначе тяжёлый оригинал утянет вес страницы, хотя большинство посетителей зумом не пользуются.

Мобильная галерея

На телефоне галерея работает иначе: вместо миниатюр сбоку — свайп между кадрами и точки-индикаторы снизу. Требования к мобильной галерее:

• Свайп и крупные тапабельные зоны — палец, а не курсор.
• Лёгкие кадры под мобильный размер — через srcset, чтобы не грузить десктопные копии.
• Первый кадр — приоритетный (LCP), остальные подгружаются по мере пролистывания.
• Зум по двойному тапу или пинчу — привычный жест на мобильном.

Технически зум и слайдер обычно подключают лёгкой JS-библиотекой поверх штатной галереи catalog.element. Главное — не превращать красивую галерею в тормоз: тяжёлые версии грузить лениво и по действию, а первый кадр держать лёгким и приоритетным.

Видео товара

Фотографий часто мало — сложный или дорогой товар выигрывает от видео: обзор, распаковка, товар в действии. В Битриксе видео к товару добавляют несколькими способами, и выбор влияет на скорость.

• Встраивание с внешней площадки (YouTube и аналоги). Самый частый и лёгкий для сервера путь: в свойство товара кладут ссылку/код видео, а карточка выводит плеер площадки. Видео при этом не грузит ваш сервер и не занимает диск.
• Загрузка видеофайла в свойство. Заводят свойство типа «Файл» под видео и хранят ролик у себя. Полный контроль, но файлы тяжёлые: нужен нормальный хостинг отдачи и, желательно, CDN.
• Видео как элемент галереи. Продвинутые шаблоны показывают видео прямо в галерее рядом с фото — как ещё один «кадр» с иконкой воспроизведения.

Ключевое правило скорости для видео такое же, как для зума: плеер и тяжёлый ролик подгружают по клику, а не при открытии карточки. До клика показывают лёгкую превью-картинку (постер) с кнопкой воспроизведения. Иначе автозагрузка видео убьёт и скорость, и мобильный трафик. Видео — сильный инструмент для конверсии, но обращаться с ним нужно так же аккуратно по весу, как и с фото.

Картинки торговых предложений: цвет → фото

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

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

Логика вывода:

1. У каждого SKU — свои фото. В детальную картинку (и галерею) предложения «синий» загружают снимки синего варианта, в «чёрный» — чёрного.
2. Компонент связывает выбор и галерею. В параметрах bitrix:catalog.element указывают, какие свойства предложений участвуют в выборе и что для них берутся собственные изображения.
3. Переключение меняет кадры. Покупатель кликает по цвету — карточка подставляет галерею выбранного предложения.
4. Запасной вариант. Если у конкретного предложения своих фото нет, показывают изображения родительского товара, чтобы место не оставалось пустым.

Здесь легко попасть в две крайности. Первая — не загрузить фото вариантам вовсе, и тогда при выборе цвета картинка не меняется (покупатель путается). Вторая — грузить полный набор фото каждому варианту, раздувая каталог и обмен. Разумный баланс: своему цвету — один-два ключевых кадра, а общие ракурсы (упаковка, детали) держать у родительского товара. Подробно про саму механику вариантов — в статье про торговые предложения (SKU) в 1С-Битрикс.

Массовая загрузка: из папки и по URL

Когда товаров сотни и тысячи, загружать фото по одному через карточку невозможно. Нужны массовые способы. Основных — три.

Несколько практических моментов, которые экономят часы:

• Стабильный ключ сопоставления. Чтобы связать фото и товар, нужен надёжный общий ключ — артикул или внешний код. Имена файлов и колонки в фиде строят вокруг него.
• Несколько фото на товар. Для галереи используют схему именования с суффиксом: art123-1.jpg, art123-2.jpg — первый в детальную, остальные в MORE_PHOTO.
• Проверка при загрузке по URL. Ссылки бывают битые или ведут на «заглушку»; массовую загрузку по URL сопровождают логом ошибок, чтобы поймать товары без фото.
• Не забыть про ресайз и вес. Массово залитые оригиналы от поставщика бывают огромными — после импорта важно, чтобы на витрину шли ресайзнутые копии, а не эти оригиналы.

В большинстве магазинов, впрочем, основным каналом поступления фото становится не разовый импорт, а регулярный обмен с 1С — к нему и переходим.

Обмен картинок с 1С по CommerceML

Стандартный способ наполнения каталога на Битриксе — обмен с 1С по протоколу CommerceML (коммерческая информация). Через него передаются товары, цены, остатки — и изображения. Разберём, как именно фото попадают из 1С на сайт.

При выгрузке 1С формирует пакет обмена: XML-файлы с описанием товаров и папку с картинками. В XML для каждого товара указаны имена его файлов изображений, а сами файлы лежат в пакете. На стороне сайта агент обмена принимает пакет, разбирает XML и для каждого товара загружает его картинки в поля инфоблока: первое изображение обычно попадает в детальную картинку, остальные — в множественное свойство галереи (MORE_PHOTO). Товары сопоставляются с элементами по внешнему коду (XML_ID), поэтому фото «прилипают» к нужному товару даже при переносе.

Что здесь важно понимать:

• Источник картинок — 1С. При таком обмене мастер-данные по фото живут в учётной системе, а сайт их принимает. Это удобно для автоматизации, но накладывает ограничения (см. следующий раздел про перезапись).
• Первое фото — детальное, остальные — галерея. Порядок картинок в 1С определяет, что станет главным фото, а что — дополнительными кадрами.
• Сопоставление по XML_ID. Стабильный внешний код — залог того, что фото не «разъедутся» по товарам и обмен будет предсказуем.
• Вес пакета. Картинки — самая тяжёлая часть выгрузки; если гонять их целиком каждый раз, обмен становится долгим и нагружает и 1С, и сайт, и канал.

Последний пункт — ключевая боль крупных каталогов, и ей посвящён отдельный раздел.

Только изменённые: не гонять всё каждый раз

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

Подходы, которыми этого добиваются:

• Инкрементальная (пошаговая) выгрузка из 1С. 1С настраивают так, чтобы в очередной пакет попадали только товары, у которых что-то поменялось с прошлого обмена, — и их картинки. Полная выгрузка остаётся редкой процедурой (первичная загрузка, ручная пересборка).
• Сравнение на стороне сайта. Обработчик обмена сверяет пришедшее фото с уже загруженным (по имени, размеру, контрольной сумме/хэшу или дате) и обновляет картинку только если она реально изменилась, а идентичную — пропускает.
• Признак изменения в пакете. В некоторых схемах 1С помечает, менялись ли изображения товара, и сайт грузит их только по этому признаку.

Обратная сторона: перезапись ручных фото

У обмена картинок есть коварная проблема, о которую спотыкаются очень многие: обмен затирает загруженные вручную фото. Сценарий такой. Менеджер добавил красивые снимки товара прямо на сайте. В 1С этих фото нет. Приходит очередной обмен — и стандартная логика переустанавливает изображения товара из пакета 1С, где фото либо старые, либо вообще отсутствуют. Ручные снимки пропадают. Обиднее всего, что происходит это молча и обнаруживается не сразу.

Как это предотвращают:

1. Определить единый источник правды по фото. Либо все изображения живут только в 1С (тогда и добавляют их там), либо только на сайте (тогда обмен вообще не трогает картинки). Смешанная схема без правил — источник затираний.
2. Хранить ручные фото в отдельном свойстве. Завести свойство под «сайтовые» изображения, которое обмен не переустанавливает, и выводить галерею из обоих источников. Обмен обновляет «свои» фото, ручные остаются нетронутыми.
3. Доработать обработчик обмена. Настроить логику так, чтобы обмен не очищал изображения товара, если в пакете для него картинок нет, и не перезаписывал те, что не менялись.
4. Зафиксировать правило в регламенте. Договориться с контент-командой, где заводятся фото, чтобы не создавать конфликт между ручной загрузкой и обменом.

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

Хранение, вес и CDN

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

Где и сколько весит

Оригиналы фото лежат в папке загрузок (/upload/), уменьшенные копии — в подпапке ресайза, WebP-версии — отдельными файлами. В каталоге на десятки тысяч товаров с галереями это легко десятки гигабайт. Отсюда практические заботы:

• Бэкапы и перенос. Папку загрузок нужно бэкапить и учитывать при переезде — это часто самая тяжёлая часть сайта.
• «Осиротевшие» файлы. При неаккуратном обмене и удалении товаров на диске копятся картинки, на которые никто не ссылается. Их периодически чистят, чтобы не раздувать хранилище.
• Кэш ресайза. Папка уменьшенных копий растёт со временем; её тоже контролируют и при необходимости пересобирают (например, после смены размеров или водяного знака).

CDN — сеть доставки контента

Для крупного каталога отдачу картинок выносят на CDN — сеть серверов, раздающих статику с узла, ближайшего к посетителю. Что это даёт:

• Скорость по географии. Картинка едет к пользователю с близкого узла, а не с единственного сервера магазина.
• Разгрузка сервера. Отдача тяжёлой статики уходит с основного сервера — ему остаётся генерация страниц.
• Автоматическая оптимизация. Многие CDN сами конвертируют картинки в WebP и сжимают их «на лету».
• Кэш и заголовки. Правильные заголовки кэширования на картинках — половина эффекта; CDN помогает это выстроить.

При этом CDN — не обязательная мера для всех. Небольшому магазину достаточно грамотного ресайза, WebP, кэша и корректных заголовков кэширования на своём сервере. CDN становится оправдан, когда картинок очень много, аудитория распределена географически и отдача статики заметно нагружает сервер. Общий разгон витрины, включая работу со статикой, мы выносим в услугу по ускорению сайта на 1С-Битрикс.

Пошагово: настраиваем изображения каталога

Сведём всё в практическую последовательность — так мы настраиваем работу с фото на реальных проектах, от полей инфоблока до обмена и скорости.

1. Проверить поля и свойства. У инфоблока товаров должны быть детальная картинка, превью и множественное свойство «Больше фотографий» (MORE_PHOTO). При наличии вариантов — поля картинок у торговых предложений.
2. Задать правила исходников. Договориться о едином формате мастер-фото (например, квадрат на белом фоне, высокое качество) и порядке кадров в галерее.
3. Настроить ресайз в компонентах. В параметрах catalog.section и catalog.element задать размеры превью, детальной и миниатюр под реальные места вывода с запасом на Retina; выбрать режим вписывания.
4. Выставить качество. Задать качество ресайза около 80–85 процентов; оригиналы держать качественными.
5. Включить WebP. Настроить отдачу WebP с запасным JPEG (через <picture> или на уровне сервера/CDN).
6. Добавить lazy-load и srcset. В шаблонах вывода картинок проставить loading="lazy" для изображений ниже экрана и сформировать srcset под мобильный и десктоп.
7. Приоритизировать LCP-фото. Главное фото карточки вывести без lazy, с fetchpriority="high", заданными размерами и в WebP.
8. Настроить водяной знак. Если нужен — наложить на ресайзнутые копии, подобрать положение и прозрачность, не закрывая товар.
9. Прописать alt и имена файлов. Настроить формирование осмысленных alt из названия товара и человеческие имена файлов.
10. Подключить галерею, зум и видео. Оформить галерею из детальной + MORE_PHOTO, зум и мобильный свайп; тяжёлые версии и видео грузить по действию.
11. Настроить обмен картинок. Определить источник правды по фото; включить перенос только изменённых; защитить ручные фото от затирания; сопоставление по XML_ID.
12. Проверить вес и кэш. Убедиться, что на витрину идут копии, а не оригиналы; настроить заголовки кэширования; при большом каталоге рассмотреть CDN.

Как видно, «загрузить фото» — лишь малая часть работы. Основное — это ресайз, форматы, ленивая загрузка, приоритет LCP и грамотный обмен. Именно эти настройки отличают каталог, который и продаёт, и быстро грузится, от красивого, но неповоротливого.

Реализация в компонентах и API

Соберём в одном месте, какими средствами Битрикса реализуется всё описанное, — чтобы было понятно, что где настраивается.

Отдельно про типовой сценарий в коде. Когда картинку выводят стандартным компонентом, размеры и режим ресайза берутся из его параметров — писать код не нужно. Когда фото выводят в нестандартном месте (кастомный блок, письмо, выгрузка), в шаблоне напрямую вызывают CFile::ResizeImageGet с идентификатором файла, нужными габаритами, режимом вписывания и — при необходимости — описанием водяного знака, а полученный путь подставляют в тег изображения вместе с alt, loading и srcset. Таким образом, вся работа с картинками собирается из одного механизма файлов и ресайза, а задача разработчика — правильно задать размеры под места вывода, форматы и поведение загрузки.

Частые ошибки

• Тяжёлые оригиналы на витрине. В плитку или карточку отдают фото 2000×2000 и масштабируют его браузером. Страница весит мегабайты и медленно грузится. Лечится ресайзом до реального размера места вывода.
• Обмен затирает ручные фото. Загруженные на сайте снимки пропадают после выгрузки из 1С. Решают единым источником правды, отдельным свойством под ручные фото и настройкой обработчика.
• Гоняют все картинки каждый обмен. Полная выгрузка изображений при каждом обмене делает его многочасовым. Нужен перенос только изменённых (инкремент, сравнение по хэшу).
• Главное фото в lazy-load. LCP-картинку откладывают ленивой загрузкой, и метрика проседает. Главное фото карточки грузят сразу и с высоким приоритетом.
• Нет WebP. Каталог отдаёт только тяжёлый JPEG, хотя WebP при том же качестве заметно легче. Настраивают отдачу WebP с запасным JPEG.
• Пустые или мусорные alt. Атрибут alt отсутствует, пуст или содержит «фото1». Теряется трафик из поиска по картинкам и доступность. Alt делают осмысленным из названия товара.
• Разноформатные исходники. Фото разного соотношения сторон дают «прыгающую» витрину. Договариваются о едином формате и режиме ресайза.
• Нет фото у вариантов. При выборе цвета торгового предложения картинка не меняется. Загружают ключевые кадры каждому SKU, остальное — у родительского товара.
• Водяной знак на оригиналах. Знак «вжигают» в мастер-файлы, и заменить логотип потом не из чего. Накладывают знак на ресайзнутые копии, оригиналы держат чистыми.
• Автозагрузка тяжёлого видео. Ролик или плеер грузятся при открытии карточки. Показывают лёгкий постер, а плеер и видео подгружают по клику.
• «Осиротевшие» файлы копятся. После удаления товаров и обменов на диске остаются картинки без ссылок, раздувая хранилище. Периодически чистят и контролируют папку загрузок.

Чек-лист по изображениям товаров

Сведём в практический список то, что проверяют при настройке и приёмке работы с фото каталога.

1. Поля на месте. Есть детальная, превью и множественное свойство «Больше фотографий» (MORE_PHOTO); у вариантов — свои картинки.
2. На витрине — копии, не оригиналы. Везде выводятся ресайзнутые изображения под размер места, а не тяжёлые исходники.
3. Размеры под места вывода. Плитка, миниатюра, главное фото имеют разумные размеры с запасом на Retina.
4. Качество настроено. Ресайз около 80–85 процентов; оригиналы качественные и чистые (без водяного знака).
5. WebP включён. Картинки отдаются в WebP с запасным JPEG.
6. Lazy-load и srcset. Изображения ниже экрана ленивые; отдаются размеры под устройство.
7. LCP-фото приоритетно. Главное фото карточки без lazy, с высоким приоритетом, в WebP, с заданными размерами.
8. Alt и имена файлов. У каждого фото осмысленный alt; имена файлов человеческие и латинские.
9. Галерея, зум, видео. Галерея собирается корректно; зум и тяжёлое видео грузятся по действию; на мобильном работает свайп.
10. Обмен под контролем. Определён источник правды по фото; переносятся только изменённые; ручные фото не затираются; сопоставление по XML_ID.
11. Вес и кэш. Настроены заголовки кэширования; папка загрузок под контролем; при большом каталоге рассмотрен CDN.

Вывод

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

Практических выводов три. Первый: на витрину никогда не отдают оригиналы — только ресайзнутые копии нужного размера и в современном формате. Второй: главное фото карточки — это ваш LCP, и обращаться с ним нужно как с самым важным элементом страницы: грузить сразу, приоритетно и в WebP. Третий: обмен картинок с 1С настраивают осознанно — переносить только изменённые фото и защищать загруженные вручную снимки от затирания, заранее решив, где живёт «мастер» изображений. Сделайте это аккуратно — и каталог будет и красивым, и быстрым одновременно. А если работу с фото нужно выстроить с нуля или разобрать существующий каталог, мы помогаем с этим в рамках разработки каталога товаров на 1С-Битрикс и ускорения интернет-магазина. Больше разборов по теме — в рубрике «Каталог и поиск».