Сжатие изображений без потери качества: WebP, AVIF и старые форматы

Картинки занимают 60-80 процентов веса страницы, поэтому правильное сжатие даёт больше, чем любая другая работа над скоростью. Фото 1920×1080 в обычном формате весит 200-400 КБ, в webp примерно вдвое меньше. На плоской графике с крупной заливкой современный формат может проиграть.

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

В статье разберу, чем отличаются форматы, какой выбрать под какую задачу, как настроить автоматическую конвертацию и где сжатие наоборот вредит. Без религиозных войн «AVIF лучше всего», потому что это не всегда так.

Чем отличаются JPG, PNG, WebP, AVIF

Кратко по формату каждого, без академических подробностей.

JPG (JPEG) — старичок 1992 года. Сжатие с потерями, оптимизирован под фото. Не поддерживает прозрачность. Поддерживается везде. Размер на типовом фото 1920×1080: 200-400 КБ при качестве 80.

PNG — тот же возраст. Сжатие без потерь, поддерживает прозрачность и альфа-канал. Хорош для логотипов, иконок, скриншотов с текстом. Тот же снимок весит 1-2 МБ, что слишком много для фото на сайте.

WebP — формат от Google, появился в 2010, стабильно поддерживается с 2014. Поддерживает и сжатие с потерями (как JPG), и без (как PNG), и прозрачность, и анимацию (как GIF). Размер фото при качестве 80: 100-200 КБ. Минус 30-50 процентов к JPG при сравнимом визуальном качестве. Поддерживается всеми современными браузерами включая Safari начиная с 14.

AVIF — открытый формат на основе кодека AV1, появился в 2019. Сжатие ещё агрессивнее, чем WebP. Поддерживает HDR, 10-битный цвет. Размер фото: 60-130 КБ при сравнимом качестве. Минус 30 процентов к WebP. Поддержка: Chrome с 2020, Firefox с 2021, Safari с 16.4 (середина 2023).

Краткая сводка

Формат	Прозрачность	Сжатие	Поддержка
JPG	нет	с потерями	везде
PNG	да	без потерь	везде
WebP	да	оба варианта	везде с 2014-2020
AVIF	да	оба варианта	везде с 2023

В 2026 году WebP можно считать стандартом по умолчанию: поддержка везде, выгода по весу очевидная, никаких рисков. AVIF — там, где экономия каждого килобайта важнее, чем поддержка совсем старых браузеров (но их в 2026 уже почти нет).

Почему AVIF не всегда лучше

Я часто вижу совет «ставьте всё в AVIF». На практике три минуса.

Кодирование медленное. Сжатие AVIF в 5-20 раз медленнее, чем WebP. Если вы каждое фото пропускаете через cwebp за 0,3 секунды, то avifenc на ту же картинку уйдёт 5-7 секунд. На большом каталоге (5000 товаров) это часы вместо минут.

Декодирование тоже медленное. На слабых мобильных устройствах AVIF распаковывается заметно дольше WebP. На дешёвом смартфоне разница может съесть выигрыш от меньшего размера файла. Здесь нужен реальный замер на целевой аудитории.

Не идеально на мелких изображениях. На картинках меньше 100×100 пикселей AVIF часто даёт больший файл, чем WebP, из-за фиксированных накладных расходов формата. Логотипы и иконки стоит оставлять в WebP или вообще в SVG.

Мой подход на типичном проекте: WebP по умолчанию, AVIF подключаем когда есть причина (тяжёлый каталог фото) и есть инфраструктура для генерации. Если делаешь сайт-визитку — ставь WebP и не парься.

Какой формат под какой контент

Привязка к типу содержимого:

Фото

Лучше всего: WebP качество 75-80. Если картинка большая (hero, баннер) — попробовать AVIF и сравнить.

Не использовать: PNG для фото. Это распространённая ошибка. PNG сохраняет каждый пиксель без потерь, файл в 5-10 раз тяжелее WebP, а визуальной разницы нет.

Иллюстрации с плоскими цветами

Лучше всего: SVG, если это вектор. WebP-lossless или PNG, если только растровая.

WebP в режиме без потерь часто меньше PNG для иллюстраций, проверять стоит. AVIF здесь не даёт большого выигрыша.

Логотип

Лучше всего: SVG. Векторный формат, масштабируется без потерь, файл часто меньше 5 КБ.

Если нет SVG: PNG для самого верхнего меню (важна резкость на любых экранах). WebP-lossless для копий на других страницах.

Не использовать: JPG для логотипа. Появятся артефакты в районе букв и контуров.

Скриншот с текстом

Лучше всего: PNG, если текст должен быть читаемым. WebP-lossless как альтернатива.

JPG и WebP с потерями убьют резкость текста, особенно мелкого. Это будет заметно на ретина-дисплеях.

Иконки

Лучше всего: SVG. Если только растр — PNG в нужных размерах.

WebP для иконок 16×16, 32×32 не даёт выигрыша, файл может быть даже больше PNG.

