1С-Bitrix Image Resize: Setup, Optimization & Speed

Imagine: an online store catalog on 1С-Bitrix with 10,000 products. Each product has an image of 4000×3000 pixels weighing 8 MB. Without resizing, these files are served in full on every request. The browser scales them via CSS, and you pay for extra gigabytes of traffic and lose visitors due to slow loading. Core Web Vitals suffer. The default Bitrix resizer is far from optimal — quality 85, GD, no pre-generation. We solve this problem comprehensively: choose the library, set parameters, configure caching and pre-generation. As a result, you save from 15,000 to 40,000 rubles per month on traffic for a catalog of 10,000 items.

Why the Default Resize Doesn't Work

Bitrix's built-in resize mechanism uses two APIs: the old CFile::ResizeImageFile() from the main module (via GD) and the new \Bitrix\Main\Web\Image (GD or Imagick). Both cache the result in bitrix/cache/resize_cache/. However, component parameters (e.g., DETAIL_IMAGE_WIDTH in bitrix:catalog.element) are often set to 0 — no resize occurs, the original is served. Even if parameters are set, GD with quality 85 is enabled by default, which is slow and suboptimal for large catalogs.

How to Choose Between GD and Imagick

Imagick is faster and higher quality. You can switch with one line or via the admin panel:

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

Check installation: php -r "echo extension_loaded('imagick') ? 'Imagick OK' : 'No Imagick';". On Bitrix VM Imagick is present, on plain PHP-FPM — apt install php-imagick or yum install php-imagick. More about Imagick advantages can be found on Wikipedia.

Setting Quality and Algorithm

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

82 for JPEG is a compromise between size and quality. For PNG, 7 out of 9.

Resize Modes and Their Application

In a component template:

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

When Do You Need Pre-generation of Previews?

On first user visit, resize is performed on the fly — causing CPU load and delay. Pre-generation via the OnAfterFileAdd event handler creates previews immediately after file upload:

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

Limits and Cache Cleanup

Resizing images over 30 MP requires memory_limit = 256M, max_execution_time = 60. For Imagick, also add imagick.skip_secure_multithreaded_extensions = 0.

The preview cache is not automatically cleared when a file is replaced. Safe cleanup by date:

// delete cache older than 30 days BXClearCache(true, '/'); 

An alternative is a script using find, but we prefer the programmatic approach.

How We Configure Resize: Process and Case Study

Our typical project — an online store with 50,000 products. Initial state: GD, quality 85, no pre-generation, catalog page load time 8 seconds. We did:

1. Audit current settings — memory_limit, driver, component parameters.
2. Enabled Imagick, set quality to 82.
3. Wrote a pre-generation handler for new files.
4. Updated component templates — set correct sizes and modes.
5. Configured an agent to clear stale cache once a week.
6. Tested — load time dropped to 2.5 seconds, traffic reduced by 65%.

What's Included in the Work

• Audit of current Bitrix and server configuration.
• Selection and activation of the optimal driver (GD/Imagick).
• Setting quality and resize modes for all components.
• Development and implementation of preview pre-generation.
• Optimization of PHP parameters (memory_limit, max_execution_time).
• Configuration of automatic cache cleanup.
• Documentation of all changes made.
• 12-month warranty on the settings.

Timeline and Pricing

Estimated timeline — from 2 to 5 working days depending on catalog size and template complexity. Pricing is calculated individually after an audit. Get a consultation — write to us, we'll evaluate your project.