WebP, JPEG, PNG чи AVIF: як обрати формат зображень для швидкого сайту

Питання «який формат зображення найкращий для сайту?» здається простим, але універсальної відповіді немає. Фотографія товару, логотип із прозорим фоном, скриншот інтерфейсу та великий банер мають різну структуру пікселів і різні вимоги до якості. Формат, який чудово стискає пейзаж, може створити ореоли навколо дрібного тексту. Безвтратний файл збереже кожен піксель, але виявиться у кілька разів важчим, ніж потрібно для звичайного фото.

Для більшості сучасних сайтів практичне рішення — не обрати один формат назавжди, а побудувати правила: AVIF або WebP для оптимізованої доставки, JPEG чи PNG як сумісний оригінал або fallback, SVG для векторної графіки та кілька розмірів кожного важливого зображення. У цьому матеріалі розберемо WebP, JPEG, PNG і AVIF, їхні сильні сторони, обмеження та вплив на швидкість сторінки.

Спочатку визначте тип зображення

Розширення файла — лише один параметр. Перед конвертацією потрібно зрозуміти, що саме містить зображення і як воно показуватиметься. Для фотографій характерні тисячі кольорів, плавні переходи й природний шум. Інтерфейсні скриншоти мають рівні площини, гострі межі та текст. Логотипи часто потребують прозорості й ідеально чітких контурів.

Растрова чи векторна графіка

WebP, JPEG, PNG та AVIF — растрові формати: вони зберігають сітку пікселів. Якщо збільшити невеликий файл, він втратить різкість. Для логотипів, піктограм і простих схем зазвичай краще SVG, бо вектор масштабується без втрати якості. Растер доречний для фотографій, складних текстур, живопису й зображень, які неможливо компактно описати геометричними фігурами.

Втратне і безвтратне стиснення

Втратний алгоритм видаляє частину інформації, яку людина, ймовірно, не помітить. Так працюють JPEG, lossy WebP і lossy AVIF. Чим сильніше стиснення, тим менший файл, але тим вищий ризик блоків, розмиття, смуг у градієнтах і зміни кольорів. Безвтратне стиснення відновлює початкові значення пікселів; його підтримують PNG, lossless WebP та lossless AVIF.

Безвтратний не завжди означає кращий

Для фотографії різниця між якісним lossy-файлом і lossless-версією часто непомітна на реальному екрані, зате різниця у вазі значна. Безвтратний режим виправданий, коли важливий кожен піксель: для технічної графіки, знімків із текстом, проміжного майстер-файла або зображення, яке ще редагуватимуть.

JPEG як передбачувана база для фотографій

JPEG десятиліттями залишається стандартним форматом фотографій у вебі. Він підтримується практично скрізь, швидко кодується й декодується, а інструменти для роботи з ним є в будь-якому редакторі та CMS. Для фото без прозорості правильно оптимізований JPEG досі може бути раціональним рішенням, особливо як fallback.

Де JPEG працює добре

• фотографії людей, інтер'єрів, природи й товарів;
• великі зображення з плавними переходами кольору;
• email-розсилки та зовнішні системи з невідомою підтримкою нових форматів;
• резервний варіант усередині елемента <picture>.

Progressive JPEG може показувати грубе попереднє зображення до завершення завантаження. Це не зменшує кількість байтів автоматично, але іноді покращує суб'єктивне відчуття швидкості.

Обмеження JPEG

JPEG не підтримує альфа-канал, тому не підходить для прозорого фону. На логотипах, тексті, тонких лініях і контрастних межах втратне стиснення створює помітні артефакти. Повторне збереження вже стисненого JPEG погіршує його ще раз, тому робочий оригінал краще тримати у форматі без втрат.

Коли не треба конвертувати JPEG повторно

Якщо є лише готовий JPEG, не слід спочатку стискати його сильніше, а потім перетворювати на WebP чи AVIF. Кожен втратний етап накопичує дефекти. Генеруйте веб-версії з RAW, TIFF, PNG або максимально якісного початкового файла.

PNG для прозорості та чітких деталей

PNG використовує безвтратне стиснення й підтримує альфа-канал. Він добре зберігає рівні кольори, дрібний текст, лінії та прозорі краї. Саме тому PNG часто використовують для скриншотів, схем, растрових логотипів і графічних елементів інтерфейсу.

Коли PNG виправданий

