Ключевые выводы

Форматы — это компромисс, а не рейтинг. Каждый кодек оптимизирует свой угол: размер файла, скорость декодирования на слабом телефоне, поддержка прозрачности, совместимость с архивами и камерами. «Перевести всё на AVIF» без fallback ломает Safari 15 и часть корпоративных браузеров.

JPEG живёт не потому, что лучший, а потому что универсален. Он проигрывает AVIF и WebP по байтам на том же качестве, но декодируется мгновенно на любом устройстве за последние тридцать лет. В production JPEG остаётся страховкой в <picture> и CDN-трансформациях.

Современный веб — это стек форматов, а не один победитель. Hero-фото — AVIF + WebP + JPEG; UI-иконки — SVG или PNG; анимация — короткое видео (MP4/WebM) вместо GIF. Выбор формата напрямую бьёт по Core Web Vitals и LCP.

Кодирование дороже декодирования. AVIF и JPEG XL дают меньший файл, но сжатие на сервере или в CI может занимать секунды на кадр. Для CMS с тысячами upload'ов важнее pipeline (кеш, фоновые воркеры), чем «максимальное» качество кодека.

Почему форматов изображений так много

Если бы существовал один идеальный формат, BMP и GIF давно исчезли бы с дисков. На практике задачи различаются: скриншот с текстом требует резких границ без артефактов; портрет — мягких переходов и малого размера; иконка — масштабирования без пикселизации; серия снимков с iPhone — метаданных и глубины.

Каждое поколение технологий сдвигало баланс. Рост разрешений камер (8 → 48 мегапикселей) и Retina-экранов увеличил сырой вес кадра. Мобильный интернет сделал каждый килобайт видимым в счёте оператора и в bounce rate. Видеокодеки (H.264, HEVC, AV1) научились сжимать последовательности кадров — логично было перенести те же идеи в статичные изображения (HEIC, AVIF).

Патенты и лицензии тоже влияли на ландшафт. GIF когда-то был под угрозой royalty; PNG создали как свободную альтернативу. HEVC в HEIC с патентной сеткой тормозит веб-адопцию. AV1 и JPEG XL позиционируются как открытые, но браузерная поддержка и скорость энкодера — отдельная история.

Кратко: много форматов — следствие разных типов контента, железа и юридических ограничений, а не «лень стандартизаторов».

Как устроено сжатие: с потерями, без потерь и зрение

Понимание механики помогает выбирать формат осознанно, а не по таблице «модный / немодный».

Сжатие без потерь (PNG, GIF, часть WebP/AVIF) находит повторяющиеся паттерны и кодирует их короче. Исходные пиксели восстанавливаются бит-в-бит. Это идеально для UI, схем, скриншотов с мелким текстом — но фото с шумом плохо сжимается: каждый пиксель уникален.

Сжатие с потерями (JPEG, большинство фото в WebP/AVIF/HEIC) отбрасывает информацию, которую глаз замечает слабее. JPEG использует дискретное косинусное преобразование (DCT): изображение делят на блоки 8×8, высокие частоты округляют или обнуляют. Отсюда характерные «квадраты» при агрессивном quality. Хрома-субдискретизация (4:2:0) дополнительно уменьшает цветовое разрешение — глаз чувствительнее к яркости, чем к оттенку.

Перцептуальные кодеки нового поколения (AV1 в AVIF, HEVC в HEIC) используют более крупные блоки, предсказание внутри кадра и контекстные модели. Они выигрывают 30–50 % размера относительно JPEG при том же субъективном качестве, но CPU при кодировании растёт кратно.

При выборе спросите: «Что важнее — байты на диске CDN или миллисекунды decode на бюджетном Android?» Ответ определит, стоит ли AVIF на каждом thumbnail или достаточно WebP.

BMP и эпоха «сырых» пикселей

Bitmap (BMP) — детище экосистемы Windows 1980-х. Файл хранит заголовок и массив пикселей почти напрямую: для 1920×1080 RGB это около 6 МБ без сжатия. Структура проста — поэтому BMP до сих пор встречается как промежуточный формат в графических пайплайнах, драйверах принтеров, legacy-играх.

