WebP, AVIF, SVG – który format obrazu wybrać w 2026

Wprowadzenie – dlaczego wybór formatu wciąż ma znaczenie

Kiedyś wybór był prosty. Zdjęcia zapisywało się jako JPEG, grafikę z przezroczystością jako PNG, animacje jako GIF. Dziś do dyspozycji mamy trzy dojrzałe formaty, które różnią się fundamentalnie w podejściu do zapisu obrazu. WebP to sprawdzony koń roboczy, obecny w przeglądarkach od dekady. AVIF to specjalista od ekstremalnej kompresji, zbudowany na fundamencie nowoczesnego kodeka wideo. SVG natomiast działa na zupełnie innych zasadach niż pozostałe dwa, bo nie jest obrazem złożonym z pikseli.

Pytanie, które warto sobie zadać w 2026 roku, nie brzmi „który format jest najlepszy". Brzmi raczej „który pasuje do tego, co teraz robię, jakimi zasobami dysponuję i dla kogo tworzę stronę". W tym artykule rozkładam każdy z trzech formatów na czynniki pierwsze – kompresję, wsparcie przeglądarek, prędkość kodowania i praktyczne zastosowania – żeby wybór formatu obrazu przestał być zgadywanką.

Różnica między obrazem rastrowym a wektorowym

Obrazy rastrowe, do których zaliczają się JPEG, PNG, WebP i AVIF, to w praktyce siatka pikseli. Każdy pojedynczy piksel ma zapisaną informację o kolorze, a im więcej pikseli buduje obraz, tym większy staje się plik. Gdy powiększysz zdjęcie rastrowe wystarczająco mocno, w końcu zobaczysz pojedyncze kwadraciki, z których się składa.

SVG działa zupełnie inaczej. To nie siatka pikseli, tylko zestaw matematycznych instrukcji, które opisują przeglądarce, jak narysować kształty, linie i krzywe. Dzięki temu można powiększyć plik SVG choćby tysiąc razy, a krawędzie pozostaną równie ostre jak w oryginale. Dodatkowym atutem jest to, że plik SVG to zwykły tekst – można go stylować arkuszem CSS, dodać do niego obsługę kliknięć, a wyszukiwarki są w stanie odczytać zawarty w nim tekst. To nie jest zamiennik JPEG, tylko zupełnie inne narzędzie do zupełnie innego zadania.

Praktyczny wniosek z tej różnicy jest prosty. SVG bierzesz do logo, ikon i ilustracji o ostrych krawędziach. Zdjęcia i wszystkie złożone obrazy rastrowe zostawiasz formatom WebP i AVIF.

WebP – sprawdzony format uniwersalny

WebP powstał w Google w 2010 roku i opiera się na kodowaniu predykcyjnym z rodziny VP8, tej samej, na której zbudowany jest format wideo WebM. Efekt tego podejścia jest łatwy do zmierzenia: pliki WebP są zwykle o 25–35% mniejsze od JPEG przy zachowaniu tej samej jakości wizualnej. W trybie bezstratnym WebP jest z kolei o 26% mniejszy od odpowiadającego mu pliku PNG.

Format obsługuje przezroczystość w obu trybach kompresji. W trybie stratnym z przezroczystością daje pliki nawet trzy razy mniejsze niż PNG. Animacje zapisane w WebP są też wielokrotnie lżejsze od klasycznego GIF-a. Dobrym przykładem jest animowany GIF ważący 1,6 megabajta, który po konwersji na WebP schodzi do około 900 kilobajtów, przy czym jakość obrazu jest znacznie wyższa niż w oryginale.

Największą zaletą WebP pozostaje jednak wsparcie przeglądarek. Format działa w Chrome od 2014 roku, w Firefoksie od 2019, w Safari od 2020 i w Edge od 2018. Łączne pokrycie to około 97% globalnego ruchu w sieci. Jedynym istotnym wyjątkiem jest Internet Explorer, wycofany ostatecznie w 2022 roku, więc w praktyce nie ma dziś znaczenia.

WebP koduje się bardzo szybko. Zdjęcie o rozdzielczości 12 megapikseli da się zakodować w mniej niż sekundę, co ma ogromne znaczenie wtedy, gdy obrazy przetwarzane są na żądanie, na przykład przy dynamicznym generowaniu miniatur.

Format ma jednak swoje ograniczenia. Obsługuje maksymalnie 8 bitów na kanał koloru, nie ma wsparcia dla HDR, a maksymalny wymiar obrazu to 16383 na 16383 piksele. Dla typowej strony internetowej to szczegół bez znaczenia, ale przy profesjonalnej fotografii z szeroką gamą barw te limity mogą się okazać odczuwalne.

