WebP Image Conversion Configuration in 1C-Bitrix
A typical e-commerce catalog page in Bitrix loads 40–80 images. JPEG and PNG combined weigh 2–5 MB — causing delay on mobile connections. WebP at comparable quality provides 25–35% size advantage. The problem is that "enabling WebP" in Bitrix isn't a single button, but a combination of mechanisms, each of which can silently fail.
How Bitrix Processes Images
The core uses the main module (class CFile) for file storage and the resize_image module for thumbnail generation. The resizer is called via \Bitrix\Main\Web\Image or the legacy API CFile::ResizeImageFile(). Results are cached in bitrix/cache/resize_cache/ with hashed folder names.
WebP conversion in Bitrix is implemented via two paths:
Path 1 — server-side conversion via PHP. GD or Imagick library converts during resize. Configured in bitrix/php_interface/dbconn.php or via admin interface in "Performance" section.
Path 2 — conversion at web server level. Nginx/Apache serves .webp version instead of original if browser supports the format (header Accept: image/webp). Files are converted in advance — via script or daemon.
Server-Side Conversion Configuration
Check GD and Imagick
php -r "echo gd_info()['WebP Support'] ? 'WebP OK' : 'WebP NOT supported';"
php -r "echo (new Imagick())->queryFormats('WEBP') ? 'Imagick WebP OK' : 'fail';"
If GD is built without WebP — install libwebp-dev and rebuild, or switch to Imagick. On Bitrix VM there are usually no issues — Imagick with WebP is included.
Bitrix Configuration
In file /bitrix/php_interface/dbconn.php add:
define("BX_USE_MYSQLI", true);
define("CACHED_b_file", 3600);
Enable WebP in the main module:
\Bitrix\Main\Config\Option::set('main', 'use_webp', 'Y');
\Bitrix\Main\Config\Option::set('main', 'webp_quality', '85');
After this, \Bitrix\Main\Web\Image::resize() will return .webp if client supports the format. Check in the b_file table — the CONTENT_TYPE field for new thumbnails should be image/webp.
Conversion at Nginx Level
This is more efficient: PHP doesn't spend CPU on conversion during request. Scheme: on first request generate .webp version next to original, Nginx checks its presence and serves if browser supports it.
map $http_accept $webp_suffix {
default "";
"~*webp" ".webp";
}
server {
location ~* ^/upload/.*\.(png|jpg|jpeg)$ {
add_header Vary Accept;
try_files $uri$webp_suffix $uri =404;
}
}
Pre-convert with cwebp script:
find /var/www/bitrix/upload -name "*.jpg" -o -name "*.png" | \
xargs -P4 -I{} sh -c 'cwebp -q 82 "$1" -o "$1.webp" 2>/dev/null' _ {}
Run via cron hourly for new files — check modification date via find -newer.
Thumbnail Cache Invalidation
After enabling WebP, old thumbnails in bitrix/cache/resize_cache/ remain in JPEG/PNG. Delete them:
rm -rf /var/www/bitrix/bitrix/cache/resize_cache/*
Or via admin panel: "Site Management" → "Performance" → "Clear cache". After this, thumbnails regenerate on first access — can prewarm with curl script by sitemap.
Typical Issues
WebP generates but browser gets JPEG. Nginx doesn't send Vary: Accept header — CDN or caching proxy serves cached version without considering browser type.
WebP size larger than original. Happens on tiny icons (under 10×10 px) and PNG with few colors. Add check: if WebP is 10% larger, serve original.
Errors in b_event_log. With conversion enabled and no write permission to upload/ — Bitrix logs errors. Check chown on upload/ directory for web server user.