Оптимізація зображень у 2026 році зводиться до чотирьох речей: формату AVIF (Baseline Widely available з 25 липня 2026), елемента <picture> з fallback на WebP, атрибуту fetchpriority="high" для LCP-зображення й адаптивних srcset/sizes. Разом вони зменшують вагу зображень на 40–60% проти JPEG без візуальних втрат. За даними Web Almanac 2025, зображення є LCP-елементом на 85% десктопних і 76% мобільних сторінок, тож правильна робота з ними, чесно кажучи, найшвидший спосіб покращити Largest Contentful Paint.
AVIF стискає фото на 20–30% сильніше за WebP і на 40–60% сильніше за JPEG при однаковій візуальній якості за SSIM.
З 25 липня 2026 AVIF отримує статус Baseline Widely available (Chrome 85+, Firefox 113+, Safari 16.4+, Edge 121+), тож його вже безпечно віддавати як основний формат.
LCP-зображення повинно мати fetchpriority="high" і ніколиloading="lazy". Протилежне сповільнює LCP на 200–800 мс.
Для fluid-зображень використовуйте srcset з дескрипторами w і sizes. Браузер сам врахує devicePixelRatio.
Client Hints Sec-CH-DPR у 2026 так і не з'явилися в жодному браузері, тож не витрачайте на них час.
JPEG XL все ще позаду: у Chrome 145 (лютий 2026) увімкнено лише за прапорцем, у Firefox 152 через Labs. На продакшн-сайтах поки що недоречний.
Що таке оптимізація зображень у 2026 році
Коли я профілюю сайт у DevTools і бачу LCP 3.4 с, у 85% випадків винне одне зображення. Героїчний банер, віддається як JPEG на 480 КБ, декодується на main thread десь між domContentLoaded і load. Оптимізація зображень, як з'ясувалося, це не просто «стисніть у TinyPNG». Це п'ять окремих рішень, які приймаються на різних тредах: вибір формату (кодек, енкодер, threading), розмір і кількість варіантів у srcset, стратегія завантаження (eager vs lazy), пріоритет мережевого запиту (fetchpriority) і декодування (decoding="async" vs sync).
У 2026 році ландшафт нарешті стабілізувався. AVIF офіційно стає Baseline Widely available 25 липня, fetchpriority вже Baseline у всіх основних браузерах, а sizes="auto" дозволяє браузеру визначити реальний розмір lazy-images без ручного розрахунку vw. Виграш вимірюваний: перехід із JPEG на AVIF для hero-зображення 1600×900 типово скидає близько 180 КБ мережі, приблизно 90 мс у Time to First Byte для критичного ресурсу і десь 40 мс blocking time на слабких Android-пристроях.
AVIF проти WebP: порівняльна таблиця для 2026
Кожні три місяці мене питають одне й те саме: «AVIF чи WebP у продакшні?». Коротка відповідь на середину 2026: обидва, через <picture>. AVIF як основний, WebP як fallback для старих Safari й непередбачених випадків. Ось як вони порівнюються за реальними метриками, які я знімаю з libavif 1.3 і libwebp 1.5.
Характеристика
AVIF
WebP
Baseline статус (2026-07)
Widely available з 25.07.2026
Widely available (~96,15% global)
Стиснення проти JPEG (SSIM-matched)
−40 до −60%
−25 до −34%
Стиснення проти WebP
−20 до −30%
базова лінія
Час кодування (проти JPEG)
~5–10× повільніше
~1,5–2× повільніше
10-bit / HDR
Так
Ні
Прогресивне декодування
Обмежене
Ні
Ліцензія / роялті
AOMedia, royalty-free
BSD-style, royalty-free
Найкраще для
Фото, градієнти, hero-банери
UI-графіка, thumbnails
Одне зауваження, яке ніхто не любить чути: AVIF повільно кодується, і це має значення для build-часу. Якщо ви пре-генеруєте варіанти в CI, 5000 зображень на однопоточному avifenc це 40+ хвилин. Ставте --jobs 0, щоб використати всі ядра, або запускайте в паралель через xargs -P. На runtime image CDN різниця в кодуванні не грає ролі, бо його результат кешується.
Правильна розмітка <picture> з fallback
Канонічний патерн для 2026: <picture> з <source type="image/avif">, <source type="image/webp"> і <img> як JPEG-fallback. Браузер бере перший підтримуваний type і завантажує саме його. Жоден зайвий байт не летить у мережу.
Тут дві школи. Одна пише srcset="[email protected] 1x, [email protected] 2x", це x-дескриптори, вони працюють для fixed-size assets: логотипи, іконки, аватарки. Друга пише srcset="foo-400.jpg 400w, foo-800.jpg 800w" sizes="50vw", це w-дескриптори, і саме вони потрібні для fluid-зображень, які змінюють розмір під viewport. Ніколи не змішуйте два підходи в одному srcset.
З w-дескрипторами браузер сам множить обраний sizes на devicePixelRatio. Тобто якщо на телефоні з DPR 3 sizes обчислюється у 360 CSS px, браузер шукатиме кандидата з мінімум 1080 фізичних px. Це головна причина, чому w точніший за x: він масштабується під будь-який пристрій без вашого втручання.
Що таке sizes="auto" і коли його використовувати
sizes="auto" це коли ви кажете браузеру: «сам визнач, скільки місця займе картинка після layout». Chrome/Edge підтримують з версії 126 (червень 2024), Firefox з 150 (квітень 2026), Safari ще ні. Атрибут працює тільки для loading="lazy" зображень, бо для eager-зображень браузер не знає layout на момент preload scanner.
<!-- Прогресивне покращення: auto для сучасних, fallback для Safari -->
<img
src="/img/gallery/photo-800.avif"
srcset="/img/gallery/photo-400.avif 400w,
/img/gallery/photo-800.avif 800w,
/img/gallery/photo-1200.avif 1200w"
sizes="auto, (max-width: 960px) 100vw, 320px"
loading="lazy"
decoding="async"
width="800"
height="600"
alt="Фотографія з галереї">
Синтаксис sizes="auto, fallback" означає, що браузер із підтримкою бере auto, всі інші беруть частину після коми як звичайний sizes. WordPress 6.7 адоптував цей патерн у Q1 2025, і я рекомендую те саме будь-якому CMS.
loading="lazy" і fetchpriority: як не зіпсувати LCP
Найпоширеніша помилка, яку я бачу у 2026, це універсальне правило «додати loading="lazy" на всі зображення». Web Almanac 2025 зафіксував: приблизно 16% сторінок lazy-loading'ять власний LCP-елемент. Наслідок такий, що LCP стрибає на 200–800 мс, бо preload scanner ігнорує lazy-images.
Second-hero (наприклад, велике фото в другому екрані): звичайне eager без fetchpriority, з decoding="async".
fetchpriority="high" це не «завантаж швидше», це «перемісти цей ресурс на початок черги пріоритетів». Використовуйте рівно один раз на сторінку. Якщо позначите п'ять зображень як high, ефект нівелюється, бо вони знову конкурують між собою. Детальний розбір семантики див. в офіційній документації web.dev по Fetch Priority.
Image CDN у 2026: Cloudflare, Cloudinary, Vercel, imgix
Ручна пре-генерація трьох форматів × п'ятьох ширин × десятків тисяч зображень швидко перестає масштабуватися. Image CDN виконує ту саму роботу on-demand: приймає URL з параметрами (?w=800&format=auto&quality=75), кодує на своєму edge, кешує результат. Ось як виглядає ринок у 2026.
Провайдер
Модель ціни (2026)
Free tier
Особливості
Cloudflare Images
$0,50/1K трансформацій + $5/100K stored
5K трансформацій/міс
Найдешевше для великого volume; вбудовано в Cloudflare CDN
Cloudinary
Credit-based; Plus $99, Advanced $249/міс
25 credits/міс
Найбагатший API (AI-crop, background removal)
Vercel Image Optimization
Hobby free; Pro $0,05–$0,081/1K + метрика cache
5K трансформацій
Тісна інтеграція з Next.js Image
Netlify Image CDN
~20 credits/GB bandwidth (без per-transform)
В межах Netlify tier
Просте налаштування, ділить credits з іншими фічами
imgix
Starter $25/міс (100 credits), Growth $300/міс
Trial
Найзріліший продукт, найбільше форматів на вході
За моїм досвідом, для сайту з 1–10 млн переглядів на місяць Cloudflare Images виграє економічно, якщо ви вже на Cloudflare. Cloudinary виправданий, коли потрібні AI-фічі (autocrop, upscale). Vercel Image беззаперечний вибір, якщо ви на Next.js і не хочете керувати нічим окремо.
Клієнтські Client Hints у 2026: спойлер, забудьте
У 2020–2022 багато хто (я включно) ставив на DPR, Width, Viewport-Width HTTP-заголовки з Accept-CH. У 2023 їх задепрекейтили на користь Sec-CH-DPR, Sec-CH-Viewport-Width. У 2026 жоден з цих Sec-CH-* так і не імплементований у Chrome, Firefox чи Safari. Не інвестуйте час у client-hints-based image serving, робіть DPR через srcset. Це офіційна позиція Chrome команди.
JPEG XL у 2026: чи час використовувати?
JPEG XL цікавий формат. Він на 10–30% менший за AVIF на фото, підтримує lossless-контейнер для існуючих JPEG (стискає їх додатково на ~15–22% без втрати якості) і має дуже швидкий encoder. Проблема одна: підтримка. Станом на липень 2026:
Safari 17+, нативна підтримка (~13,6% глобального usage).
Chrome 145 (лютий 2026), за прапорцем chrome://flags/#enable-jxl, не за замовчуванням.
Firefox 152 (червень 2026), доступно через Labs, off by default.
Це не Baseline і не буде найближчим часом. Використовувати JPEG XL у продакшні можна, тільки як додатковий <source type="image/jxl">перед AVIF у <picture>. Ефект від нього поки що вимірюється у частках відсотка глобального трафіку. Формально специфікація AVIF від AOMedia залишається технічним референсом для більшості нових проєктів у 2026.
Практичні поради з кодування AVIF
Я перепрофілював десятки pipeline на своїх клієнтах і зібрав перелік того, що дійсно змінює якість, розмір і швидкість.
--speed має діапазон 0–10, де 0 найповільніший і найкраще стиснення, а 10 найшвидший і найгірше. Значення 6 це золота середина для CI: приблизно у 3× швидше за 0 при +2–4% розміру. --jobs 0 віддає всі ядра енкодеру.
Якість (QP)
Замість «якість 75» у AVIF використовується --min/--max QP (quantization parameter, 0–63, де менше = краще). Мої дефолти:
Фото: --min 20 --max 30, приблизно еквівалент JPEG q=80.
UI-скріншоти: --min 15 --max 25, уникає артефактів на тексті.
Іконки з прозорістю: --min 10 --max 20.
Chroma subsampling
--yuv 420 це стандарт для фото, зменшує розмір на ~15–25%. Для скріншотів UI з дрібним текстом переходьте на --yuv 444: без цього тонкі лінії розмиваються. Різниця у вазі приблизно 30–40%, але візуально це різниця між читабельним і нечитабельним.
Як виміряти вплив на Core Web Vitals
Змінити формат це половина справи. Друга половина: виміряти, що зміна дала. Мій воркфлоу після кожної image-оптимізації:
Lighthouse у DevTools (mobile, Slow 4G throttling) до і після. Дивитеся на LCP, TBT і Total Bytes. Це синтетичний тест, але порівнюваний.
Chrome Performance panel. Записуєте трасу, шукаєте event "Largest Contentful Paint". Він показує URL LCP-елемента, час до нього, і що його блокувало. Якщо ваш AVIF hero ще й досі LCP-кандидат, але тепер за 800 мс замість 1900, ви виграли.
Field data з CrUX через тиждень після деплою. Реальні користувачі показують реальний ефект. Синтетика часто занижує виграш, бо не враховує CPU-bound декодинг на низькокласних Android.
Network waterfall. Порівняйте пріоритети запитів у Network, колонка Priority. LCP-image має бути High. Якщо він Low або Medium, значить fetchpriority не прочитався.
Один нюанс, який часто ігнорують: image decoding відбувається на main thread за замовчуванням. У Performance panel це видно як події Decode Image, які часто займають 20–80 мс на mid-range Android. decoding="async" переносить декодинг у compositor thread. Це чиста перемога, використовуйте завжди. Якщо ви серйозно оптимізуєте час до першої взаємодії, паралельно з зображеннями подивіться гід з оптимізації TTFB. Часто найбільший виграш ховається не в форматі, а в тому, як швидко байти взагалі доходять до клієнта.
Часті запитання
AVIF кращий за WebP у 2026 році?
Так. При однаковій візуальній якості (SSIM-matched) AVIF стискає фотографії на 20–30% ефективніше за WebP і на 40–60% ефективніше за JPEG. Найбільша перевага AVIF на градієнтах і фото з великими однорідними ділянками. Для UI-графіки й іконок різниця менша (10–15%).
Чи всі браузери підтримують AVIF у 2026?
З 25 липня 2026 AVIF отримує статус Baseline Widely available: Chrome 85+, Firefox 113+, Safari 16.4 (iOS 16.1)+, Edge 121+. Це приблизно 93,4% глобального usage. Для решти 6,6% використовуйте <picture> з WebP і JPEG fallback.
Чи псує loading="lazy" LCP?
Так, якщо застосувати до самого LCP-елемента. Web Almanac 2025 зафіксував: ~16% сторінок лениво завантажують свій LCP-image, і це збільшує LCP на 200–800 мс. Правило: LCP-зображення завжди eager і з fetchpriority="high". Лениво завантажуйте тільки below-the-fold контент.
Що використовувати, srcset з x чи w дескрипторами?
x-дескриптори (1x, 2x) для fixed-size графіки: логотипи, іконки, аватарки. w-дескриптори (800w, 1600w) з sizes для fluid-зображень, що змінюють ширину під viewport. w-варіант точніший, бо браузер автоматично враховує devicePixelRatio. Ніколи не змішуйте два підходи в одному srcset.
Чи вартий JPEG XL використання у 2026?
Ще ні для продакшн-сайтів як основного формату. Safari 17+ підтримує нативно (~13,6% usage), Chrome 145 за прапорцем, Firefox 152 через Labs. Можна додати як необов'язковий <source type="image/jxl"> перед AVIF у <picture>, але поки що це trade-off у складності pipeline на мінімальний виграш.
Як зменшити Cumulative Layout Shift нижче 0.1 у 2026 році: розміри зображень, font metric overrides, реклама без зсуву, View Transitions API і налагодження в Chrome DevTools з робочими прикладами коду.
Speculation Rules API дає змогу попередньо завантажувати або повністю рендерити майбутні сторінки у фоні — і у 2026 році це найпростіший спосіб отримати майже миттєвий LCP. Розбираємо синтаксис, рівні eagerness, HTTP-заголовок Speculation-Rules та нову опцію Chrome 144.
TTFB напряму визначає, наскільки швидко браузер починає рендерити сторінку. У цьому гіді — як виміряти Time to First Byte, цільові пороги у 2026 році, і дев'ять перевірених стратегій оптимізації від Early Hints до edge-функцій.
