Оптимизация изображений на сайте 1С-Битрикс: форматы, вес и настройки

Картинки — самая тяжёлая часть почти любой страницы, и обычно именно они определяют, за сколько секунд посетитель увидит первый экран. Беда приходит не в день запуска: сайт сдали быстрым, а через полгода контент-менеджер загрузил десяток фотографий прямо с телефона, и главная открывается восемь секунд.

Про серверную часть скорости — в первой части, здесь только изображения.

Как понять, что дело в картинках

Откройте страницу с очищенным кешем: Ctrl+F5 в Windows, Shift+Cmd+R в macOS. Если крупные изображения проявляются сверху вниз, а страница собирается дольше трёх секунд, проверять нужно их.

Дальше — инструменты разработчика в браузере, вкладка «Сеть»: отсортируйте запросы по размеру и посмотрите первые строки. Там сразу видно и вес, и сколько времени ушло на каждый файл. На сайте одного жилого комплекса главная картинка весила 4,9 МБ, и страница грузилась дольше двенадцати секунд — остальное можно было не смотреть.

Снаружи то же самое показывает экспресс-аудит сайта: он измеряет вес страницы и отмечает, если картинки отдаются без сжатия.

Сколько должна весить картинка

Ориентиры, от которых стоит отталкиваться:

• Баннер или фотография на всю ширину — 150–300 КБ. Больше оправдано редко.
• Картинки в карточках и списках — 30–80 КБ.
• Вся страница целиком — до 1,5–2 МБ, и картинки в этом объёме занимают основную долю.

Главный показатель, на который смотрят поисковики, — время появления самого крупного элемента первого экрана. Хорошим считается результат до 2,5 секунды, и чаще всего этим элементом оказывается именно фотография или баннер.

Замер: одна фотография в четырёх вариантах

Чтобы не спорить о процентах, взяли фотографию с нашего сайта — 1190 на 616 точек, 596 КБ — и пересохранили её средствами самого продукта:

Вариант	Вес	Время обработки
JPEG, качество 95 (значение по умолчанию)	293 КБ	15 мс
JPEG, качество 80	114 КБ	10 мс
JPEG, качество 70	93 КБ	8 мс
WebP, качество 85	98 КБ	173 мс

Выводов из этой таблицы два. Первый: смена качества с 95 на 80 уменьшила файл в два с половиной раза — это самая дешёвая правка из всех возможных, и делается она одной настройкой. Второй: WebP при сопоставимом качестве выигрывает у сжатого JPEG немного, около пятнадцати процентов, но кодируется в десять с лишним раз дольше. На загрузке одной картинки это незаметно, а при массовой перегонке каталога разница в часах.

Какой формат выбирать

Формат	Для чего	Что учесть
JPEG	Фотографии	Универсальный вариант, качество 80 вместо 95 экономит до половины веса
PNG	Скриншоты, картинки с прозрачностью	Для фотографий не подходит: вес вырастает в несколько раз
WebP	Замена JPEG и PNG	Понимают все современные браузеры; выигрыш у сжатого JPEG небольшой, у несжатого — заметный
AVIF	Фотографии, где важен вес	Сжимает сильнее WebP, но в программном интерфейсе продукта такого формата нет: только своим кодом поверх библиотеки сервера
SVG	Логотипы, иконки, схемы	Масштабируется без потерь и весит килобайты; перед загрузкой чистить от лишних данных редактора

WebP в 1С-Битрикс: что умеет платформа

Здесь важно разделить две вещи. Библиотека обработки изображений на современных сборках сервера WebP и AVIF поддерживает — проверяется одной строкой в консоли:

php -r 'print_r(gd_info());'

А вот сам продукт в другой формат ничего не переводит. Когда картинка уменьшается при загрузке или через CFile::ResizeImage, результат сохраняется в том же формате, в каком был исходник: загрузили JPEG — получите JPEG поменьше.

Получить WebP можно тремя способами.

1. Своим кодом. В ядре есть подходящий класс, он принимает формат явно:

   use Bitrix\Main\File\Image;
   
   $image = new Image($_SERVER['DOCUMENT_ROOT'].'/upload/photo.jpg');
   if ($image->load()) {
       $image->saveAs($_SERVER['DOCUMENT_ROOT'].'/upload/photo.webp', 85, Image::FORMAT_WEBP);
   }

   Так делают конвертацию при сохранении элемента или отдельным агентом по каталогу.