AVIF – maksymalna kompresja dla nowoczesnych ekranów

AVIF stworzyło Alliance for Open Media, konsorcjum, w którego skład wchodzą między innymi Google, Apple, Netflix, Amazon, Microsoft i Facebook. Format opiera się na kodeku wideo AV1 – innymi słowy, plik AVIF to w uproszczeniu klatka kluczowa z nowoczesnego kodeka wideo zapisana jako pojedynczy obrazek.

Efekty kompresji są imponujące. AVIF jest zwykle o 50–60% mniejszy od JPEG i o 20–30% mniejszy od WebP przy zachowaniu tej samej jakości wizualnej. Weźmy przykład krajobrazu o rozdzielczości 3000 na 2000 pikseli: jako JPEG waży on 2,5 megabajta, jako WebP 1,8 megabajta, a jako AVIF już tylko 1,2 megabajta. Przy skali strony ze stu takimi zdjęciami różnica robi się ogromna – to różnica między 130 megabajtami transferu a 36 megabajtami.

AVIF obsługuje 10-bitową głębię kolorów, podczas gdy JPEG ogranicza się do 8 bitów. Format wspiera również HDR oraz szerokie gamy barw DCI-P3 i Rec.2020, więc został zaprojektowany z myślą o współczesnych monitorach. Obsługuje też przezroczystość i technicznie potrafi zapisywać animacje, choć implementacja animowanych plików AVIF jest jeszcze niedojrzała.

Wsparcie przeglądarek w 2026 roku jest już dobre. Chrome obsługuje AVIF od sierpnia 2020, Firefox od października 2021, Safari od marca 2023 (wersja 16.4), a Edge od stycznia 2024 (wersja 121). Łączne pokrycie to około 94–95% globalnego ruchu. Różnica względem WebP wynika głównie ze starszych urządzeń z Androidem oraz przeglądarek typu legacy, które wciąż krążą po sieci.

Głównym mankamentem AVIF pozostaje prędkość kodowania. Zdjęcie o rozdzielczości 12 megapikseli na ustawieniach szybkich koduje się 2–5 sekund, a na ustawieniach jakościowych nawet 30 sekund. WebP wykonuje to samo zadanie w ułamek sekundy. Dla statycznej strony, na której obrazy kodujesz raz podczas budowania witryny, ta różnica nie ma znaczenia. Dla systemu przetwarzającego tysiące zdjęć na żądanie to już problem zasadniczy.

Drugą wadą jest brak progresywnego dekodowania. Plik AVIF musi zostać pobrany w całości, zanim przeglądarka pokaże cokolwiek, podczas gdy JPEG czy JPEG XL potrafią wyświetlić wstępny podgląd już po kilkuset bajtach. Trzecim ograniczeniem jest zapotrzebowanie na pamięć RAM – kodowanie AVIF na środowiskach serverless bywa z tego powodu problematyczne.

AVIF sprawdza się najlepiej tam, gdzie zależy Ci na maksymalnej kompresji i możesz zakodować obrazy jednorazowo, na przykład podczas budowania strony. Nie nadaje się natomiast do przetwarzania obrazów w locie, gdy liczy się każda sekunda odpowiedzi serwera.

SVG – fundament ikon, logo i interfejsu

Logotypy, ikony, wykresy i ilustracje – wszystko, co ma ostre krawędzie i nie jest fotografią – powinno być zapisane jako SVG. Pliki tego typu są lekkie, skalują się bez żadnej utraty jakości, można je animować za pomocą arkusza CSS, a wyszukiwarki potrafią odczytać zawarty w nich tekst.

Jest jednak jeden haczyk. Nieoptymalizowany plik SVG wyeksportowany z Figmy czy Illustratora potrafi ważyć kilka razy więcej, niż powinien. Taki eksport zawiera zwykle metadane edytora, puste grupy, zbędne identyfikatory, atrybuty domyślne oraz ścieżki zapisane z przesadną precyzją – na przykład pięć miejsc po przecinku tam, gdzie w zupełności wystarczą dwa. Typowa ikona wyeksportowana z Figmy waży około 4 kilobajtów, a po optymalizacji – niecałe 800 bajtów.

Optymalizacja SVG – jak zmniejszyć wagę pliku

