Оптимізація зображень у 2026: AVIF, WebP та ліниве завантаження

Зображення залишаються найважчими ресурсами на більшості веб-сторінок. У наших проєктах у DigiForge ми регулярно бачимо, що зображення становлять значну частину загальної ваги сторінки. До 2026 року ландшафт усталився: AVIF та WebP — це два сучасні формати, до яких варто звертатися; адаптивні зображення через srcset стали стандартом, а відкладене завантаження настільки поширене, що неправильне його використання може навіть погіршити продуктивність. Ця стаття узагальнює наш практичний досвід у чіткий, авторський робочий процес, який можна застосувати до будь-якого проєкту.

Вибір правильного формату: AVIF проти WebP

Протягом багатьох років WebP був основним форматом наступного покоління. AVIF з'явився пізніше, обіцяючи краще стиснення та підтримку HDR, але з вищою вартістю кодування та підтримкою браузерів, яка досі не є універсальною (Safari був останнім, хто не підтримував). Ось стан справ у 2026 році:

• AVIF зазвичай забезпечує менші розміри файлів, ніж WebP, при однаковій сприйнятній якості. Він підтримує 10-бітний колір, HDR, безвтратну альфа-канал і навіть анімацію. Кодування значно повільніше, ніж у WebP, що робить його менш придатним для генерації в реальному часі, але цілком прийнятним для статичних ресурсів, що готуються на етапі збірки.
• WebP підтримується всіма сучасними браузерами. Він пропонує передбачувану якість, швидке кодування та чудові інструменти (cwebp, sharp, imagemin). Для сайтів з великою кількістю контенту, де швидкість кодування має значення, WebP досі є прагматичним вибором за замовчуванням.
• JPEG XL (JXL) демонстрував ранні перспективи, але так і не набув популярності серед браузерів. Chromium видалив його прапорець, а Safari ніколи не впроваджував його. Не витрачайте час на нього, доки ситуація не зміниться.

Наша рекомендація: Використовуйте AVIF із запасним варіантом WebP. Застосовуйте <picture>, щоб браузери спочатку вибирали AVIF, потім WebP, а потім оригінальний JPEG/PNG. Це максимізує стиснення для тих, хто може його отримати, і ніколи не залишає нікого без зображення. Більшість сучасних браузерів підтримують AVIF, тому запасний варіант важливий, але не є основним шляхом.

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="...">
</picture>

Адаптивні розміри: не лише srcset

Атрибут srcset з sizes добре відомий, але багато реалізацій, які ми перевіряємо, неправильно використовують sizes. Браузер використовує sizes, щоб визначити, який кандидат із srcset завантажити – це не просто рекомендація. Відсутній sizes за замовчуванням дорівнює 100vw, що може змусити браузер обрати найбільше зображення навіть на маленькому екрані, марнуючи пропускну здатність.

Для простих адаптивних зображень, де зображення масштабується разом із вікном перегляду, пишіть:

<img src="image-800.jpg" 
     srcset="image-400.jpg 400w, image-800.jpg 800w, image-1200.jpg 1200w"
     sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 33vw"
     alt="...">

Але є нюанс. sizes має відображати фактичну ширину CSS, яку займає зображення на кожній точці перелому, а не частку області перегляду. Для головного зображення, яке завжди на всю ширину, просто sizes="100vw" є правильним. Для галереї, де кожне зображення займає одну третину рядка, використовуйте 33vw. Якщо зображення має відступи або знаходиться всередині контейнера з максимальною шириною, потрібно обчислити фактичну відображувану ширину — іноді доводиться використовувати calc() у sizes.

Дескриптори ширини проти піксельної щільності

Використовуйте дескриптори w (наприклад, 400w) та sizes для гнучких зображень, чий розмір відображення змінюється залежно від макета. Дескриптори щільності (1x, 2x) підходять лише для зображень фіксованого розміру, таких як логотипи або іконки, де ви знаєте точні фізичні розміри. Для контентних зображень завжди використовуйте w — це дає браузеру справжню гнучкість для вибору найкращого кандидата на основі ширини області перегляду та коефіцієнта пікселів пристрою.