Для веба BMP бесполезен: огромный вес, нет прозрачности, нет прогрессивной загрузки. Если вы видите .bmp на сайте — это либо ошибка CMS, либо внутренний asset, случайно попавший в public.

Урок BMP для истории форматов: простота структуры ≠ пригодность для сети. Интернету нужны были алгоритмы, а не только контейнеры для пикселей.

GIF, JPEG и PNG: три ответа на три задачи

GIF — анимация и 256 цветов

CompuServe выпустил GIF в 1987 году. Формат ограничен палитрой в 256 цветов на кадр, зато поддерживает прозрачность (один «ключевой» цвет) и покадровую анимацию. GIF сделал возможными ранние мемы, баннеры и loader'ы на GeoCities.

Для плоской графики, схем и пиксель-арта GIF до сих пор читаем. Для фотографий — нет: дithering и banding разрушают кожу и небо. Анимированный GIF часто весит больше, чем тот же ролик в H.264: каждый кадр — отдельное сжатие без межкадрового предсказания.

JPEG — фотографии в массовый интернет

JPEG (1992, ISO 10918) перевёл фото из разряда «скачать час» в «открыть страницу». Потери настроены под человеческое зрение: мелкие детали в текстурах сохраняют грубо, плавные градиенты — аккуратнее. Quality 80–85 — типичный компромисс для веба; ниже 70 на лицах и небе появляются блоки.

JPEG не поддерживает альфа-канал и анимацию (исключая редкий MJPEG для видео). Логотип на прозрачном фоне в JPEG невозможен — отсюда пара PNG + JPEG на одном сайте.

Почему JPEG «победил»: маленькие файлы при приемлемом качестве, мгновенный decode, поддержка в каждом редакторе и камере. Недостатки известны — артефакты, нет прозрачности — но для hero-фото и галерей этого хватало двадцать лет.

PNG — без потерь и полная прозрачность

PNG (1996) родился как патентно-свободная альтернатива GIF. Deflate-сжатие без потерь, полноценный альфа-канал (256 уровней прозрачности), gamma-коррекция. Идеален для логотипов, иконок, скриншотов, UI-слоёв.

Цена — размер на фото: PNG 4000×3000 легко переваливает за 15–25 МБ, тогда как JPEG уложится в 2–4 МБ. PNG-8 с палитрой экономит место для простых картинок, но уступает по гибкости PNG-24.

Кратко: GIF — анимация и плоская графика; JPEG — фото; PNG — чёткие края и прозрачность. Три формата закрыли 90 % задач 1990–2000-х.

Интернет ускоряется, а изображения тяжелеют

К началу 2000-х парадокс стала очевидна: каналы ширре, а страницы грузятся не пропорционально быстрее. Причины — рост разрешения мониторов, камер смартфонов, Retina-дисплеев и «полноэкранных» hero-блоков в дизайне.

Смартфон 2020 года снимает 12 МП и сохраняет HEIC; дизайнер кладёт «оригинал» 4000 px в <img width="400">. Браузер всё равно скачивает лишние мегапиксели, если нет srcset и server-side resize. Формат — только половина оптимизации; вторая — правильный размер и lazy load (см. чеклист ускорения Next.js).

Мобильный интернет добавил latency и лимиты данных. Google включил LCP в Core Web Vitals — largest contentful paint часто приходится на hero-изображение. Выигрыш 30 % в байтах AVIF против JPEG напрямую улучшает метрику без смены дизайна.

Современные форматы: WebP, HEIC, AVIF и JPEG XL

WebP — первая серьёзная попытка Google

Google представил WebP в 2010 году, опираясь на технологии VP8. Один контейнер закрывает lossy и lossless, альфа, анимацию. На типичных фото WebP на 25–35 % легче JPEG при том же SSIM; lossless WebP обычно на 20–30 % меньше PNG.

Поддержка в браузерах с 2020-х — практически полная (Safari с 14+). WebP стал «безопасным» следующим шагом после JPEG: CDN Cloudflare, Imgix, Vercel Image Optimization отдают WebP по умолчанию.

Минусы: кодирование lossless медленнее PNG; анимация WebP не везде лучше видео; на очень низком quality иногда «мылит» иначе, чем JPEG — стоит A/B на критичных баннерах.

HEIC и HEIF — формат камеры, не сайта