Анимация

Лучше всего: WebP или AVIF в режиме анимации. Видео в формате MP4/WebM (короткие зацикленные ролики).

Не использовать: GIF. Он сильно тяжелее любого современного варианта. Анимированный WebP легче GIF в 5-10 раз при той же длительности.

Как настроить автоматическую генерацию WebP/AVIF

Ручное сжатие каждой картинки — тупиковый путь. На сайте на 200 страниц с 5 картинками каждая это 1000 файлов. Через полгода кто-то загрузит новые в админку, забудет сжать, и красные баллы вернутся. Нужна автоматизация.

WordPress

Самый удобный путь — плагин. В 2026 я рекомендую один из:

• Converter for Media (бывший WebP Converter for Media) — бесплатный, настраивается за 10 минут, поддерживает WebP и AVIF, переписывает HTML на лету.
• EWWW Image Optimizer — комбинированный, сжимает оригиналы и генерирует WebP/AVIF.
• ShortPixel — облачный, лучшее качество, но платный после 100 картинок в месяц.

После установки Converter for Media:

1. В админке заходите в «Settings — Converter for Media».
2. Выбираете форматы: WebP обязательно, AVIF опционально (если хостинг тянет).
3. Качество: 75-80 для фото, 85-90 для иллюстраций.
4. Метод доставки: «Pass thru» (через PHP) для shared, «Apache mod_rewrite» если хостинг разрешает свой .htaccess.
5. Запускаете «Bulk optimization» для существующих картинок.

Плагин подменяет картинки в HTML на лету: если браузер поддерживает WebP, отдаётся WebP, иначе оригинал. Никаких изменений в темах не нужно.

Битрикс

В Битриксе есть штатный модуль «Веб-оптимизатор» с поддержкой WebP с 2021 года. Включается в админке: «Настройки — Настройки модулей — Главный модуль — Веб-оптимизатор». Чекбокс «Включить веб-оптимизатор», выбираете «WebP» в списке форматов.

Для AVIF в Битриксе пока нет штатной поддержки в коробке, нужен модуль из Маркетплейса или ручная настройка через BX_RESIZE_IMAGE. Я обычно ставлю либо платный модуль, либо ручной обработчик в init.php:

AddEventHandler('main', 'OnAfterRenderImage', function ($arParams) {
    // тут логика конверсии в WebP/AVIF при рендере
});

Tilda

Tilda сама генерирует WebP с 2022 года для всех новых блоков. Старые блоки не пересобираются автоматически — надо открыть страницу в редакторе и пересохранить. После этого WebP появится в выдаче.

AVIF на Tilda недоступен из коробки. Если очень нужен — только через свой CDN с правилами на стороне CDN.

OpenCart, MODX

В OpenCart есть модуль WebP Generator от стороннего разработчика, рабочий. В MODX используется компонент pThumb или phpThumbOf с правильной конфигурацией.

На голом хостинге без CMS

Если у вас статика или собственный движок — можно настроить через .htaccess с проверкой Accept-заголовка:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTP_ACCEPT} image/webp
  RewriteCond %{REQUEST_FILENAME}.webp -f
  RewriteRule ^(.+).(jpg|jpeg|png)$ $1.$2.webp [T=image/webp,E=accept:1,L]
</IfModule>

<IfModule mod_headers.c>
  <FilesMatch ".(jpg|jpeg|png)$">
    Header append Vary Accept
  </FilesMatch>
</IfModule>

Этот сниппет ищет файл с расширением .webp рядом с оригиналом, и если есть и браузер поддерживает — отдаёт его. Сами WebP-файлы заранее сгенерируйте скриптом:

find ./images -type f ( -iname "*.jpg" -o -iname "*.png" ) 
  -exec sh -c 'cwebp -q 80 "$1" -o "$1.webp"' _ {} ;

Picture, srcset и почему просто заменить файлы недостаточно

Если вы просто положили .webp рядом с .jpg и поменяли расширение в HTML — на старых iOS до версии 14 картинки покажутся битыми. Чтобы такого не было, используется тег <picture> с фолбэком:

<picture>
  <source srcset="/img/hero.avif" type="image/avif">
  <source srcset="/img/hero.webp" type="image/webp">
  <img src="/img/hero.jpg" alt="Главное фото" width="1200" height="600">
</picture>

Браузер пробегает по <source> сверху вниз. Первый формат, который он понимает, грузится. Если ни один не подошёл, грузится <img> как фолбэк.

Адаптивные картинки через srcset

Если вы хотите отдавать разные размеры картинки разным экранам (полезно для мобильных), используется srcset с дескрипторами ширины:

<picture>
  <source
    srcset="/img/hero-480.webp 480w,
            /img/hero-960.webp 960w,
            /img/hero-1920.webp 1920w"
    sizes="(max-width: 600px) 100vw, 50vw"
    type="image/webp">
  <img
    src="/img/hero-960.jpg"
    alt="Главное фото"
    width="960" height="480"
    loading="lazy">