Do czyszczenia plików SVG służy narzędzie SVGO, które usuwa zbędne dane pozostawione przez program graficzny. Średnia redukcja rozmiaru po takiej optymalizacji wynosi 50–80%, a same metadane edytora odpowiadają często za 40–60% wagi pliku. Do tego dochodzi kompresja GZIP lub Brotli po stronie serwera, która zmniejsza transfer pliku SVG o kolejne 60–75%.

SVG ma jednak swoją górną granicę złożoności. Każdy element w takim pliku to osobny węzeł w strukturze dokumentu strony, dlatego przy około 5 tysiącach elementów format zaczyna zwalniać, a przy 10 tysiącach animacja spada nawet do 12 klatek na sekundę. Dla porównania Canvas radzi sobie z 50 tysiącami elementów przy 55 klatkach na sekundę, a WebGL z milionem elementów przy 45 klatkach na sekundę. SVG świetnie sprawdza się w interfejsach i prostych wizualizacjach, ale do map z dziesiątkami tysięcy punktów lepiej zastosować Canvas z dodatkową warstwą SVG na wierzchu, przeznaczoną wyłącznie do etykiet.

Prawidłowa kolejność formatów i warianty zapasowe

Standardem w budowaniu strony jest znacznik obrazu z kilkoma alternatywnymi źródłami, spośród których przeglądarka bierze pierwsze rozpoznawane przez siebie źródło i ignoruje resztę. Kolejność tych źródeł ma znaczenie krytyczne: najpierw powinno znaleźć się źródło w formacie AVIF, jako to dające największą kompresję, następnie WebP jako zapasowy wariant działający praktycznie wszędzie, a na końcu JPEG jako ostateczne zabezpieczenie dla najstarszych przeglądarek i robotów indeksujących.

Każde źródło musi mieć jednoznacznie zdefiniowany typ pliku. Bez tej informacji przeglądarka zaczyna zgadywać format i często pobiera plik, którego wcale nie obsługuje, co prowadzi do niepotrzebnego marnowania transferu albo do braku wyświetlenia obrazu. Ważne jest też, aby obraz miał od razu zarezerwowane miejsce na stronie poprzez podanie jego szerokości i wysokości, zanim jeszcze zdąży się załadować. Dzięki temu układ strony się nie przesuwa, co bezpośrednio przekłada się na lepszy wynik metryki CLS w Core Web Vitals.

Preload i priorytet dla obrazu LCP

Dla obrazu znajdującego się powyżej linii cięcia strony, czyli takiego, który jest zwykle największym widocznym elementem po wejściu na witrynę, nie powinno się stosować opóźnionego ładowania. Zamiast tego warto nadać mu wysoki priorytet pobierania oraz umieścić dla niego dodatkową wskazówkę wstępnego ładowania w nagłówku strony, wskazującą dokładnie ten plik i jego format.

Ta kombinacja – właściwy format, wstępne ładowanie, wysoki priorytet pobierania oraz zdefiniowane wymiary obrazu – daje największą poprawę metryki LCP spośród wszystkich możliwych optymalizacji obrazów na stronie.

CDN i automatyczna negocjacja formatu

Jeśli korzystasz z sieci CDN oferującej automatyczną negocjację formatu, w praktyce możesz zapomnieć o ręcznym przygotowywaniu kilku wersji tego samego obrazu. Rozwiązania takie jak Cloudinary, imgix czy Cloudflare Images odczytują nagłówek przesyłany przez przeglądarkę użytkownika i na tej podstawie samodzielnie serwują odpowiedni format – AVIF, WebP albo JPEG – z jednego, prostego odwołania do obrazu w kodzie strony. Cała reszta pracy odbywa się po stronie serwera, bez potrzeby zmian w samej witrynie.

Na WordPressie podobną rolę pełnią wtyczki takie jak ShortPixel, Imagify czy Cloudinary for WordPress. Automatycznie konwertują przesyłane obrazy do AVIF i WebP, dodają responsywne warianty rozmiarów i podłączają całość pod sieć CDN, bez konieczności ręcznej ingerencji w każdy pojedynczy plik.

Który format wybrać w Twojej sytuacji

Dla większości stron internetowych optymalnym rozwiązaniem jest AVIF jako format główny, z WebP w roli zabezpieczenia. Dotyczy to sklepu internetowego, bloga podróżniczego czy portfolio fotografa – oszczędności transferu będą wtedy znaczące, średnio około 70% mniej niż przy JPEG i 37% mniej niż przy WebP.

Jeśli natomiast obrazy generujesz dynamicznie i każda sekunda kodowania ma znaczenie dla wydajności serwera, bezpieczniejszym wyborem pozostaje WebP. Strata w kompresji rzędu 20–30% jest w takiej sytuacji akceptowalna wobec realnego zysku w czasie przetwarzania.