PNG доречний, якщо зображення має небагато кольорів, прозорість або піксельні деталі, які не повинні змінюватися. Для навчальної статті зі скриншотами він може бути надійним майстер-форматом. Водночас для доставки браузеру lossless WebP нерідко створює менший файл із тим самим візуальним результатом.

Чому фотографія в PNG майже завжди зайва

Безвтратне кодування складної фотографії з мільйонами відтінків дає великий файл. Якщо прозорість не потрібна, JPEG, WebP або AVIF забезпечать значно кращий баланс. Винятком може бути архівний оригінал, але його не варто віддавати відвідувачеві напряму.

PNG-8 і PNG-24

Палітровий PNG-8 економний для простої графіки з обмеженою кількістю кольорів. PNG-24 зберігає повноколірне зображення, але важить більше. Сучасний конвеєр оптимізації може автоматично вибирати палітру, видаляти зайві метадані та стискати структуру без зміни пікселів.

WebP як універсальний формат для більшості сайтів

WebP підтримує втратне й безвтратне стиснення, прозорість та анімацію. За даними офіційної документації Google, lossy WebP у тестах давав файли на 25–34% менші за порівнювані JPEG при еквівалентному показнику якості, а lossless WebP — на 26% менші за PNG. Конкретний результат залежить від зображення та параметрів енкодера, тому ці числа не слід сприймати як гарантію для кожного файла.

Сильні сторони WebP

Формат підходить і для фотографій, і для прозорої растрової графіки. Він має широку підтримку в сучасних браузерах, швидко декодується та інтегрований у більшість популярних CMS, CDN і бібліотек обробки зображень. Це робить WebP безпечним базовим вибором для нового корпоративного сайту.

Де WebP може бути не найкращим

AVIF іноді стискає фотографії ефективніше. PNG може бути простішим для обміну майстер-файлами або спеціального програмного забезпечення. Для дуже старих браузерів, поштових клієнтів чи сторонніх каналів може знадобитися JPEG або PNG. Також автоматична конвертація не гарантує, що WebP стане меншим: проста палітрова PNG-графіка іноді вже оптимальна.

WebP не скасовує контроль якості

Налаштування quality у різних енкодерах не є універсальною шкалою. Значення 80 у JPEG і 80 у WebP не описують однакову візуальну якість. Порівнюйте результат на типових екранах, особливо обличчя, волосся, дрібні написи, червоні контури та плавні градієнти.

AVIF для максимальної ефективності

AVIF базується на відеокодеку AV1 і підтримує втратне та безвтратне стиснення, прозорість, HDR, широкий колірний діапазон і кілька зображень у контейнері. У багатьох фотографічних сценаріях він дає менший файл, ніж JPEG або WebP, за схожої візуальної якості. Огляд можливостей доступний у матеріалі web.dev про AVIF.

Коли AVIF приносить найбільшу користь

AVIF варто тестувати для великих hero-зображень, фотографій каталогу, редакційних фото й сторінок із великою кількістю медіа. Економія на одному маленькому прев'ю може бути несуттєвою, а на десятках великих фотографій — помітною для мобільного користувача.

Компроміси AVIF

Кодування AVIF складніше й зазвичай повільніше, ніж JPEG або WebP. Це важливо, якщо сайт генерує багато варіантів одразу після завантаження. За агресивного стиснення можуть зникати дрібні текстури або з'являтися неприродна гладкість. Підтримка у сучасних браузерах уже широка, але для старих клієнтів доцільно залишати fallback.

Не використовуйте AVIF автоматично для всього

На маленьких іконках, лінійній графіці та зображеннях із текстом службові дані контейнера й особливості кодування можуть не дати переваги. Порівнюйте AVIF із WebP і PNG на конкретних класах контенту, а не лише на одному тестовому фото.

Швидке порівняння форматів

Формат	Стиснення	Прозорість	Найкращі сценарії	Основне обмеження
JPEG	Втратне	Ні	Фото, fallback, зовнішні канали	Артефакти на тексті та краях
PNG	Безвтратне	Так	Скриншоти, графіка, прозорі елементи	Великий розмір фотографій
WebP	Втратне і безвтратне	Так	Універсальна веб-доставка	Не завжди найменший файл
AVIF	Втратне і безвтратне	Так	Великі фото, каталоги, hero	Повільніше кодування

Правильна доставка через picture

Елемент <picture> дозволяє запропонувати браузеру кілька форматів. Браузер обере перше джерело, яке підтримує, а вкладений <img> залишиться fallback і збереже семантику, alt, розміри та поведінку завантаження.

