Комплексна оптимізація зображень для 1С-Бітрікс: WebP, AVIF, srcset

Ми спеціалізуємося на оптимізації зображень для проєктів на 1С-Бітрікс. Зображення — найбільший компонент ваги сторінок для більшості бітрікс-проєктів. Типова ситуація: менеджер завантажує фото товару у високому роздільненні прямо з камери (3–8 MB, 4000×3000 пікселів), Бітрікс зберігає файл у /upload/iblock/, і саме цей файл віддається користувачам з мобільних пристроїв. Це критично впливає на 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/ може вирости до 20–50 GB — при цьому більшість файлів застаріли. Інфоблоки (IBLOCK) зберігають зображення, і без грамотної стратегії кешування розростання неминуче.

WebP дає виграш до 40%?

WebP дає на 25–40% менший розмір файлу при еквівалентній якості для фотографій, і на 60–80% для графіки з прозорістю порівняно з PNG. Сучасні браузери (Chrome 32+, Firefox 65+, Safari 14+) підтримують WebP. Wikipedia: WebP підтверджує ці цифри. Порівняйте: JPEG 100 КБ → WebP 60 КБ при тій самій візуальній якості. Це означає, що WebP кращий за JPEG на 30–40% за розміром при рівній якості.

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

1. На рівні nginx — через ngx_http_image_filter_module з перевіркою заголовка Accept. Вимагає попередньо створені .webp копії.
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="Фото товару в каталозі — приклад оптимізації зображень для 1С-Бітрікс">
</picture>

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

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

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

Як налаштувати автоматичну конвертацію при завантаженні?

Для автоматизації конвертації використовуйте наступний порядок дій:

1. Встановіть PHP-розширення gd або imagick з підтримкою WebP та AVIF.
2. Напишіть агент Бітрікс, який раз на годину перевіряє нові файли та конвертує їх.
3. Для вже існуючих файлів запустіть batch-скрипт через cron за допомогою cwebp або imagemagick.
4. Після конвертації налаштуйте srcset для адаптивних зображень.
5. Увімкніть lazy load атрибутами loading="lazy".

Після конвертації генеруються srcset-версії для адаптивних зображень.

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

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

$sizes = [400, 800, 1200];
$srcset = [];
foreach ($sizes as $w) {
    $img = CFile::ResizeImageGet($fileId, ['width' => $w, 'height' => round($w*0.75)], BX_RESIZE_IMAGE_PROPORTIONAL);
    $srcset[] = $img['src'] . ' ' . $w . 'w';
}
?>
<img srcset="<?= implode(', ', $srcset) ?>"
     sizes="(max-width: 768px) 400px, (max-width: 1024px) 800px, 1200px"
     src="/upload/fallback.jpg" alt="Зображення товару в різних роздільненнях"/>

Кожне зображення супроводжується alt-текстом з ключовим словом для SEO.

Кейс: каталог меблів, 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. Економія трафіку склала більше 80%, що дозволило клієнту заощадити десятки тисяч гривень щомісячно на CDN-трафіку.

Цей кейс — реальний приклад. Кожен проєкт унікальний, але ми гарантуємо аналогічний приріст продуктивності. Зв'яжіться з нами, щоб обговорити оптимізацію вашого каталогу.

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

Етапи робіт

Разом від 4 до 8 днів залежно від кількості кастомних шаблонів та обсягу каталогу. Наш досвід: 10+ років у розробці на Бітрікс, 150+ успішних проєктів з оптимізації. Гарантуємо покращення показників Core Web Vitals.

Замовте оптимізацію зображень для вашого проєкту — отримайте консультацію з вибору форматів та схеми кешування. Зв'яжіться з нами, щоб отримати розрахунок економії для вашого проєкту — інвестиції окупаються за 2-3 місяці за рахунок зростання конверсії.

80% сайтів на Бітрікс гальмують через одну таблицю

b_iblock_element_property — EAV-структура. Кожен рядок зберігає одне значення однієї властивості одного елемента. Каталог у 50 000 товарів з 30 властивостями дає 1,5 млн рядків. Коли розумний фільтр робить JOIN цієї таблиці з b_iblock_element за п'ятьма властивостями, MySQL іде в full table scan на 3–5 секунд.

