Налаштування ресайзу зображень 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, '/');