Оптимізація зображень для 1С-Бітрікс

Оптимізація зображень для 1С-Бітрікс

Зображення — найбільший компонент ваги сторінок для більшості бітрікс-проєктів. Типова ситуація: менеджер завантажує фото товару у високій роздільній здатності прямо з камери (3–8 MB, 4000×3000 пікселів), Бітрікс зберігає файл у /upload/iblock/, і саме цей файл віддається користувачам з мобільних пристроїв. У 2024 році це впливає на Core Web Vitals (LCP, CLS), позиції в пошуку Google та конверсію — повільне завантаження зображень напряму пов'язане з відмовами на мобільних.

Механізм ресайзу в Бітрікс

Бітрікс надає функції CFile::ResizeImageGet() і \Bitrix\Main\UI\FileInput::processFiles() для нарізки зображень на льоту. У шаблонах компонентів це виглядає так:

$resizedImage = CFile::ResizeImageGet(
    $arItem['PREVIEW_PICTURE'],
    ['width' => 400, 'height' => 300],
    BX_RESIZE_IMAGE_PROPORTIONAL,
    false,
    false
);

Результат кешується в /upload/resize_cache/. Проблема: за замовчуванням кеш нарізки зберігається без обмеження розміру. На проєкті з активною заміною зображень тека /upload/resize_cache/ за 2–3 роки може вирости до 20–50 GB — при цьому більшість файлів застаріли.

Конвертація у WebP

WebP дає на 25–40% менший розмір файлу при еквівалентній якості для фотографій, і на 60–80% для графіки з прозорістю порівняно з PNG. Сучасні браузери (Chrome 32+, Firefox 65+, Safari 14+) підтримують WebP.

Способи реалізації WebP для Бітрікс:

1. На рівні nginx через ngx_http_image_filter_module:

location ~* \.(jpg|jpeg|png)$ {
    add_header Vary Accept;
    if ($http_accept ~* "webp") {
        rewrite ^(.*)\.(jpg|jpeg|png)$ $1.webp break;
    }
}

Працює лише якщо .webp-версії файлів існують. Генерація — через cron-скрипт з cwebp або imagemagick.

2. Через PHP-обгортку над CFile::ResizeImageGet():

function getImageSrc(int $fileId, int $width, int $height): string {
    $webpSupported = str_contains($_SERVER['HTTP_ACCEPT'] ?? '', 'image/webp');
    $format = $webpSupported ? 'webp' : 'jpg';
    // Кастомний конвертер з кешуванням результату
    return ImageConverter::resize($fileId, $width, $height, $format);
}

3. Тег <picture> з кількома джерелами:

<picture>
    <source srcset="/upload/resize_cache/product_400x300.webp" type="image/webp">
    <img src="/upload/resize_cache/product_400x300.jpg" width="400" height="300" loading="lazy" alt="...">
</picture>

Це найбільш універсальний спосіб — браузер сам вибирає підтримуваний формат.

AVIF як наступний крок

AVIF (AV1 Image Format) дає ще 20–35% виграш над WebP для фотографій. Chrome підтримує з версії 85, Firefox з 86, Safari з 16. Кодування AVIF повільніше WebP, тому для великих каталогів генерація ведеться у фоні через чергу завдань.

Адаптивні зображення (srcset)

Для Retina-дисплеїв і різних розмірів екрана потрібні кілька версій зображення:

$sizes = [
    ['width' => 400, 'height' => 300],   // мобільні
    ['width' => 800, 'height' => 600],   // планшети
    ['width' => 1200, 'height' => 900],  // десктоп
];
$srcset = [];
foreach ($sizes as $size) {
    $img = CFile::ResizeImageGet($fileId, $size, BX_RESIZE_IMAGE_PROPORTIONAL);
    $srcset[] = $img['src'] . ' ' . $size['width'] . 'w';
}

<img srcset="<?= implode(', ', $srcset) ?>"
     sizes="(max-width: 768px) 400px, (max-width: 1024px) 800px, 1200px"
     src="/upload/fallback.jpg" alt="...">

Кейс: каталог меблів, 8000 SKU

До оптимізації: всі зображення в JPEG, середній розмір 480 KB, немає srcset, немає WebP. Сторінка каталогу (24 товари) — 11,5 MB зображень на десктоп, 11,5 MB на мобільний (ті самі файли).

Що зробили:

• Batch-конвертація всіх зображень у upload у WebP через cwebp (cron-скрипт, обробка за ніч)
• Нарізка через CFile::ResizeImageGet() у трьох розмірах для srcset
• Тег <picture> з source WebP + img JPEG fallback у шаблоні catalog.section
• Lazy load для зображень нижче fold
• Налаштування планового очищення /upload/resize_cache/ старіше 90 днів

Результат: середня вага зображення в каталозі — 28 KB (WebP, потрібний розмір). Сторінка каталогу — 680 KB зображень на мобільному, 1,1 MB на десктоп. LCP: 4,2 с → 1,6 с. PageSpeed Mobile: 31 → 74.

Етапи робіт

Разом від 4 до 8 днів залежно від кількості кастомних шаблонів і обсягу каталогу.