<picture>
  <source type="image/avif" srcset="hero.avif">
  <source type="image/webp" srcset="hero.webp">
  <img src="hero.jpg" width="1280" height="720"
       alt="Опис зображення">
</picture>

Порядок має значення: найефективніший бажаний формат ставлять першим, fallback — останнім. Сервер не повинен називати JPEG-файл розширенням AVIF; правильний MIME type і реальний вміст обов'язкові.

Коли достатньо одного WebP

Якщо аудиторія використовує сучасні браузери, а сайт не вбудовується у старі WebView чи поштові шаблони, один WebP може бути прагматичним рішенням. Менше варіантів спрощує кешування, зберігання та адміністрування. Рішення варто приймати за аналітикою реальних пристроїв.

Art direction і формат — різні задачі

<picture> також може віддавати різні кадрування для мобільного та десктопного екрана. Це називається art direction. Формат відповідає за кодування, а media-умова — за композицію. Не слід замінювати широкий банер на мобільному простим стисканням до вузької колонки, якщо головний об'єкт стає нерозбірливим.

Розміри важать не менше за формат

Зображення шириною 4000 пікселів залишиться надмірним навіть у AVIF, якщо на сторінці воно показується у блоці 600 пікселів. Найбільшу економію часто дає правильна геометрія, а вже потім формат і quality.

Використовуйте srcset і sizes

srcset містить кілька ширин, а sizes підказує браузеру приблизний розмір зображення в макеті. Браузер враховує ширину viewport і щільність пікселів та завантажує придатний файл.

<img
  src="photo-960.webp"
  srcset="photo-480.webp 480w,
          photo-960.webp 960w,
          photo-1600.webp 1600w"
  sizes="(max-width: 700px) 100vw, 50vw"
  width="960" height="640" alt="...">

Завжди задавайте width і height

Атрибути розмірів дозволяють браузеру зарезервувати пропорційне місце до завантаження файла. Це зменшує layout shift і покращує стабільність сторінки. CSS усе одно може зробити зображення адаптивним через max-width:100% і height:auto.

Щільність 2x не означає подвоїти все

Для дуже деталізованого фото на Retina-екрані більша версія корисна, але різниця між 2x і 3x може бути непомітною при звичайній відстані перегляду. Перевіряйте візуально й не створюйте гігантські варіанти без потреби.

Вплив на Core Web Vitals

Велике зображення у першому екрані часто стає елементом Largest Contentful Paint. Менший файл може скоротити час завантаження, але LCP залежить також від моменту виявлення ресурсу, пріоритету, відповіді сервера й рендерингу.

Не застосовуйте lazy loading до hero

Головне зображення першого екрана потрібно виявити якомога раніше. Для нього зазвичай не використовують loading="lazy"; за потреби додають fetchpriority="high". Нижні галереї, фото в статті й картки поза viewport можна завантажувати ліниво.

Не ховайте важливий hero лише в CSS

Фонове зображення з CSS браузер знаходить пізніше, ніж звичайний <img> у HTML. Якщо hero є змістовним і потенційно стає LCP, семантичний img або picture часто простіше оптимізувати. Декоративний фон без інформаційної ролі може залишатися в CSS.

Preload використовуйте вибірково

Попереднє завантаження допомагає критичному ресурсу, але надлишок preload конкурує за мережу зі шрифтами, CSS та іншими важливими файлами. Не потрібно пріоритизувати всю галерею.

Якість потрібно оцінювати очима й метриками

Найменший файл не завжди найкращий. Якщо товар виглядає пластиковим, градієнт має смуги, а текст на скриншоті розмився, економія шкодить бізнесу. Порівнюйте кандидати в однаковому фізичному розмірі на мобільному й десктопному екранах.

Де шукати артефакти

• волосся, трава, тканина й дрібні повторювані текстури;
• червоні елементи на контрастному тлі;
• тіні та плавні градієнти неба;
• тонкі лінії, піктограми та текст;
• напівпрозорі краї й тіні навколо об'єкта.

Не порівнюйте лише однаковий quality

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

SEO та доступність зображень

Формат сам по собі не забезпечує позицій, але швидша сторінка і стабільний макет покращують досвід. Пошуковій системі також потрібні зрозумілий контекст, доступна URL і коректний alt.

Пишіть змістовний alt

