Налаштування ресайзу зображень у 1С-Бітрікс: оптимізація

Уявіть: в каталозі інтернет-магазину на 1С-Бітрікс 10 000 товарів. Кожен товар — зображення 4000×3000 пікселів вагою 8 МБ. Без ресайзу ці файли передаються повністю на кожен запит. Браузер масштабує їх через CSS, а ви платите за зайві гігабайти трафіку та втрачаєте відвідувачів через повільне завантаження. Core Web Vitals падають. А ресайзер Бітрікса за замовчуванням налаштований далеко не оптимально — якість 85, GD, без попередньої генерації. Ми вирішуємо цю проблему комплексно: підбираємо бібліотеку, виставляємо параметри, налаштовуємо кешування та попередню генерацію. У результаті ви економите від $150–400ів на місяць на трафіку для каталогу на 10 000 товарів.

Чому ресайз за замовчуванням не працює?

Вбудований механізм ресайзу Бітрікса використовує два API: старий CFile::ResizeImageFile() з модуля main (через GD) та новий \Bitrix\Main\Web\Image (GD або Imagick). Обидва кешують результат у bitrix/cache/resize_cache/. Однак часто параметри компонентів (наприклад, DETAIL_IMAGE_WIDTH в bitrix:catalog.element) встановлені в 0 — ресайз не відбувається, віддається оригінал. Навіть якщо параметри задані, за замовчуванням увімкнено GD з якістю 85, що для великих каталогів повільно та неоптимально.

Як вибрати між GD та Imagick?

Imagick працює швидше та якісніше. Переключити можна одним рядком або через адмін-панель:

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

Перевірити встановлення: php -r "echo extension_loaded('imagick') ? 'Imagick OK' : 'No Imagick';". На Bitrix VM Imagick є, на чистому PHP-FPM — apt install php-imagick або yum install php-imagick. Детальніше про переваги Imagick можна дізнатися на Wikipedia.

Налаштування якості та алгоритму

\Bitrix\Main\Config\Option::set('main', 'image_resize_quality', '82'); \Bitrix\Main\Config\Option::set('main', 'image_resize_png_quality', '7'); 

82 для JPEG — компроміс між розміром та якістю. Для PNG 7 з 9.

Режими ресайзу та їх застосування

У шаблоні компонента:

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

Коли потрібна попередня генерація прев'ю?

При першому вході користувача ресайз виконується на льоту — це навантаження на CPU та затримка. Попередня генерація через обробник події OnAfterFileAdd створює прев'ю одразу після завантаження файлу:

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+ МП вимагає memory_limit = 256M, max_execution_time = 60. Для Imagick додайте imagick.skip_secure_multithreaded_extensions = 0.

Кеш прев'ю не очищається автоматично при заміні файлу. Безпечне очищення за датою:

// видалення кешу старше 30 днів BXClearCache(true, '/'); 

Альтернатива — скрипт через find, але ми віддаємо перевагу програмному підходу.

Як ми налаштовуємо ресайз: процес та кейс

Наш типовий проект — інтернет-магазин з 50 000 товарів. Вихідно: GD, якість 85, без попередньої генерації, час завантаження сторінки каталогу 8 секунд. Ми виконали:

1. Аудит поточних налаштувань — memory_limit, драйвер, параметри компонентів.
2. Увімкнули Imagick, виставили якість 82.
3. Написали обробник попередньої генерації для нових файлів.
4. Оновили шаблони компонентів — вказали правильні розміри та режими.
5. Налаштували агента для очищення застарілого кешу раз на тиждень.
6. Протестували — час завантаження впав до 2.5 секунд, трафік зменшився на 65%.

Що входить у роботу

• Аудит поточної конфігурації Бітрікса та сервера.
• Вибір та активація оптимального драйвера (GD/Imagick).
• Налаштування якості, режимів ресайзу для всіх компонентів.
• Розробка та впровадження попередньої генерації прев'ю.
• Оптимізація параметрів PHP (memory_limit, max_execution_time).
• Налаштування автоматичного очищення кешу.
• Документація щодо внесених змін.
• Гарантія 12 місяців на налаштування.

Терміни та вартість

Орієнтовний термін — від 2 до 5 робочих днів залежно від обсягу каталогу та складності шаблонів. Вартість розраховується індивідуально після аудиту. Отримайте консультацію — напишіть нам, оцінимо проект.