Настройка ресайза изображений 1С-Битрикс

Настройка ресайза изображений 1С-Битрикс

Загруженное в Битрикс изображение 4000×3000 пикселей весом 8 МБ никуда не девается — оно лежит в upload/ и при каждом обращении без ресайза отдаётся целиком. Браузер масштабирует его через CSS. Итог: лишние мегабайты трафика, медленная загрузка, плохой Core Web Vitals. Встроенный ресайзер Битрикса решает это автоматически, но по умолчанию настроен далеко не оптимально.

Как работает ресайзер

Битрикс использует два API для работы с изображениями. Старый — CFile::ResizeImageFile() из модуля main, работает через GD. Новый — \Bitrix\Main\Web\Image, поддерживает GD и Imagick. Оба кешируют результаты в bitrix/cache/resize_cache/ по структуре [хеш-папки]/[имя-файла].[расширение].

Размеры превью задаются компонентами. В компоненте bitrix:catalog.element за размеры отвечают параметры DETAIL_IMAGE_WIDTH, DETAIL_IMAGE_HEIGHT, в bitrix:catalog.section — SECTION_IMAGE_WIDTH и т.д. Но у многих разработчиков эти параметры выставлены в 0 — ресайз не происходит.

Выбор библиотеки: GD vs Imagick

По умолчанию Битрикс использует GD. Imagick работает быстрее на больших изображениях и качественнее при уменьшении. Переключить можно в настройках модуля:

\Bitrix\Main\Config\Option::set('main', 'image_handler', 'imagick');

Или через административную панель: «Настройки» → «Настройки продукта» → «Производительность» → раздел «Изображения».

Проверка доступных драйверов:

php -r "echo extension_loaded('imagick') ? 'Imagick OK' : 'No Imagick';"
php -r "print_r(gd_info());"

На Bitrix VM Imagick установлен. На чистом PHP-FPM может отсутствовать — ставить через apt install php-imagick или yum install php-imagick.

Настройка качества и алгоритма

// Качество JPEG (по умолчанию 85)
\Bitrix\Main\Config\Option::set('main', 'image_resize_quality', '82');

// Алгоритм сжатия PNG (0-9, по умолчанию 6)
\Bitrix\Main\Config\Option::set('main', 'image_resize_png_quality', '7');

Значение 82 для JPEG — разумный компромисс. Ниже 75 артефакты заметны на фотографиях товаров. Выше 88 — файл растёт, визуальной разницы нет.

Режимы ресайза

Битрикс поддерживает несколько режимов через константы модуля main:

• BX_RESIZE_IMAGE_EXACT — точные размеры с обрезкой
• BX_RESIZE_IMAGE_PROPORTIONAL — пропорционально, вписывается в рамку
• BX_RESIZE_IMAGE_PROPORTIONAL_ALT — пропорционально, без белых полос

В шаблоне компонента вызов выглядит так:

$arFile = CFile::ResizeImageGet(
    $arResult['DETAIL_PICTURE'],
    ['width' => 800, 'height' => 600],
    BX_RESIZE_IMAGE_PROPORTIONAL,
    false
);

Четвёртый параметр false означает «не сохранять на диск» — вернуть URL к кешированной версии. Если передать true, файл будет скопирован в upload/resize_cache/ — полезно для предгенерации.

Предгенерация превью

Стандартная проблема: при первом входе пользователя на страницу ресайз происходит на лету — PHP тратит CPU, пользователь ждёт. Решение — прогрев кеша через скрипт или обработчик OnAfterFileAdd.

Обработчик события при добавлении файла:

// в /bitrix/php_interface/init.php
AddEventHandler('main', 'OnAfterFileAdd', function($arFields) {
    if (in_array($arFields['CONTENT_TYPE'], ['image/jpeg', 'image/png'])) {
        CFile::ResizeImageGet(
            $arFields['ID'],
            ['width' => 1200, 'height' => 900],
            BX_RESIZE_IMAGE_PROPORTIONAL
        );
        CFile::ResizeImageGet(
            $arFields['ID'],
            ['width' => 400, 'height' => 300],
            BX_RESIZE_IMAGE_PROPORTIONAL
        );
    }
});

Лимиты памяти и таймаут

Ресайз 30-мегапиксельного RAW в PHP требует до 256 МБ памяти. Стандартный memory_limit = 128M вызывает фатальную ошибку без записи в лог — страница просто не отдаёт изображение. Настройка в .htaccess или php.ini:

memory_limit = 256M
max_execution_time = 60

Для потокового ресайза через Imagick — поставить imagick.skip_secure_multithreaded_extensions = 0 в php.ini, это снимает лишние блокировки.

Очистка устаревшего кеша превью

Кеш ресайза не инвалидируется при изменении файла автоматически. Если заменили изображение товара через административный интерфейс — старое превью может отдаваться ещё часами. Битрикс при изменении записи в b_iblock_element_property удаляет запись из b_file, но физический файл в resize_cache/ не трогает.

Безопасная очистка только устаревших превью:

find /var/www/bitrix/bitrix/cache/resize_cache/ -mtime +30 -name "*.jpg" -delete
find /var/www/bitrix/bitrix/cache/resize_cache/ -mtime +30 -name "*.png" -delete

Полная очистка — через API, чтобы сбросить и файлы, и записи в b_cache_tag:

CBitrixComponent::clearComponentCache('bitrix:catalog.element');
BXClearCache(true, '/');