Dla elementów interfejsu – ikon, logo i ilustracji – zawsze wybieraj SVG. Jeden dobrze zoptymalizowany plik SVG po kompresji GZIP waży zwykle 1–2 kilobajty, czyli mniej niż jakikolwiek format rastrowy.

Dla profesjonalnych fotografii z szeroką gamą barw i obsługą HDR AVIF praktycznie nie ma konkurencji, ponieważ WebP nie obsługuje 10-bitowej głębi koloru. Warto też pamiętać o formacie JPEG XL – choć jest technicznie imponujący, w 2026 roku nie jest jeszcze gotowy do produkcyjnego użycia na publicznych stronach. Obsługuje go zaledwie około 12% przeglądarek, głównie Safari. Jeśli kontrolujesz środowisko odbiorcy, na przykład w aplikacji wewnętrznej firmy albo na kiosku, JPEG XL ma sens. Dla publicznej strony internetowej – jeszcze nie.

Najczęstsze błędy przy wdrażaniu nowych formatów

Pierwszym błędem jest wielokrotne przekodowywanie stratne. Gdy trzymasz zdjęcie w formacie JPEG, konwertujesz je do WebP, a potem do AVIF, każda kolejna konwersja pogarsza jakość obrazu. Oryginały warto przechowywać w formacie bezstratnym, na przykład PNG czy TIFF, a do formatu docelowego kodować zawsze bezpośrednio z takiego mastera.

Drugim częstym błędem jest umieszczenie WebP przed AVIF wśród źródeł obrazu. Skoro przeglądarka bierze pierwsze rozpoznawane źródło, a WebP znajduje się na początku listy, nikt nigdy nie zobaczy lżejszej wersji w AVIF, mimo że przeglądarka mogłaby ją obsłużyć.

Trzecim błędem jest stosowanie opóźnionego ładowania na obrazie, który jest największym elementem widocznym zaraz po wejściu na stronę. Takie ustawienie opóźnia pobranie obrazu o 200–500 milisekund i bezpośrednio pogarsza wynik metryki LCP.

Dlaczego nie warto przesadzać z kompresją

Przejście z JPEG na WebP daje zwykle 25–35% oszczędności wagi pliku. Przejście z WebP na AVIF to kolejne 20–30%. Dalsze zwiększanie poziomu kompresji przynosi już coraz mniejsze korzyści przy wyraźnie widocznym pogorszeniu jakości obrazu. Większy wpływ na wynik LCP ma zwykle coś zupełnie innego: serwowanie zdjęcia o szerokości 2000 pikseli na widoku szerokim na 400 pikseli, brak wstępnego ładowania kluczowego obrazu albo opóźnione ładowanie zastosowane właśnie na nim.

Format obrazu to w gruncie rzeczy wykończenie całego procesu, a nie jego fundament. Najpierw warto poprawić strukturę dostarczania obrazów, a dopiero potem zajmować się samym formatem. Większe oszczędności przy mniejszym wysiłku daje poprawne dopasowanie rozmiaru obrazu do rozmiaru wyświetlacza, dzięki czemu przeglądarka przestaje pobierać wersję przeznaczoną na komputer stacjonarny na ekran telefonu. To trochę jak wyłączanie świateł w całym domu zamiast wymiany jednej żarówki.

Podsumowanie

Wybór formatu obrazu w 2026 roku nie jest już dylematem czysto technicznym. AVIF wygrywa pod względem kompresji i jakości przy tej samej wadze pliku. WebP wygrywa uniwersalnością wsparcia oraz szybkością kodowania, co czyni go bezpiecznym wyborem tam, gdzie liczy się czas przetwarzania. SVG sprawdza się wszędzie tam, gdzie obraz musi pozostać ostry w każdej możliwej skali powiększenia.

Nie ma jednej uniwersalnie poprawnej odpowiedzi na pytanie o format obrazu. Jest tylko odpowiedź dopasowana do konkretnego pytania: co robisz, jakimi zasobami dysponujesz i dla kogo tworzysz stronę. Jeśli budujesz stronę od podstaw lub planujesz jej optymalizację pod kątem szybkości ładowania, warto potraktować dobór formatu obrazu jako jeden z ostatnich, a nie pierwszych kroków w tym procesie.

Więcej o tym, jak obrazy i inne elementy strony wpływają na wyniki w Google, znajdziesz w naszym przewodniku po Core Web Vitals i PageSpeed Insights, gdzie opisujemy wszystkie metryki wydajności krok po kroku.