Ключові висновки

Формати — це компроміс, а не рейтинг. Кожен кодек оптимізує свій кут: розмір файлу, швидкість декодування на слабкому телефоні, підтримку прозорості, сумісність з архівами та камерами. «Перевести все на AVIF» без резервного варіанту ламає 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 з тисячами завантажень важливіший 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'и.

Для плоскої графіки, схем і pixel art GIF досі читабельний. Для фотографій — ні: dithering руйнує шкіру та небо. Анімований GIF часто важить більше, ніж той самий ролик у H.264 — кожен кадр стискається окремо.

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

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

JPEG не підтримує альфа-канал і анімацію. Логотип на прозорому тлі в JPEG неможливий — звідси пара PNG + JPEG. JPEG «переміг» через маленькі файли, миттєвий decode і підтримку в кожній камері.

PNG — без втрат і повна прозорість

PNG (1996) народився як патентно-вільна альтернатива GIF. Deflate-стиснення без втрат, повноцінний альфа-канал (256 рівнів прозорості). Ідеален для логотипів, іконок, скріншотів, UI-шарів.

Ціна — розмір на фото: PNG 4000×3000 легко перевищує 15–25 МБ, тоді як JPEG вкладеться в 2–4 МБ. PNG-8 економить місце для простих картинок.

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

Інтернет прискорюється, а зображення важчають

На початку 2000-х парадокс став очевидним: канали ширші, а сторінки не завантажуються пропорційно швидше. Причини — зростання роздільності моніторів, камер смартфонів, Retina-дисплеїв і full-bleed 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.

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

HEIF, часто з HEVC всередині, — стандарт Apple для фото з iPhone з iOS 11. Для вебу HEIC проблемний через патенти та слабку підтримку в Chrome/Firefox на десктопі. Робочий патерн — конвертувати upload у JPEG/WebP/AVIF на сервері.

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

AVIF (2019) упаковує кадри кодека AV1 — відкритого наступника VP9. На фото AVIF часто на 20–50 % менший за WebP і на 30–60 % менший за JPEG при порівнянній якості. Підтримуються 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); на старих Android decode AVIF помітніший за JPEG; деякі CMS ще не генерують AVIF при upload.

JPEG XL — потенціал без масової перемоги

JPEG XL проектувався як «справжня заміна JPEG»: lossy і lossless в одному файлі, progressive decode, HDR, альфа. Apple не прийняла JXL у Safari; Chrome експеримент закрили. У 2026 році JPEG XL — формат для ентузіастів і архівів.

Порівняльна таблиця (факти дубльовані в тексті):

SVG і коли вектор перемагає растр

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

Для фото SVG не підходить — растр усередині <image> не дає виграшу. Правило 2026: іконки і логотипи — SVG; фото — AVIF/WebP/JPEG; скріншоти з дрібним текстом — PNG або lossless WebP.

Inline SVG покращує доступність і SEO, якщо задати <title> і role="img".

Який формат обрати у 2026 році

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

Основний — AVIF. Резервний — WebP, потім JPEG. Генеруйте три версії при build або через image CDN. Не віддавайте 3000 px, якщо CSS показує 800 px.

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

SVG для простих форм. PNG коли потрібна pixel-perfect растрова графіка. Lossless WebP як легша альтернатива PNG. Уникайте JPEG для тексту.

Анімація

Замініть GIF на коротке loop-відео (<video autoplay muted loop playsinline>). WebP/AVIF animation для простих loader'ів.

Архів і вихідники

PNG або TIFF для мастер-копій без втрат. JPEG XL — якщо toolchain уже підтримує.

Коротко: 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.

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 стане нормою. Формати все сильніше запозичують у відеокодеків (AV1, майбутні AV2). ШІ-стиснення поки в дослідженнях, але через 3–5 років може з’явитися в mass-market інструментах. JPEG як legacy — аналог MP3: універсальний lowest common denominator ще десятиліття.

Часті питання

Чим AVIF кращий за WebP?

AVIF зазвичай дає на 20–50 % менший файл при тій самій якості, плюс краще підтримує HDR. WebP простіше і швидше кодуються.

Чи потрібно ще використовувати JPEG?

Так, як фінальний fallback у <picture> і для email-клієнтів, старих застосунків.

Чому iPhone зберігає HEIC, а сайт — ні?

Apple оптимізувала локальне сховище під HEVC. Веб уникає HEIC через патенти та фрагментовану підтримку браузерів.

PNG чи WebP lossless для скріншотів?

На сучасних браузерах lossless WebP часто на чверть менший за PNG. Для документації — PNG.

Який quality обрати для AVIF і WebP?

Для libaom AVIF почніть з cq 30–45; для cwebp — quality 75–85. Порівнюйте візуально на retina-дисплеї.

Чи замінить JPEG XL AVIF?

Поки ні. AVIF виграв за браузерною підтримкою; JPEG XL — теоретичною швидкістю decode.

Чи варто віддавати GIF у 2026 році?

Лише для email або legacy-чатів. На сайті — video loop або CSS.

Як формати пов’язані з Core Web Vitals?

LCP часто — велике зображення above-the-fold. Менший AVIF/WebP і правильний srcset прискорюють download; явні width/height зменшують CLS.

Додаткові матеріали

• Next.js: чеклист майже миттєвого завантаження
• 8 правок продуктивності JavaScript у 2026
• SEO, AEO, GEO і AISO
• Чому сайт переписано на Astro
• Збірка сучасного стеку на Vite

Зовнішні ресурси: Can I use — AVIF, web.dev — Choose the right image format.

Висновок

Історія форматів — історія компромісів: від BMP до AVIF і JPEG XL пройшло майже 40 років. У 2026 році виграє не той, хто обрав «найновіший» кодек, а той, хто побудував каскад форматів, responsive delivery і чесні fallback'и.

На цьому тижні: перевірте hero головної — чи є AVIF/WebP, коректний sizes, fallback JPEG і фіксовані dimensions.