2. Модулем из маркетплейса. Есть решения, которые сжимают и переводят картинки при загрузке, в том числе через сервис TinyPNG. Устанавливать модули может только владелец активного лицензионного ключа с действующим периодом обновлений, и перед установкой стоит сделать резервную копию.
3. На уровне веб-сервера. nginx умеет отдавать .webp вместо .jpg, если такой файл лежит рядом, а браузер сообщил о поддержке формата. Разметку страниц при этом менять не нужно, но правка конфигурации требует доступа root.

Если конвертация делается заранее и файлы лежат парами, в вёрстке их подключают через <picture>: браузер сам возьмёт тот формат, который понимает.

Настройки, которые включают до наполнения сайта

Продукт умеет уменьшать слишком большие изображения прямо при загрузке — это страховка от фотографий с телефона в полном разрешении. Настройки задаются для каждого инфоблока отдельно, в разделе полей, и включать их нужно сразу после установки, а не когда контент уже загружен: к ранее загруженным файлам они не применяются.

Заходим в настройки инфоблока:

Для картинки анонса ограничиваем размер по высоте и ширине: она показывается в списках, и 500 точек по высоте обычно достаточно.

Для детальной картинки ограничение шире — 1600–2000 точек по длинной стороне закрывает и крупные экраны, и зум.

Качество на снимках экрана стоит 95 — значение по умолчанию и главный резерв. Общая настройка качества живёт в главном модуле: Настройки → Настройки продукта → Настройки модулей → Главный модуль, поле «Качество JPG при масштабировании изображений». Снижение до 80 почти не заметно на глаз и даёт заметную экономию.

Сжатие перед загрузкой

Когда картинки готовит дизайнер или контент-менеджер, половина работы делается до сайта. Онлайн-сервисы сжатия — TinyPNG, Squoosh, Compressor.io — убирают лишний вес без видимой потери качества. Вот что получилось с той самой картинкой жилого комплекса:

4,9 МБ превратились в 694 КБ — на 86 процентов меньше, и это без обрезки размеров. В графических редакторах тот же эффект даёт экспорт для веба с подбором качества:

Правило, которое экономит больше любого сжатия: не загружать картинку шире, чем место, где она показывается. Фотография 4000 точек в блоке шириной 600 — это лишние мегабайты, которых никакое качество JPEG не вернёт.

Ленивая загрузка и первый экран

Атрибут loading="lazy" откладывает загрузку картинок, пока посетитель до них не долистал. Для длинных страниц это заметная экономия, и в современных шаблонах его ставят почти везде.

Почти — потому что для главной картинки первого экрана он вреден: браузер отложит как раз тот файл, по которому измеряется скорость появления контента. Баннер на первом экране загружают наоборот, в приоритете:

<img src="/upload/banner.jpg" width="1600" height="600" fetchpriority="high" alt="...">

И ещё одна мелочь, которая решает: атрибуты width и height нужны всем картинкам. Без них браузер не знает, сколько места занять, и содержимое прыгает по мере загрузки — поисковики считают это отдельным дефектом страницы.

Что проверить после

1. Пересобрать страницу с очищенным кешем и посмотреть вкладку «Сеть»: самые тяжёлые файлы должны измеряться сотнями килобайт, а не мегабайтами.
2. Прогнать адрес через экспресс-аудит и сравнить с тем, что было.
3. Проверить мобильную версию отдельно: там канал уже, а картинки часто те же самые.
4. Заглянуть в upload/resize_cache. Уменьшенные копии складываются туда и со временем занимают гигабайты — это нормально, но учитывайте при подсчёте места: разбор есть в материале о том, чем занят диск сервера.

Коротко

• Ограничения размеров в инфоблоках включают до наполнения сайта: задним числом они не сработают.
• Качество JPEG 80 вместо 95 уменьшает файл в два с половиной раза — самая дешёвая правка.
• WebP продукт сам не делает: нужен модуль, свой код или подмена на стороне nginx.
• Картинку первого экрана из ленивой загрузки исключают, остальным она полезна.
• Размеры в атрибутах width и height обязательны.