При використанні <picture> для вибору формату кожен <source> повинен мати власний srcset та опціональний sizes. Ви можете використовувати однаковий sizes для всіх джерел, якщо макет ідентичний, але уникайте непотрібного дублювання.

Ліниве завантаження: нативне, Intersection Observer чи обидва?

Нативне ліниве завантаження (loading="lazy") підтримується всіма основними браузерами з 2020 року. Це нуль JavaScript, працює із зображеннями та iframe і є найпростішим шляхом. Але на практиці воно має нюанси:

• Нативне ліниве завантаження відкладає завантаження доти, доки браузер не визначить елемент близьким до області перегляду. Поріг визначається браузером – Chrome використовує щедрий відступ для раннього завантаження; Firefox використовує менший відступ. Це означає, що зображення можуть завантажуватися пізніше, ніж очікувалося, у Firefox.
• У деяких ранніх реалізаціях воно не ідеально працює з srcset. Старі версії Safari (до 16.4) мали помилки. У 2026 році це рідкість, але все ж варто тестувати.
• Для елементів <picture> loading="lazy" слід вказувати на тегу <img>, а не на тегах <source>.

Ми використовуємо гібрид: нативне ліниве завантаження як базовий рівень, плюс легкий поліфіл Intersection Observer (IO) для старіших браузерів (хоча до 2026 року це рідкісний випадок). IO також може запускати анімацію появи або завантажувати низькоякісні заповнювачі. Наша реалізація:

const lazyImages = document.querySelectorAll('img[loading="lazy"]');

if ('loading' in HTMLImageElement.prototype) {
  // Native lazy loading works – do nothing extra
} else {
  const observer = new IntersectionObserver((entries) => {
    entries.forEach(entry => {
      if (entry.isIntersecting) {
        const img = entry.target;
        img.src = img.dataset.src;
        observer.unobserve(img);
      }
    });
  });
  lazyImages.forEach(img => observer.observe(img));
}

Збираємо все разом: практичний робочий процес

У DigiForge ми дотримуємося такого конвеєра для кожного проєкту, незалежно від того, чи це статичний сайт, сайт на CMS або вебзастосунок:

1. Вихідні зображення: Дизайнери надають у високій роздільній здатності PNG або TIFF. Ми зберігаємо оригінали в папці _originals для майбутнього перестискання, якщо з'являться нові формати.
2. Генерація форматів: Використовуємо Node.js скрипт із sharp або Makefile з ImageMagick для створення AVIF, WebP та запасних JPEG/PNG у 3–5 ширинах (наприклад, 480, 800, 1200, 1920). Для великих проєктів запускаємо це паралельно, використовуючи робочі потоки для прискорення збірки.
3. Налаштування якості: Запускаємо CI-перевірки, які порівнюють розмір файлу з перцептивною метрикою (SSIM або Butteraugli). Ми блокуємо pull request, якщо загальна вага зображень для типової сторінки перевищує розумний поріг залежно від типу контенту.
4. Розмітка: Генеруємо <picture> із порядком type (AVIF, WebP, запасний) та <img> з loading="lazy" (крім першого героя). Для адаптивних розмірів генеруємо sizes на основі фактичного CSS – це часто надходить із файлу токенів дизайну, спільного для дизайну та розробки.
5. Обслуговування через CDN: Для статичних сайтів ми обслуговуємо попередньо закодовані ресурси через CDN із довгими заголовками кешу (наприклад, Cache-Control: public, max-age=31536000, immutable). Якщо використовується CDN зображень, як-от Cloudinary або imgix, багато кроків автоматизовано через URL-трансформації, але ми все одно попередньо кодуємо критичні зображення, щоб уникнути витрат на холодний старт.