High Efficiency Image Container (HEIF), часто с HEVC (H.265) внутри, — стандарт Apple для фото с iPhone с iOS 11. Файлы .heic компактнее JPEG при том же визуальном качестве, поддерживают глубину, серии Live Photo, HDR-метаданные.

Для веба HEIC проблемен: патенты HEVC, слабая поддержка в Chrome/Firefox на десктопе, неудобство для пользователей Windows без конвертера. Рабочий паттерн — конвертировать upload в JPEG/WebP/AVIF на сервере, а не отдавать HEIC напрямую.

AVIF — лидер эффективности в 2026 году

AVIF (2019) упаковывает кадры кодека AV1 — открытый преемник VP9. На фото AVIF часто на 20–50 % меньше WebP и на 30–60 % меньше JPEG при сравнимом качестве (зависит от энкодера и -speed). Поддерживаются HDR (PQ/HLG), широкая гамма, lossless и анимация.

Chrome, Firefox, Safari 16+ декодируют AVIF; для старых клиентов нужен fallback через <picture>:

<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="…" width="1200" height="630" loading="lazy" />
</picture>

Недостатки: кодирование медленное (libaom, rav1e — настройка -cpu-used / speed); на старых Android decode AVIF заметнее JPEG; некоторые CMS ещё не генерируют AVIF в upload pipeline.

JPEG XL — потенциал без массовой победы

JPEG XL (стандарт ISO/IEC 18181, финализация ~2021) проектировался как «настоящая замена JPEG»: lossy и lossless в одном файле, progressive decode, recompression без дополнительных потерь JPEG→JXL, HDR, альфа, анимация. Декодирование задумывалось быстрее, чем у AVIF.

Apple не приняла JXL в Safari; Chrome эксперимент закрыли. В 2026 году JPEG XL — формат для энтузиастов, архивов и инструментов (Squoosh, XnConvert), но не для «default CDN format». Следите за ситуацией: если Safari добавит поддержку, баланс может сдвинуться — AVIF выигрывает по adoption, JXL — по скорости decode в теории.

Сводное сравнение ключевых свойств (дублируем в prose, таблица — шпаргалка):

JPEG остаётся страховкой совместимости; PNG — когда нужны идеальные края; WebP — золотая середина CDN; AVIF — максимум экономии байт на фото; HEIC — исходник с телефона, не asset на сайте; JPEG XL — watch list.

SVG и когда вектор побеждает растр

SVG не конкурирует с AVIF на фото, но закрывает другой класс задач: логотипы, иконки, диаграммы, простые иллюстрации. Масштабируется без потери резкости, весит килобайты, стилизуется CSS, анимируется SMIL/CSS/JS.

Для фото SVG не подходит — растр внутри <image> не даёт выигрыша. Правило 2026: иконки и логотипы — SVG (или icon font только если legacy); фото — AVIF/WebP/JPEG; скриншоты с мелким текстом — PNG или lossless WebP.

Inline SVG улучшает доступность и SEO, если задать <title> и role="img". Для sprite sheet'ов рассмотрите <use href="#icon-id">.

Какой формат выбрать в 2026 году

Фотографии и hero-блоки

Основной — AVIF (quality 45–55 в большинстве энкодеров ≈ JPEG 80). Fallback — WebP, затем JPEG. Генерируйте три версии при build или через image CDN. Не отдавайте 3000 px, если CSS показывает 800 px — экономия от resize часто больше, чем от смены кодека.

Логотипы, UI, скриншоты

SVG для простых форм. PNG когда нужна pixel-perfect растровая графика или сложная композиция. Lossless WebP как более лёгкая альтернатива PNG там, где браузеры позволяют. Избегайте JPEG для текста — артефакты на буквах неприемлемы.

Анимация

Замените GIF на короткое loop-видео (<video autoplay muted loop playsinline>) — обычно в 5–10 раз меньше веса. WebP/AVIF animation уместна для простых loader'ов без звука. Для сложной анимации — Lottie (JSON) или CSS.

Архив и исходники

PNG или TIFF для мастер-копий без потерь. JPEG XL — если ваш toolchain уже поддерживает и вы готовы к миграции при росте поддержки. Не храните единственную копию в HEIC без конвертера.