Наш досвід показує: без втручання в цю таблицю прискорення неможливе. Ми беремося за проекти, де швидкість завантаження впала до 8–10 секунд, і повертаємо TTFB < 200 мс за 1–2 тижні. Оптимізація швидкості сайту починається з аудиту slow-запитів і закінчується комплексною перебудовою інфраструктури під ключ. У нашому портфоліо — понад 200 успішних проєктів. Ми — команда сертифікованих фахівців з 10‑річним досвідом роботи в Бітрікс.

Серверна оптимізація

Nginx. Не просто «увімкнули gzip». Конкретно:

• gzip_comp_level 4-5 — вище безглуздо, CPU з'їдає більше, ніж економить трафік;
• brotli on з brotli_static on — для попередньо стиснутих файлів (Brotli стискає на 20–30% краще за gzip);
• HTTP/2 з http2_max_concurrent_streams 128;
• fastcgi_cache для PHP-відповідей — кешування на рівні Nginx, минаючи PHP-FPM;
• worker_processes auto, worker_connections під кількість одночасних з'єднань.

PHP-FPM. Вибір між pm = dynamic і pm = static — не академічний:

• Static: фіксована кількість воркерів, без overhead на форк — для виділених серверів з передбачуваним навантаженням.
• Dynamic: економить RAM при низькому трафіку. pm.max_children рахуємо як (доступна RAM − RAM для MySQL/Redis) / середня витрата на процес.
• OPcache: opcache.memory_consumption=256, opcache.max_accelerated_files=20000, opcache.validate_timestamps=0 на продакшені (перезавантаження PHP-FPM при деплої).

MySQL/MariaDB. Головне вузьке місце майже завжди:

• slow_query_log з порогом 0.5 сек — кожен запит розбираємо через EXPLAIN.
• innodb_buffer_pool_size = 70–80% доступної RAM на виділеному сервері.
• Складені індекси для фасетного пошуку: (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) на b_iblock_element_property.
• OPTIMIZE TABLE b_iblock_element_property після масових операцій.

Як налаштувати кешування на три рівні?

Керований кеш компонентів. TTL налаштовуємо для кожного компонента окремо. Каталог — 3600 сек, новинна стрічка — 300 сек, банери — 86400. Однаковий TTL всюди — гарантія або застарілих даних, або марного кешу.

Композитний кеш. Технологія bitrix:composite — Nginx віддає готовий HTML із файлу, PHP не запускається. Динамічні зони (кошик, авторизація) підвантажуються AJAX-запитом через CBitrixComponent::setFrameMode(true). TTFB < 50 мс. Але не всі компоненти сумісні: $APPLICATION->ShowPanel() і прямий вивід через echo ламають композит. Перевіряємо кожну сторінку через панель «Продуктивність → Композитний сайт».

Порівняння: композитний кеш швидший за керований у 10–20 разів за часом першого байта. Офіційна документація Бітрікс з композитного кешу — Bitrix Composite.

Memcached / Redis. Переносимо кеш із файлової системи:

• Сесії → Redis (session.save_handler = redis) — швидше за файли в 10–50×, плюс робота в кластері.
• Кеш компонентів → Memcached через .settings.php: 'cache' => ['type' => 'memcache'].
• Кеш ORM-запитів — однакові GetList() не навантажують MySQL на кожному хіті.

Чому стандартних налаштувань MySQL недостатньо?

Індекси. Складені для фасетного пошуку. Покриваючі — для частих вибірок MySQL відповідає з індексу, не звертаючись до даних. Часткові індекси (MariaDB) для фільтрації за ACTIVE = 'Y'. Аудит невикористовуваних індексів — кожен сповільнює INSERT/UPDATE.

Партиціонування. Для таблиць з мільйонами рядків: b_stat_session, b_search_content_stem, Highload-блоки з історією. Партиція за датою — запит «замовлення за місяць» не сканує дані за три роки.

Реальний кейс: каталог 200 000 товарів, 50 властивостей. Фільтр за 10 властивостями займав 12 секунд. Після створення складених індексів за (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) та партиціонування b_iblock_element_property за IBLOCK_ID час виконання впав до 0,3 секунди. Навантаження на MySQL знизилося в 40 разів. Це дозволило скоротити витрати на сервер до 40% без втрати продуктивності.