Альтернативний текст описує функцію або зміст зображення для користувача, який його не бачить. Не вставляйте список ключових слів. Декоративне зображення може мати порожній alt="", а текст на інформаційній схемі повинен бути доступний і в HTML.

Використовуйте стабільні адреси

CDN або CMS можуть генерувати варіанти динамічно, але URL мають бути кешованими й передбачуваними. Не змінюйте адресу при кожному запиті. Після заміни важливого зображення оновіть sitemap та перевірте, що старі посилання не повертають помилки.

Якщо важкі картинки вже впливають на швидкість та індексацію, SEO-аудит сайту допоможе визначити LCP-елементи, неправильні розміри, відсутність lazy loading та інші технічні причини.

Автоматизація в CMS і на сервері

Ручна оптимізація працює для десяти файлів, але не для каталогу з тисячами товарів. Надійна система зберігає один якісний оригінал, а під час завантаження або першого запиту створює потрібні формати, ширини й кадрування.

Що повинен робити конвеєр

1. перевіряти тип, розмір і безпеку завантаженого файла;
2. виправляти орієнтацію за EXIF;
3. зберігати майстер окремо від публічних копій;
4. генерувати AVIF, WebP та fallback за визначеними правилами;
5. створювати кілька ширин без збільшення малого оригіналу;
6. видаляти непотрібні метадані, але зберігати потрібний ICC-профіль;
7. записувати width, height і alt у модель контенту;
8. кешувати результат у CDN та очищати за версією файла.

Генерація під час завантаження чи на вимогу

Попередня генерація дає передбачувану швидкість віддачі, але займає місце й час навіть для невикористаних варіантів. Генерація на вимогу економить сховище, проте перший запит може бути повільним і потребує захисту від масового створення довільних розмірів. Часто використовують гібрид: основні розміри створюються одразу, рідкісні — через image CDN.

Для інтернет-магазину автоматизація особливо важлива: одна фотографія товару може показуватися в мініатюрі, картці, галереї, рекомендаціях і Open Graph.

Типові помилки

• змінити розширення файла без реального перекодування;
• завантажувати оригінал 5000 px для прев'ю 300 px;
• перетворювати логотип на втратний JPEG;
• конвертувати вже пошкоджений JPEG у ще нижчу якість;
• віддавати AVIF без fallback старим клієнтам, які важливі для проєкту;
• використовувати lazy loading для головного LCP-зображення;
• не задавати width і height;
• зберігати однакову якість для фото, скриншотів і прозорої графіки;
• оптимізувати лише обкладинку, ігноруючи галереї та сторонні віджети.

Практична схема вибору

Для фотографій і hero

Почніть із AVIF, додайте WebP і за потреби JPEG fallback. Перевірте різницю у вазі та деталях. Для критичного hero створіть точні мобільне й десктопне кадрування, задайте розміри та не застосовуйте lazy loading.

Для скриншотів та інтерфейсів

Порівняйте PNG, lossless WebP і lossless AVIF. Якщо текст лишається чітким у якісному lossy WebP, можна використати його, але рішення приймайте після перегляду при масштабі 100%. Важливий текст дублюйте в HTML.

Для прозорих об'єктів

Використовуйте WebP або AVIF з alpha, а PNG залишайте як майстер чи fallback. Перевіряйте напівпрозорі тіні на світлому й темному фоні. Для простого логотипа оберіть SVG.

Для великого каталогу

Налаштуйте автоматичні пресети за роллю зображення, а не один параметр quality для всіх. Вимірюйте середню вагу сторінки, cache hit rate, час генерації та LCP. Якщо платформа не підтримує такий процес, це слід врахувати під час розробки сайту або його технічної модернізації.

Рекомендація для більшості проєктів

WebP є найпростішим універсальним стандартом доставки для сучасного сайту: він підходить для фото й прозорої графіки, добре підтримується та легко автоматизується. AVIF варто додати там, де він дає помітну економію на великих фотографіях. JPEG залишається надійним fallback і форматом обміну, а PNG — рішенням для безвтратної графіки, прозорості та майстер-файлів.

Але швидкий сайт створює не саме розширення. Потрібні правильні фізичні розміри, responsive variants, розумна якість, раннє завантаження LCP, lazy loading нижнього контенту, стабільний макет, кешування й автоматичний конвеєр. Найкращий формат — той, що виконує вимоги конкретного зображення з найменшою реальною вагою та без видимого погіршення.