Кратко: AVIF + fallback для фото; SVG/PNG для UI; видео вместо GIF; JPEG — универсальный запасной аэродром.

Как отдавать изображения на production-сайте

Формат без правильной доставки не даст эффекта. Минимальный чеклист для Astro, Next.js или статики:

Responsive images. Атрибуты srcset и sizes (или компонент <Image> в Next/Astro) сообщают браузеру, какой файл скачать. Без них mobile тянет desktop-версию.

Lazy loading. loading="lazy" для below-the-fold; fetchpriority="high" и без lazy для LCP-hero — иначе проседает Largest Contentful Paint.

CDN и on-the-fly transform. Cloudinary, imgproxy, Thumbor, встроенные оптимизаторы хостинга — один оригинал, много форматов по Accept-заголовку (Accept: image/avif,image/webp,*/*).

Кеширование. Долгий Cache-Control для hashed URL (hero.a1b2c3.avif). При смене картинки меняйте hash, а не полагайтесь на purge вручную.

Width/height. Явные размеры предотвращают CLS — layout shift при lazy decode. В Astro 5 и Next Image это делают автоматически при известных dimensions.

На stuzhuk.page обложки блога — WebP в /assets/img/blog/; тот же принцип масштабируйте на свой проект.

Типичные ошибки разработчиков

Один оригинал на все случаи. Upload 6000×4000 JPEG в CMS и resize только CSS — главная причина тяжёлых страниц. Режьте на сервере или при build.

PNG для всех иконок. 512×512 PNG на 80 КБ там, где SVG занял бы 2 КБ. Проверьте DevTools → Network.

AVIF без fallback. Пользователи старых Safari и embedded WebView увидят broken image, если <img src> указывает только на .avif.

GIF для длинной анимации. Мем на три секунды — ещё терпимо; демо продукта на 30 секунд — только video.

Игнор alt и декоративных изображений. Пустой alt="" для чистого декора; осмысленный alt для контентных фото — и SEO, и a11y.

Перекодирование JPEG→JPEG. Каждое сохранение добавляет потери. Храните master lossless или максимальное quality JPEG один раз.

Будущее форматов изображений

HDR станет нормой: дисплеи с высокой яркостью и AVIF/JXL с PQ-переносом уже готовы; контент и пайплайны догоняют. Форматы всё сильнее заимствуют у видеокодеков (AV1, будущие AV2) — единая экосистема encoder'ов для video + stills.

ИИ-компрессия (нейросетевые кодеки, super-resolution при decode) пока в исследованиях и проприетарных CDN, но через 3–5 лет может появиться в mass-market инструментах. Ожидайте гибриды: традиционный кодек + нейросетевое улучшение на клиенте.

JPEG как legacy — аналог MP3 в аудио: универсальный lowest common denominator ещё десятилетие. Новые форматы будут жить в <picture>, а не заменять JPEG в EXIF камер мгновенно.

Следите за поддержкой JPEG XL в Safari и за энкодерами AVIF с приемлемой скоростью в production (SVT-AV1, libavif speed presets).

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

Дополнительные материалы

Углубление по смежным темам на stuzhuk.page:

• Next.js: чеклист почти мгновенной загрузки — next/image, AVIF/WebP, LCP
• 8 правок производительности JavaScript в 2026 — lazy load, приоритет hero
• SEO, AEO, GEO и AISO — Core Web Vitals как часть видимости
• Почему сайт переписан на Astro — статика и оптимизация assets
• Сборка современного стека на Vite — pipeline фронтенда

Внешние ресурсы: Can I use — AVIF, web.dev — Choose the right image format, спецификация AVIF (AOM).

Заключение

История форматов — история компромиссов: BMP принёс простоту и гигабайты; GIF и PNG разделили анимацию и прозрачность; JPEG сделал фото массовым; WebP, HEIC, AVIF и JPEG XL борются за каждый килобайт в эпоху mobile-first. В 2026 году выигрывает не тот, кто выбрал «самый новый» кодек, а тот, кто выстроил каскад форматов, responsive delivery и честные fallback'и.

На этой неделе: проверьте hero главной страницы — есть ли AVIF/WebP, корректный sizes, fallback JPEG и фиксированные dimensions. Один такой аудит часто даёт больше, чем смена фреймворка.