Очищення. У будь-якій базі за рік-два накопичується: застарілий пошуковий індекс, прострочені записи в b_cache_tag, історія b_iblock_element_prop_s*, логи в b_event_log на гігабайти. Налаштовуємо регулярне очищення через агенти.

Партиціонування також вирішує проблему з паралельними запитами при обміні з 1С через CommerceML. Докладніше: MySQL Partitioning Documentation.

Після аудиту вашого проекту ми визначимо вузькі місця за 2 години та запропонуємо конкретний план прискорення. Замовте безкоштовний аудит швидкості — заповніть форму на сайті.

Фронтенд

Зображення — 60–80% ваги сторінки:

• WebP через CFile::ResizeImageGet() з BX_RESIZE_IMAGE_PROPORTIONAL + конвертація;
• srcset + sizes — не завантажуємо 3000px картинку в блок 400px;
• loading="lazy" для всього нижче першого екрану;
• AVIF — ще 20–30% економії порівняно з WebP.

CSS/JS:

• Вбудований модуль Бітрікс: об'єднання та мініфікація через «Налаштування → Оптимізація CSS/JS»;
• PurgeCSS / UnCSS — на типовому Бітрікс-проекті 60–70% CSS не використовуються;
• defer / async для некритичного JS;
• Critical CSS інлайном у <head> для миттєвого FCP.

Шрифти:

• <link rel="preload" as="font" crossorigin> для основного шрифту;
• font-display: swap — текст видно одразу;
• Subsetting через pyftsubset — вирізаємо кирилицю + латиницю, файл зменшується в 3–5 разів.

CDN

Cloudflare, BunnyCDN, AWS CloudFront або локальні (Selectel CDN, VK Cloud CDN).

• Статика (CSS, JS, зображення, шрифти) — через CDN.
• Правила кешування: Cache-Control: public, max-age=31536000, immutable для файлів з хешем.
• Оптимізація зображень на льоту (imgproxy, Cloudflare Polish) без навантаження на origin.

Навіщо потрібне навантажувальне тестування?

Не синтетичні бенчмарки, а реальні сценарії:

• k6 / wrk — імітація маршрутів: каталог → фільтрація → картка → кошик → оформлення.
• Метрики: RPS, час відповіді (p50, p95, p99), відсоток помилок.
• Xdebug (callgrind) або Blackfire — профілювання PHP, пошук вузьких місць.

Результат тестування — об'єктивна картина, де реально гальмує. Після оптимізації проганяємо повторно — фіксуємо покращення.

Результати

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

1. Аудит поточної продуктивності — аналіз slow-запитів, профілювання PHP, перевірка кешування, CDN, серверних налаштувань.
2. Налаштування серверної частини — Nginx, PHP-FPM, MySQL, Redis/Memcached, OPcache.
3. Оптимізація кешування — керований кеш, композитний сайт, налаштування TTL, теговане кешування.
4. Робота з БД — створення індексів, партиціонування, очищення, реорганізація EAV-таблиць.
5. Фронтенд — зображення (WebP/AVIF), CSS/JS (мініфікація, deferred), шрифти (preload, subsetting).
6. CDN — підключення, налаштування правил кешування.
7. Навантажувальне тестування — сценарії реальних користувачів, звіт за метриками.
8. Документація — опис усіх змін, рекомендації щодо подальшого обслуговування.
9. Гарантія — підтримка протягом 1 місяця після здачі.

Моніторинг

Без моніторингу через півроку все деградує. Новий модуль, неочищені логи, зміна в шаблоні — і швидкість повернулася до початкової.

• web-vitals API — Real User Monitoring від реальних відвідувачів.
• Synthetic monitoring — Pingdom, UptimeRobot, регулярні перевірки з різних локацій.
• Алерти — TTFB > 500 мс або LCP > 3 сек → сповіщення.

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

Вартість розраховується індивідуально після аудиту. Отримайте консультацію щодо вашого проекту — оцінимо поточний стан і запропонуємо план прискорення з конкретними термінами та бюджетом. Ми — команда з 10+ роками досвіду в Бітрікс, виконали понад 200 проектів з оптимізації швидкості сайту. Замовте безкоштовний аудит швидкості — зв'яжіться з нами просто зараз.