WebP – co to jest i dlaczego warto go używać?

Format obrazu z liczbami podanymi przez samego wydawcę

Drugą liczbę cytuje się zwykle bez końcówki, a właśnie ona jest istotna. Porównanie dotyczy obrazów o równym wskaźniku SSIM, czyli zmierzonym podobieństwie do oryginału, a nie „tej samej jakości” w potocznym sensie. Bez tego zastrzeżenia zdanie zmienia się w obietnicę, której nikt nie składał.

Dokumentacja podaje też koszt przezroczystości w trybie bezstratnym: dodatkowe 22% bajtów.1 Wsparcie przeglądarek nie jest już dziś tematem: format jest natywnie obsługiwany w Chrome, Safari, Firefoksie, Edge i Operze.1

Rozszerzenie w adresie nie mówi, co dostaje przeglądarka

Tu leży rzecz, która wywraca większość audytów obrazów. Adres kończący się na .png nie gwarantuje, że serwer odeśle plik PNG. Ten sam adres może zwrócić różne formaty różnym odbiorcom, zależnie od tego, co odbiorca zadeklaruje w nagłówku żądania.

Mechanizm nazywa się negocjacją treści i jest częścią protokołu HTTP. Przeglądarka wysyła nagłówek mówiący, jakie formaty przyjmie; serwer wybiera z nich najlepszy i dokłada informację, że odpowiedź zależy od tego nagłówka. Konwersję wykonuje przy tym często nie sam serwer strony, lecz warstwa pośrednicząca przed nim.

Praktyczny wniosek jest prosty i niewygodny: policzenie rozszerzeń plików w kodzie strony nie mówi nic o tym, co realnie pobiera użytkownik. Żeby to sprawdzić, trzeba odpytać adres dwa razy (raz jako klient przyjmujący nowe formaty, raz jako klient, który ich nie przyjmuje) i porównać odpowiedzi.

Nasz pomiar: audyt po nazwach plików pokazał zero

Sprawdziliśmy własny serwis 2 września 2026 roku i przebieg tego sprawdzenia jest tu ciekawszy niż wynik. Zaczęliśmy od katalogu z plikami: 13 534 obrazy JPG, 4344 PNG i tylko 453 WebP, przy zerowej liczbie plików AVIF. Potem policzyliśmy odwołania do obrazów w kodzie sześciu stron różnych szablonów: ani jednego adresu z rozszerzeniem WebP i ani jednego znacznika <picture>.

Wniosek nasuwał się sam i był fałszywy. Zanim trafił do tekstu, sprawdziliśmy jeszcze, co serwer naprawdę odsyła. Ten sam adres pliku PNG odpytany bez deklaracji obsługi nowych formatów zwrócił obraz PNG o wielkości 1 092 613 bajtów. Odpytany tak, jak robi to każda współczesna przeglądarka, zwrócił obraz WebP o wielkości 50 042 bajtów. To ta sama grafika i ten sam adres, mniejsza o 95%.

Odpowiedź zawiera przy tym nagłówek mówiący wprost, że jej treść zależy od żądania, oraz informację, że warstwa pośrednicząca nie trzyma tych obrazów w pamięci podręcznej. Konwersja wykonuje się więc przy każdym pobraniu, zamiast raz. To osobna sprawa do naprawy, ale też dowód, że mechanizm faktycznie pracuje.

Zapamiętaliśmy z tego regułę: liczba plików w katalogu i liczba rozszerzeń w kodzie to dwa różne pomiary, a żaden z nich nie jest odpowiedzią na pytanie, w jakim formacie strona się ładuje. Odpowiedzi udziela wyłącznie nagłówek odpowiedzi serwera.

Oszczędność zależy od tego, jak zły był oryginał

Wyjaśnijmy różnicę między naszymi 95% a podawanym przez dokumentację przedziałem 25–34%. To nie jest sprzeczność, tylko inny punkt odniesienia. Deklarowane widełki dotyczą porównania z dobrze zapisanym JPEG-iem o zbliżonej jakości. Nasz przykład to fotografia zapisana jako PNG, czyli w formacie bezstratnym, przeznaczonym do grafik z płaskimi barwami, a nie do zdjęć.

Większość oszczędności nie wzięła się więc z wyższości formatu, tylko z naprawy złego wyboru sprzed lat. To użyteczna wskazówka przy szacowaniu korzyści: największe zyski daje znalezienie zdjęć zapisanych bezstratnie, a nie zmiana formatu na najnowszy. Jeden plik obrazu ważący ponad megabajt jest tu sygnałem czytelniejszym niż jakikolwiek raport.

Co z tego wynika przy pracy nad obrazami

Pierwszy wniosek dotyczy sposobu sprawdzania. Audyt formatów, tak samo jak szersza optymalizacja obrazów, należy robić na odpowiedziach serwera, a nie na nazwach plików. Inaczej można równie dobrze uznać, że format wdrożony i działający w ogóle nie istnieje.

Drugi dotyczy kolejności prac. Zanim ktokolwiek zajmie się formatem, dobrze jest znaleźć obrazy nieproporcjonalnie ciężkie względem tego, co przedstawiają. Poprawa wyboru formatu źródłowego daje zwykle więcej niż konwersja poprawnie zapisanych plików, a sama kompresja obrazów jest wtedy tylko domknięciem tej pracy.

Trzeci dotyczy warstwy pośredniczącej. Jeśli konwersja odbywa się w locie, to dobrze jest sprawdzić, czy jej wynik jest zapamiętywany. Inaczej ta sama praca wykonuje się przy każdym żądaniu. Rolę pamięci podręcznej pełni tu zwykle sieć dostarczania treści, więc to w jej ustawieniach szuka się przyczyny.

Najczęstsze pytania

O ile WebP jest lżejszy od innych formatów?
Według dokumentacji o 26% wobec PNG w trybie bezstratnym i o 25–34% wobec JPEG przy równym wskaźniku SSIM.1 W praktyce różnica bywa większa, gdy oryginał zapisano w nieodpowiednim formacie.

Czy WebP obsługuje przezroczystość?
Tak, w obu trybach kompresji. W trybie bezstratnym kosztuje to dodatkowe 22% bajtów.1

Jak sprawdzić, czy strona serwuje WebP?
Trzeba odczytać nagłówek odpowiedzi serwera dla konkretnego obrazu, a nie rozszerzenie w adresie. Ten sam adres może zwracać różne formaty różnym przeglądarkom.

Czy używanie WebP podnosi pozycję w wyszukiwarce?
Nie bezpośrednio. Format wpływa na wagę strony i czas jej wczytywania, a te są mierzone osobnymi wskaźnikami. Sam wybór formatu nie jest czynnikiem rankingowym.

Źródła

1. Google Developers, „WebP — An image format for the Web” — wielkości oszczędności wobec PNG i JPEG wraz z zastrzeżeniem o wskaźniku SSIM, koszt przezroczystości oraz lista przeglądarek z natywną obsługą. Zobacz dokumentację formatu WebP →