</picture>

Браузер сам выбирает подходящий размер по ширине вьюпорта и плотности пикселей. На мобильном уйдёт 480-я версия, на десктопе — 1920-я. Экономия трафика на мобильных — в 4-8 раз.

В современных CMS адаптивные картинки делаются сами. WordPress генерирует srcset для медиатеки автоматически с версии 4.4. Битрикс — через CFile::ResizeImageGet. Tilda — в встроенных блоках.

Атрибуты width и height обязательны

Без явных размеров картинка во время загрузки занимает 0 пикселей, а потом резко прыгает. Это убивает CLS. Указывайте width и height всегда, даже если CSS их потом переопределяет:

<img src="/img/team.webp" alt="Команда" width="800" height="600" style="max-width: 100%; height: auto;">

Браузер использует эти числа для расчёта пропорций, резервирует место заранее. После загрузки CLS ноль.

Когда сжатие наоборот портит сайт

Слепое сжатие всех картинок в WebP с качеством 80 — не лучшая стратегия. Где это вредит:

Логотипы с тонкими линиями

Сжатие WebP с потерями съедает резкость на тонких линиях и засечках шрифта. Если ваш логотип состоит из тонкого текста или узкой иконки — результат заметен на ретине. Решение: оставить PNG, перевести в SVG, или использовать WebP в режиме без потерь (-lossless в cwebp).

Иконки UI

Иконки 16×16, 32×32 после сжатия с потерями становятся мутными. Используйте SVG (для векторных) или PNG (для пиксельных).

Скриншоты с мелким текстом

Скриншоты экрана с интерфейсом, где текст 12-14 пикселей — после WebP с качеством 80 текст становится размытым. Используйте PNG или WebP-lossless.

Картинки с уже артефактами

Если у вас уже сжатый JPG с артефактами и вы пересжимаете его в WebP — артефакты могут даже усилиться. Лучший результат — брать оригинал большого качества, делать из него WebP один раз.

Очень мелкие фото

Картинки меньше 50 КБ — выигрыш от перехода на WebP мал, а накладные расходы есть. Оставьте JPG, сэкономите время на конвертацию.

Реальный кейс: магазин на 1200 SKU

Интернет-магазин обуви на OpenCart, 1200 товаров, у каждого по 4-6 фото. Главные жалобы: PageSpeed мобильный 28 баллов, страница товара грузится 6 секунд, пользователи отваливаются.

Анализ. Каждое фото товара 800×800 в JPG качества 95, средний вес 250 КБ. На странице товара 5 фото — это 1,25 МБ только на картинки. Плюс шапка, шрифты, стили — итого почти 2 МБ.

Что сделали:

• Поставили модуль WebP Generator для OpenCart.
• Запустили пакетное преобразование всех 6000 файлов с качеством 80. Заняло 4 часа.
• Включили адаптивный srcset через шаблон.
• Главные карточки на категории грузим в 480-й версии, на странице товара — 800-й.

Результат:

• Средний вес фото: 60 КБ (было 250).
• Размер страницы товара: 720 КБ (было 2 МБ).
• LCP на мобильном: 2,1 с (было 5,8).
• PageSpeed мобильный: 71 балл (было 28).

Стоимость работ: 12 часов на настройку, тестирование и подкрутку шаблона. По часовой ставке вышло 14 тысяч рублей.

Чек-лист настройки сжатия на сайте

Если вы хотите сделать всё сами, вот порядок действий:

1. Определите CMS и выберите модуль/плагин (WordPress — Converter for Media, Битрикс — штатный модуль, OpenCart — WebP Generator).
2. Установите, настройте качество 75-80 для фото, 90 для иллюстраций.
3. Запустите массовую конвертацию существующих картинок.
4. Проверьте через DevTools на вкладке Network, что вместо JPG действительно отдаётся WebP.
5. Прогоните PageSpeed для главной и страницы товара/услуги, сравните до и после.
6. Через неделю проверьте Search Console, ушли ли красные предупреждения по картинкам.

Если на каком-то шаге застряли или не уверены, что плагин делает именно то, что нужно — можно прислать ссылку через форму, посмотрю и подскажу. Базовый аудит с настройкой автоматической конвертации — 4-6 часов работы, в зависимости от CMS и количества картинок. Подробности по тарифам — в разделе цен.

Дополнительные материалы по теме скорости — в рубрике speed. Там есть статьи про LCP, Core Web Vitals, PageSpeed и общие принципы оптимизации, которые хорошо ложатся на работу с картинками.

Частые вопросы

Какой формат выбрать для картинок

Для фотографий webp, современные браузеры его понимают. Для плоской графики и логотипов часто выигрывает векторный формат. AVIF сжимает плотнее, но кодируется медленнее и поддерживается уже.

Сколько экономит сжатие

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

Почему недостаточно просто заменить файлы

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

Когда сжатие портит сайт

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