Сайти на кшталт Unsplash [3] та Pixabay [1] надають зображення високої роздільності, які часто важать кілька мегабайт у сирому вигляді. Наш конвеєр значно зменшує їх без помітних втрат. Аналогічно, AI-генеровані зображення з інструментів на кшталт ChatGPT Images [4] часто виходять у високій роздільності без оптимізації, тому їх обробка через той самий робочий процес стиснення є критичною. Стокові зображення з Shutterstock [5] або Bing Images [2] мають схожі характеристики – великі файли, які можуть погіршити продуктивність, якщо їх не оптимізувати.

Типові помилки, які ми бачимо (і виправляємо)

• Повна відсутність sizes: Браузер завантажує найбільший кандидат із srcset, оскільки вважає, що ширина дорівнює 100vw. Завжди вказуйте sizes — навіть простий 100vw краще, ніж нічого.
• Використання JPEG для всього: Багато команд досі використовують лише JPEG. У 2026 році це вже не виправдано — WebP та AVIF є зрілими форматами, а зусилля для їх додавання мінімальні.
• Надмірне ліниве завантаження: Кожне зображення з loading="lazy" затримує перше значуще відтворення. Використовуйте loading="eager" для критичних зображень і розгляньте попереднє завантаження головного зображення за допомогою <link rel="preload" as="image" href="..."> для максимальної швидкості LCP.
• Відсутність запасного варіанту для анімованих форматів: Якщо використовується анімований AVIF (підтримка якого обмежена), передбачте запасний варіант у WebP або GIF через <picture>.
• Кодування зображень на льоту в серверних функціях: Кодування AVIF вимагає значних ресурсів CPU. Спалах запитів може призвести до тайм-аутів або зростання витрат. Завжди генеруйте ресурси заздалегідь під час збірки, за винятком зображень, завантажених користувачами, які не можна підготувати заздалегідь.

Ми також бачили команди, які покладаються на єдине джерело зображення без версіонування. Коли дизайнер оновлює головний банер, старий файл перезаписується, що ламає кеш CDN. Використовуйте хеші вмісту в іменах файлів (наприклад, hero-a1b2c3.avif), щоб нові версії отримували нову URL-адресу, а старі могли кешуватися безстроково.

Рекомендації щодо інструментів

Для розробників, які віддають перевагу CLI, cwebp (з libwebp) та avifenc (з libavif) є надійними та піддаються автоматизації. Для конвеєрів Node.js sharp не має рівних — він швидкий, працює з усіма форматами та може виводити AVIF (потребує libvips, зібраної з підтримкою AVIF). Для ad-hoc порівнянь ми використовуємо Squoosh або інструменти на кшталт icdif (Image Compare Diff).

Для великих проєктів варто розглянути CDN для зображень, як-от Cloudinary, imgix або Image Optimizer від Fastly. Вони автоматизують зміну розміру та узгодження форматів через параметри URL, а також часто обробляють кодування AVIF на власному кешувальному шарі, тому ви не платите за обчислення на вашому сервері. Однак слід пам'ятати про залежність від постачальника та вартість – для сайту з великою кількістю зображень щомісячний рахунок може бути значним. Ми часто рекомендуємо гібридний підхід: попередньо генеруйте найпоширеніші розміри та формати, а CDN нехай обробляє рідкісні точки зламу або завантаження користувачів.

Якщо ви використовуєте CMS або генератор статичних сайтів, існують плагіни для більшості фреймворків (наприклад, @next/image для Next.js, gatsby-plugin-sharp для Gatsby, eleventy-img для Eleventy). Вони автоматизують генерацію та розмітку, але ми все ж рекомендуємо перевіряти їхні налаштування якості за замовчуванням – вони часто є консервативними (без втрат або майже без втрат), щоб уникнути скарг, що може призвести до зайвих байтів.

Підсумок

Оптимізація зображень у 2026 році – це компроміси: AVIF економить найбільше байтів, але потребує більше обчислень; WebP – надійна золота середина. Адаптивні розміри мають бути точними, а не приблизними. Відкладене завантаження майже автоматичне, але потребує продуманого застосування, щоб не нашкодити LCP. Добре налаштований конвеєр обробки зображень може значно зменшити вагу сторінки – це прямий виграш для досвіду користувачів, Core Web Vitals та конверсії.

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