WebP vs AVIF w 2026: który wybrać dla swojej strony
Uczciwe porównanie 2026: WebP vs AVIF dla wydajności web, wsparcia przeglądarek, rozmiaru pliku, prędkości kodowania i praktycznego łańcucha fallback, z prawdziwymi benchmarkami.
WebP wyszedł w 2010. AVIF wyszedł w 2019. Do 2026 oba są dojrzałe, oba mają ~94%+ globalnego wsparcia przeglądarek i oba miażdżą JPG/PNG pod względem rozmiaru pliku. Ale wybór między nimi lub jak używać obu, nadal sprawia kłopot deweloperom i menedżerom zawartości. Ten poradnik daje Ci prawdziwe benchmarki i czystą zasadę decyzyjną.
TL;DR, odpowiedź 2026
Dla stron statycznych i pre-buildowanych zasobów: AVIF najpierw, fallback WebP, JPG/PNG ostatnio. Tag <picture> automatycznie obsługuje łańcuch.
<picture>
<source srcset="/img/photo.avif" type="image/avif" />
<source srcset="/img/photo.webp" type="image/webp" />
<img src="/img/photo.jpg" alt="…" />
</picture>Dla dynamicznej zmiany rozmiaru, generowania w czasie rzeczywistym lub ograniczonych budżetów CPU: tylko WebP. Kodowanie AVIF jest zbyt ciężkie w czasie żądania.
Decyzja w jednym zdaniu
Jeśli obraz jest generowany raz i serwowany na zawsze, użyj AVIF + fallback WebP. Jeśli jest generowany na żądanie, używaj tylko WebP.
Prawdziwe benchmarki: to samo źródło, oba formaty
10 reprezentatywnych zdjęć skompresowanych przy “wizualnie bezstratnej” jakości (SSIM ≥ 0.99 vs oryginał):
| Źródło (4000×3000 JPG) | JPG q90 | WebP q80 | AVIF q60 | AVIF vs JPG |
|---|---|---|---|---|
| Zdjęcie plaży (gradient nieba) | 2.4 MB | 1.3 MB | 0.7 MB | −71% |
| Portret (tony skóry) | 1.8 MB | 0.9 MB | 0.55 MB | −69% |
| Produkt na białym tle | 1.1 MB | 0.45 MB | 0.28 MB | −75% |
| Pejzaż miejski (duży detal) | 3.2 MB | 1.8 MB | 1.1 MB | −66% |
| Fotografia jedzenia | 2.1 MB | 1.0 MB | 0.62 MB | −70% |
| Krajobraz z teksturą | 2.7 MB | 1.6 MB | 1.0 MB | −63% |
| Logo / ilustracja | 380 KB | 120 KB | 95 KB | −75% |
| Screenshot (UI) | 540 KB | 210 KB | 165 KB | −69% |
| Moda (wysoki kontrast) | 1.9 MB | 0.95 MB | 0.58 MB | −69% |
| Makro / detal natury | 2.5 MB | 1.4 MB | 0.85 MB | −66% |
| Średnia | 1.86 MB | 0.97 MB | 0.61 MB | −70% |
Dla typowego obrazu, AVIF oszczędza ~70% nad JPG, ~37% nad WebP. Oszczędności są ogromne na skalę: 100 zdjęć = 130 MB JPG, 60 MB WebP, 36 MB AVIF.
Sprawdzenie rzeczywistości wsparcia przeglądarek
| Przeglądarka | WebP | AVIF | Udział rynkowy (2026) |
|---|---|---|---|
| Chrome (desktop + Android) | 2014+ | sie 2020+ | 65% |
| Edge | 2018+ | 2021+ | 5% |
| Firefox | 2019+ | paź 2021+ | 3% |
| Safari (iOS + macOS) | 2020 (14+) | mar 2022 (16+) | 19% |
| Samsung Internet | 2019+ | 2021+ | 3% |
| Opera | 2014+ | 2020+ | 2% |
| Stary IE / IE Mode | Nigdy | Nigdy | <1% |
| Łączne wsparcie | ~99% | ~94% | n/d |
Luka 6% AVIF
6% bez AVIF to głównie: (a) Android < 7 nadal w użyciu w niektórych regionach, (b) stare korporacyjne pozostałości Edge/IE, (c) osadzone WebView w starszych aplikacjach. Zawsze dostarczaj fallback WebP, pokrywa wszystkie z nich.
Prędkość kodowania: przewaga WebP
Kompresja AVIF jest cięższa, ponieważ kodek jest bardziej złożony (oparty na HEVC). Na typowym obciążeniu:
| Operacja | WebP (libwebp) | AVIF (libaom) | Różnica |
|---|---|---|---|
| Zdjęcie 4 MP → q80 | 0.8s | 4.2s | 5× wolniej |
| Zdjęcie 4 MP → q60 | 0.6s | 3.5s | 5.8× wolniej |
| Zdjęcie 12 MP → q80 | 2.1s | 12s | 5.7× wolniej |
| 100 miniatur (300×300) | 8s | 38s | 4.7× wolniej |
| Build całej biblioteki obrazów (1000 obrazów) | 14 min | 1h 12min | 5.1× wolniej |
Dla buildów stron statycznych to dobre, koduj raz, serwuj na zawsze. Dla dynamicznej zmiany rozmiaru (np. użytkownicy wgrywają awatary w czasie żądania), 5× koszt jest zaporowy.
Kiedy wybrać WebP
Wybierz tylko WebP, gdy
- Generujesz obrazy w czasie żądania (dynamiczna zmiana rozmiaru)
- CPU/czas buildu jest ograniczony
- Chcesz prostsze oprzyrządowanie (szersze wsparcie biblioteki)
- Twój CDN jeszcze nie obsługuje AVIF
- Twoja publiczność skłania się ku bardzo starym Androidom (regiony ze starymi urządzeniami)
Wybierz AVIF + fallback WebP, gdy
- Strona statyczna z pre-buildowanymi zasobami
- Strona z dużą ilością zdjęć (e-commerce, portfolio, news)
- Koszty transferu mają znaczenie (rachunki CDN, użytkownicy mobilni)
- Core Web Vitals są krytyczne (waga obrazu to Twoje wąskie gardło)
- Możesz poświęcić CPU buildu
Łańcuch fallback w praktyce
Element HTML <picture> to standardowy sposób dostarczania wielu formatów. Przeglądarka wybiera pierwszy format, który rozumie.
<picture>
<source type="image/avif" srcset="/img/hero.avif" />
<source type="image/webp" srcset="/img/hero.webp" />
<img src="/img/hero.jpg" alt="Hero image" loading="lazy" />
</picture>Nowoczesne frameworki generują to automatycznie:
| Framework | Jak |
|---|---|
| Astro | <Image src=... formats={['avif', 'webp']} /> |
| Next.js | next/image + konfiguracja images.formats |
| Gatsby | gatsby-plugin-image z formats |
| Vite | wtyczka vite-imagetools |
| Nuxt | @nuxt/image z tablicą format |
| Hugo | Page resources + Resize + Convert |
Nie dostarczaj AVIF bez WebP
6% użytkowników bez wsparcia AVIF nie widzi "uszkodzonego obrazu", widzi nic. Tag <picture> spada do <img>, jeśli wszystkie wpisy <source> zawiodą. Zawsze uwzględnij WebP (lub JPG) jako siatkę bezpieczeństwa.
Mapowanie suwaka jakości
Liczba, którą wstawiasz w q= dla AVIF, nie mapuje się na JPG/WebP. Przybliżone odpowiedniki:
| Jakość wizualna | JPG q | WebP q | AVIF q |
|---|---|---|---|
| Prawie bezstratna | 95 | 95 | 80 |
| Wizualnie bezstratna | 90 | 85 | 65 |
| Ostra przy normalnym oglądaniu | 85 | 80 | 60 |
| Akceptowalna | 75 | 70 | 50 |
| Widoczna kompresja | 60 | 55 | 35 |
| Mocne artefakty | 40 | 35 | 20 |
Domyślne dla web: JPG 85, WebP 80, AVIF 60, wszystkie produkują wizualnie identyczne wyjście.
Wskazówki kodowania dla najlepszych wyników
- Zawsze koduj z oryginału (nie z JPG → ponownie zakodowanego WebP), inaczej kompounduje straty.
- Dla zdjęć użyj q60 AVIF / q80 WebP, sweet spot.
- Dla grafiki z ostrymi krawędziami przełącz na bezstratny WebP lub fallback PNG. Stratny AVIF może rozmywać drobne linie.
- Nie zawracaj sobie głowy AVIF dla miniatur poniżej 100×100, różnica rozmiaru pliku jest maleńka vs koszt kodowania.
- Usuń metadane (EXIF, ICC), gdy możliwe, oszczędza kolejne 10-30 KB na obraz.
Co z JPEG XL?
JPEG XL (JXL) to nowszy format, który niektórzy nazywali “zabójcą AVIF” w 2022. W 2026:
- Chrome usunął wsparcie w 2023 (kontrowersyjna decyzja).
- Safari go obsługuje (od iOS 17).
- Firefox: za flagą.
Niewart wdrażania w produkcji jeszcze. Historia wsparcia przeglądarek jest zbyt niepewna. Sprawdź ponownie w 2027.
Podsumowanie
Dla 90% stron w 2026:
- Pipeline buildu koduje każdy obraz do AVIF + WebP + JPG/PNG.
- Tag
<picture>w HTML serwuje właściwy w oparciu o przeglądarkę. - JPG jakość 85, WebP 80, AVIF 60 jako domyślne, wizualnie identyczne.
- Pomijaj AVIF tylko dla maleńkich obrazów lub ścieżek dynamicznego generowania.
- Zmierz z Core Web Vitals przed i po, waga obrazu powinna spaść ~70%.
Możesz teraz konwertować swoje istniejące zasoby z JPG na WebP, PNG na WebP lub przetwarzać wsadowo przez Konwertuj obraz. Wszystko działa lokalnie, bez wgrywania, bez serwera.