Setting up image resizing in 1C-Bitrix

Our company is engaged in the development, support and maintenance of Bitrix and Bitrix24 solutions of any complexity. From simple one-page sites to complex online stores, CRM systems with 1C and telephony integration. The experience of developers is confirmed by certificates from the vendor.
Our competencies:
Development stages
Latest works
  • image_website-b2b-advance_0.png
    B2B ADVANCE company website development
    1175
  • image_bitrix-bitrix-24-1c_fixper_448_0.png
    Website development for FIXPER company
    811
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Development based on Bitrix, Bitrix24, 1C for the company Development of an Online Appointment Booking Widget for a Medical Center
    564
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Development based on 1C Enterprise for MIRSANBEL
    747
  • image_crm_dolbimby_434_0.webp
    Website development on CRM Bitrix24 for DOLBIMBY
    655
  • image_crm_technotorgcomplex_453_0.webp
    Development based on Bitrix24 for the company TECHNOTORGKOMPLEKS
    976

Image Resize Configuration in 1C-Bitrix

An image uploaded to Bitrix at 4000×3000 pixels weighing 8 MB doesn't disappear — it sits in upload/ and gets served in full on each request without resize. The browser scales it via CSS. Result: extra megabytes of traffic, slow loading, poor Core Web Vitals. Bitrix's built-in resizer solves this automatically, but by default is configured far from optimally.

How the Resizer Works

Bitrix uses two APIs for image work. The old — CFile::ResizeImageFile() from the main module, works via GD. The new — \Bitrix\Main\Web\Image, supports GD and Imagick. Both cache results in bitrix/cache/resize_cache/ by structure [hash-folder]/[filename].[extension].

Thumbnail sizes are set by components. In the bitrix:catalog.element component, DETAIL_IMAGE_WIDTH, DETAIL_IMAGE_HEIGHT control sizes; in bitrix:catalog.sectionSECTION_IMAGE_WIDTH etc. But many developers set these to 0 — no resize happens.

Choosing Library: GD vs Imagick

By default Bitrix uses GD. Imagick is faster on large images and higher quality when downscaling. Switch via module settings:

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

Or via admin panel: "Settings" → "Product Settings" → "Performance" → "Images" section.

Check available drivers:

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

On Bitrix VM Imagick is installed. On bare PHP-FPM may be missing — install via apt install php-imagick or yum install php-imagick.

Quality and Algorithm Configuration

// JPEG quality (default 85)
\Bitrix\Main\Config\Option::set('main', 'image_resize_quality', '82');

// PNG compression algorithm (0-9, default 6)
\Bitrix\Main\Config\Option::set('main', 'image_resize_png_quality', '7');

Value 82 for JPEG is a reasonable compromise. Below 75, artifacts are visible on product photos. Above 88, file grows but visual difference is none.

Resize Modes

Bitrix supports several modes via main module constants:

  • BX_RESIZE_IMAGE_EXACT — exact dimensions with crop
  • BX_RESIZE_IMAGE_PROPORTIONAL — proportional, fits in box
  • BX_RESIZE_IMAGE_PROPORTIONAL_ALT — proportional, no white bars

In component template the call looks like:

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

Fourth parameter false means "don't save to disk" — return URL to cached version. If true, file is copied to upload/resize_cache/ — useful for pre-generation.

Thumbnail Pre-Generation

Standard problem: on user's first page visit, resize happens on-the-fly — PHP spends CPU, user waits. Solution — warm cache via script or OnAfterFileAdd handler.

Event handler on file add:

// in /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
        );
    }
});

Memory Limits and Timeout

Resizing a 30-megapixel RAW in PHP requires up to 256 MB. Standard memory_limit = 128M causes fatal error without log write — page just won't serve image. Configure in .htaccess or php.ini:

memory_limit = 256M
max_execution_time = 60

For streaming Imagick resize — set imagick.skip_secure_multithreaded_extensions = 0 in php.ini, removes extra locks.

Clearing Outdated Thumbnail Cache

Resize cache isn't auto-invalidated on file change. If you replaced product image via admin — old thumbnail may serve for hours. Bitrix deletes b_file entry on property change, but doesn't touch physical file in resize_cache/.

Safe cleanup of only outdated thumbnails:

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

Full cleanup — via API to reset both files and b_cache_tag entries:

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