Страница каталога загружает 40 изображений товаров суммарным весом 8 МБ. Google PageSpeed фиксирует ошибки: «Используйте изображения в современных форматах» и «Правильно задайте размер изображений». Битрикс хранит оригиналы в /upload/ и создаёт ресайзы через CFile::ResizeImageGet() — но формат остаётся JPEG/PNG, без автоматической конвертации в WebP. Результат — медленная загрузка и потерянные позиции в выдаче. Неоптимизированные изображения — лишние 50–100 КБ трафика на каждое. На странице с 40 товарами это 2–4 МБ только на картинках. Поисковики учитывают скорость, особенно на мобильных устройствах: медленный сайт теряет до 20% конверсии. Комплексная оптимизация — сжатие без потерь, WebP, lazy loading — сокращает вес страницы в 2–3 раза и повышает позиции.
Мы настраиваем многоуровневую оптимизацию под ключ: ресайз, сжатие, WebP, lazy loading и отдача через CDN. Опыт более 7 лет в разработке на Битрикс позволяет гарантировать результат. Мы уже оптимизировали изображения для 50+ проектов, добившись улучшения PageSpeed на 20+ баллов. Средняя экономия на трафике после оптимизации составляет 15 000–20 000 рублей в месяц для каталога из 1000 товаров. Стоимость базового пакета работ варьируется от 30 000 до 50 000 рублей в зависимости от объёма существующих файлов. Оцените ваш проект — свяжитесь для бесплатного аудита скорости.
Влияние оптимизации изображений на производительность Битрикс
Каждое неоптимизированное изображение — это лишние 50–100 КБ трафика. На странице каталога с 40 товарами это 2–4 МБ только на картинках. Поисковики учитывают скорость загрузки, особенно на мобильных устройствах. Медленный сайт теряет до 20% конверсии. Комплексная оптимизация — сжатие без потерь, WebP, lazy loading — сокращает вес страницы в 2–3 раза и поднимает позиции в выдаче.
Пошаговый план настройки автоматической оптимизации
-
Аудит текущего состояния: замер PageSpeed, анализ структуры файлов в
/upload/, оценка объёма и форматов. -
Сжатие при загрузке: реализация обработчика
OnAfterFileSaveс вызовомImageOptimizer::compress(). Ограничение стороны до 2000px, качество 85% JPEG / 9 PNG, удаление EXIF. -
WebP-конвертация: установка обработчика
OnAfterGetResizeImagePathдля генерации WebP-копий. Настройка Nginx для отдачи WebP поAccept. - Lazy loading и srcset: доработка шаблонов компонентов каталога — добавление
loading="lazy",srcsetдля адаптивных разрешений. - Массовая обработка существующих файлов: запуск агента на 100 файлов за шаг.
- Тестирование и мониторинг: повторный замер PageSpeed, проверка отдачи WebP, совместимость с кэшем.
Уровень 1: ресайз и сжатие при загрузке
Стандартный CFile::ResizeImageGet() создаёт ресайз при первом запросе и кэширует результат в /upload/resize_cache/. Основная проблема — оригиналы хранятся без сжатия, и менеджеры загружают фотографии с телефона размером 5–10 МБ. Мы добавляем обработчик события OnAfterFileSave, который сжимает файл сразу после загрузки.
\Bitrix\Main\EventManager::getInstance()->addEventHandler(
'main',
'OnAfterFileSave',
function (\Bitrix\Main\Event $event) {
$file = $event->getParameter('FILE');
if (!in_array($file['CONTENT_TYPE'], ['image/jpeg', 'image/png', 'image/gif'])) {
return;
}
$path = $_SERVER['DOCUMENT_ROOT'] . $file['SRC'];
if (!file_exists($path)) {
return;
}
\Local\Media\ImageOptimizer::compress($path, $file['CONTENT_TYPE']);
}
);
Класс ImageOptimizer использует Imagick при его наличии, иначе GD. Он удаляет EXIF, ограничивает максимальную сторону до 2000px и выставляет качество 85% для JPEG или уровень сжатия 9 для PNG. После этого оригинал занимает в среднем 30% от исходного объёма. Если нужно обработать уже загруженные файлы, запускается массовый агент, который перебирает по 100 файлов за шаг.
Как настроить WebP-конвертацию в Битрикс?
WebP даёт 25–35% выигрыш в размере по сравнению с JPEG при сопоставимом качестве. Браузерная поддержка — 97%+ (все современные). Стратегия: генерируем WebP-версию рядом с оригиналом через событие OnAfterGetResizeImagePath, затем nginx отдаёт WebP браузерам, поддерживающим формат.
\Bitrix\Main\EventManager::getInstance()->addEventHandler(
'main',
'OnAfterGetResizeImagePath',
function (\Bitrix\Main\Event $event) {
$result = $event->getParameter('RESULT');
$src = $result['src'] ?? '';
if (!$src || !preg_match('/\.(jpg|jpeg|png)$/i', $src)) {
return;
}
$localPath = $_SERVER['DOCUMENT_ROOT'] . $src;
$webpPath = preg_replace('/\.(jpg|jpeg|png)$/i', '.webp', $localPath);
if (!file_exists($webpPath) && file_exists($localPath)) {
\Local\Media\WebpConverter::convert($localPath, $webpPath);
}
}
);
Пример конфигурации Nginx
map $http_accept $webp_suffix {
default "";
"~*webp" ".webp";
}
server {
location ~* ^(/upload/resize_cache/.+)\.(jpg|jpeg|png)$ {
set $img_path $1.$2;
set $webp_path $1.webp;
if ($webp_suffix = ".webp") {
add_header Vary Accept;
try_files $webp_path $img_path =404;
}
try_files $img_path =404;
expires 30d;
add_header Cache-Control "public, immutable";
}
}
Почему lazy loading критичен для SEO?
Lazy loading откладывает загрузку изображений за пределами экрана, сокращая время до интерактивности. В шаблоне компонента каталога добавляем loading="lazy" и srcset для адаптивных разрешений.
<?php
$img = \CFile::ResizeImageGet($element['PREVIEW_PICTURE'], ['width' => 300, 'height' => 300]);
$img2 = \CFile::ResizeImageGet($element['PREVIEW_PICTURE'], ['width' => 600, 'height' => 600]);
?>
<img
src="<?= htmlspecialchars($img['src']) ?>"
srcset="<?= htmlspecialchars($img['src']) ?> 300w, <?= htmlspecialchars($img2['src']) ?> 600w"
sizes="(max-width: 768px) 300px, 600px"
loading="lazy"
width="300"
height="300"
alt="Автоматическая оптимизация медиафайлов 1С-Битрикс"
>
Сравнение форматов изображений
| Формат | Сжатие | Качество | Поддержка | Размер файла |
|---|---|---|---|---|
| JPEG | Потери | Хорошее | 100% | 100% (база) |
| PNG | Без потерь | Отличное | 100% | 200%+ (больше) |
| WebP | Потери/без потерь | Сравнимо с JPEG | 97% | 70-75% от JPEG |
| AVIF | Потери/без потерь | Лучше | 90%+ | 50-60% от JPEG |
Автоматическая конвертация в WebP — оптимальный баланс совместимости и выигрыша в весе. Мы используем качество 82% (визуально без потерь).
Типичные проблемы при оптимизации
| Проблема | Причина | Решение |
|---|---|---|
| WebP не отдаётся | Отсутствует проверка Accept или неправильный location nginx | Настроить map и location как в примере выше |
| Исчезают EXIF-данные | Стриппинг метаданных при сжатии | При необходимости сохранить — отключить stripImage() |
| Lazy loading ломает вёрстку | Не указаны атрибуты width/height | Добавить их явно в тег img |
Что входит в настройку оптимизации медиафайлов
- Сжатие при загрузке: обработчик OnAfterFileSave, удаление EXIF, ресайз до 2000px, качество 85% JPEG / 9 PNG.
- WebP-конвертация: событие OnAfterGetResizeImagePath + конфигурация Nginx для отдачи WebP.
- Lazy loading и srcset: доработка шаблонов компонентов каталога.
- Массовая оптимизация существующих файлов: агент с шагом 100 файлов.
- Тестирование: замер PageSpeed, проверка отдачи WebP, совместимость с кэшем.
- Документация: описание всех изменений, настройки для поддержки.
Сколько времени занимает настройка?
- Базовый пакет (сжатие + WebP + lazy loading) — 1–2 рабочих дня.
- Массовая оптимизация существующих файлов — дополнительно 4–8 часов.
- Интеграция с CDN или дополнительными форматами (AVIF) — обсуждается отдельно.
Мы гарантируем выполнение работ в оговоренные сроки. Закажите настройку — мы оценим ваш проект бесплатно и предложим оптимальное решение. Свяжитесь с нами для консультации и получите экономию трафика до 60%.