Jak format WebP rewolucjonizuje przetwarzanie i optymalizację obrazów w internecie

Obraz o szerokości 4000 pikseli, wyświetlany na stronie w kolumnie 700 pikseli, pozostanie źle przygotowany nawet po zapisaniu go jako WebP. Zmieni się rozszerzenie i spadnie waga pliku, ale przeglądarka nadal będzie pobierała więcej danych, niż potrzebuje. WebP daje najlepsze efekty dopiero wtedy, gdy jest częścią całego procesu optymalizacji: skalowania, kompresji, generowania wersji responsywnych i prawidłowego ładowania obrazów.

Format łączy kompresję stratną i bezstratną, obsługę przezroczystości oraz animacji. Dzięki temu może przejąć wiele zadań wykonywanych wcześniej przez JPEG, PNG i GIF. W praktyce stratne pliki WebP często są o około 25–34% mniejsze od porównywalnych JPEG-ów, a bezstratne WebP mogą być o około 26% mniejsze od PNG. Nie jest to jednak gwarancja dla każdego obrazu — wynik zależy od jego zawartości, ustawień kodera i oczekiwanej jakości.

WebP odchudza obrazy, ale nie naprawia błędów w ich przygotowaniu

W praktyce największe oszczędności rzadko wynikają z samego wyboru formatu. Najpierw trzeba usunąć nadmiarowe piksele. Dopiero później ma sens walka o kolejne kilobajty kompresją.

Jeżeli zdjęcie produktu jest wyświetlane maksymalnie w rozmiarze 800 × 800 px, serwowanie pliku 3000 × 3000 px nie poprawi jego wyglądu. Zwiększy natomiast transfer, czas dekodowania i zużycie pamięci, szczególnie na tańszych telefonach. Podobny problem dotyczy banerów przygotowanych w jednym rozmiarze dla wszystkich urządzeń. Telefon często pobiera wtedy panoramiczną grafikę przeznaczoną dla monitora, choć na ekranie widoczny jest tylko jej fragment.

Rozsądny proces przygotowania obrazu wygląda następująco:

• ustalenie jego największego realnego rozmiaru na stronie;
• przygotowanie osobnych wariantów dla telefonu, tabletu i dużego ekranu;
• usunięcie zbędnych metadanych, o ile nie są potrzebne;
• eksport kilku wersji WebP z różnymi ustawieniami jakości;
• porównanie plików na ekranie, na którym będą faktycznie oglądane;
• wdrożenie atrybutów srcset i sizes, aby przeglądarka mogła wybrać właściwy wariant.

Dla zdjęć dobrym punktem startowym jest zwykle jakość WebP w granicach 70–82, ale nie istnieje jedna wartość odpowiednia dla całej biblioteki. Zdjęcie krajobrazu z dużą liczbą drobnych detali może wymagać wyższego ustawienia. Prosta fotografia produktu na jednolitym tle często znosi mocniejszą kompresję. Grafika z tekstem, cienkimi liniami lub interfejsem potrafi natomiast wyglądać źle już przy pozornie bezpiecznych parametrach.

Najczęściej problematyczne są:

• gradienty, na których pojawiają się pasy kolorów;
• drobny tekst otoczony artefaktami;
• włosy, trawa, tkaniny i inne nieregularne szczegóły;
• ostre krawędzie produktów na kontrastowym tle;
• półprzezroczyste cienie i delikatne poświaty.

Kompresji nie należy oceniać wyłącznie po procentowej redukcji. Plik zmniejszony z 300 do 90 KB nie jest sukcesem, jeśli na karcie produktu widać zabrudzone kontury lub utratę faktury materiału. W e-commerce obraz ma sprzedawać. Oszczędzenie dodatkowych 20 KB nie rekompensuje pogorszenia prezentacji produktu.

WebP obsługuje również kanał alfa, czyli przezroczystość. Dzięki temu może zastąpić wiele ciężkich PNG używanych do prezentowania produktów bez tła, nakładek, dekoracji lub ilustracji. Trzeba jednak uważać na grafiki z informacjami zapisanymi w całkowicie przezroczystych pikselach. Niektóre ustawienia kodera mogą modyfikować ich wartości RGB w celu poprawy kompresji, co ma znaczenie w nietypowych procesach dalszej obróbki.

Kiedy wybrać WebP, a kiedy JPEG, PNG, SVG lub AVIF

Zasada „konwertujemy wszystko do WebP” jest wygodna, ale technicznie słaba. Format powinien wynikać z rodzaju materiału, a nie z jednego ustawienia w CMS-ie.

WebP sprawdza się przede wszystkim przy:

• zdjęciach produktowych;
• miniaturach wpisów i kategorii;
• grafikach typu hero;
• zdjęciach w artykułach;
• rastrowych ilustracjach z przezroczystością;
• krótkich animacjach interfejsu.

JPEG nadal ma sens jako plik zapasowy, materiał wejściowy albo format wymagany przez starsze oprogramowanie. Nie trzeba jednak publikować go jako podstawowej wersji zdjęcia na współczesnej stronie. PNG warto zachować tam, gdzie potrzebna jest bezstratna kopia robocza, zgodność z konkretnym narzędziem lub idealne odwzorowanie pikseli. Używanie PNG dla zwykłych fotografii niemal zawsze kończy się niepotrzebnie dużymi plikami.

W przypadku logo, ikon, wykresów i prostych kształtów pierwszym wyborem powinno być SVG, nie WebP. Wektor pozostaje ostry niezależnie od rozmiaru, łatwo dopasowuje się do ekranów o wysokiej gęstości pikseli i często waży mniej od rastrowego odpowiednika. WebP jest rozwiązaniem zastępczym, gdy źródło istnieje wyłącznie w postaci bitmapy albo grafika zawiera efekty trudne do odtworzenia w SVG.

Osobnej decyzji wymaga AVIF. Ten format często pozwala uzyskać mniejsze pliki niż WebP, szczególnie przy zdjęciach, lecz kodowanie może trwać dłużej, a rezultaty przy niskiej jakości bywają mniej przewidywalne. W niektórych fotografiach AVIF bardzo dobrze zachowuje szczegóły. W innych może wygładzać tekstury lub wprowadzać artefakty, które stają się widoczne na dużym monitorze.

Praktyczna hierarchia wygląda więc tak:

1. Dla fotografii przetestować AVIF i WebP przy podobnej jakości wizualnej.
2. Wybrać mniejszy plik, ale odrzucić wersję z widocznymi uszkodzeniami.
3. Zachować WebP jako szeroko obsługiwany wariant nowoczesny.
4. Dodać JPEG lub PNG jako fallback tylko wtedy, gdy wymagają tego odbiorcy, urządzenia albo aplikacje.

WebP jest obsługiwany przez aktualne wersje Chrome, Edge, Firefox, Safari i popularnych przeglądarek mobilnych. Na typowej stronie firmowej, blogu lub sklepie może być podstawowym formatem obrazów. Fallback nadal ma uzasadnienie w systemach działających na starych WebView, urządzeniach przemysłowych, terminalach, kioskach lub nieaktualizowanych przeglądarkach.

Do serwowania kilku formatów służy element <picture>. Przeglądarka przechodzi przez dostępne źródła i pobiera pierwsze, które potrafi obsłużyć:

<picture>
  <source srcset="produkt.avif" type="image/avif">
  <source srcset="produkt.webp" type="image/webp">
  <img src="produkt.jpg"
       width="800"
       height="800"
       alt="Czarne buty trekkingowe z wysoką cholewką">
</picture>

Nie trzeba stosować takiej konstrukcji dla każdego obrazu. Jeżeli statystyki ruchu pokazują wyłącznie współczesne przeglądarki, pojedynczy plik WebP upraszcza wdrożenie i ogranicza liczbę wariantów przechowywanych w systemie. Rozbudowany fallback należy traktować jako odpowiedź na konkretny wymóg zgodności, a nie obowiązkowy rytuał. Element <picture> jest również przydatny wtedy, gdy na telefonie powinien pojawić się inaczej wykadrowany obraz, a nie tylko mniejsza kopia wersji desktopowej.

Animowane WebP potrafią być wyraźnie lżejsze od GIF-ów i oferują pełną paletę kolorów oraz 8-bitową przezroczystość. Mimo to przy dłuższych sekwencjach lepiej przetestować MP4 lub WebM. Format wideo zazwyczaj wygra przy demonstracji produktu, kilkunastosekundowej instrukcji lub dużej animacji w tle. Animowany WebP ma największy sens przy krótkich zapętleniach, emotikonach, naklejkach i prostych efektach interfejsu.

Szybkość strony zależy nie tylko od wagi pliku

Lżejsze obrazy skracają pobieranie danych i mogą poprawić Largest Contentful Paint, jeżeli największym elementem pierwszego ekranu jest zdjęcie lub baner. Sam WebP nie gwarantuje jednak lepszego wyniku w PageSpeed Insights. Obraz nadal może ładować się za późno, mieć nieprawidłowe wymiary albo być blokowany przez źle skonstruowaną stronę.

Najwyższy priorytet mają obrazy widoczne bez przewijania:

• główny baner;
• pierwsze zdjęcie produktu;
• miniatury na początku listingu;
• grafika otwierająca artykuł;
• zdjęcie w pierwszej sekcji landing page’a.

To właśnie te pliki należy najpierw posortować według wagi i sprawdzić w zakładce Network w narzędziach deweloperskich. Optymalizowanie ilustracji znajdujących się kilka ekranów niżej jest działaniem pomocniczym. Nie rozwiąże problemu, jeżeli użytkownik czeka na pobranie dwumegabajtowego banera startowego.

Częsty błąd polega na dodawaniu loading="lazy" do wszystkich obrazów. Grafika odpowiedzialna za LCP nie powinna być leniwie ładowana, ponieważ przeglądarka może rozpocząć jej pobieranie z opóźnieniem. Dla najważniejszego obrazu można zastosować fetchpriority="high", o ile rzeczywiście jest on głównym zasobem pierwszego widoku. Nadawanie wysokiego priorytetu kilku grafikom naraz rozmywa korzyść i może opóźnić pobieranie innych potrzebnych elementów.

Drugi problem to brak zadeklarowanych wymiarów:

<img src="produkt.webp"
     width="800"
     height="800"
     alt="Czarne buty trekkingowe z wysoką cholewką">

Atrybuty width i height pomagają przeglądarce wcześniej zarezerwować miejsce. Ogranicza to przesunięcia układu podczas ładowania. CSS nadal może skalować obraz responsywnie, na przykład przez max-width: 100%; height: auto;.

WebP nie zwalnia też z przygotowania srcset:

<img
  src="produkt-800.webp"
  srcset="
    produkt-400.webp 400w,
    produkt-800.webp 800w,
    produkt-1200.webp 1200w"
  sizes="(max-width: 600px) 92vw, 800px"
  width="800"
  height="800"
  alt="Czarne buty trekkingowe z wysoką cholewką">

Dzięki temu telefon nie musi pobierać pliku przygotowanego dla ekranu 4K. To często daje większą oszczędność niż obniżanie jakości pojedynczego obrazu. Responsywne źródła pozwalają przeglądarce dobrać wariant do szerokości ekranu i gęstości pikseli, zamiast zmuszać każde urządzenie do pobrania tej samej wersji.

Po wdrożeniu trzeba sprawdzić cztery rzeczy:

• wagę transferu, a nie tylko rozmiar pliku zapisany w CMS-ie;
• rzeczywiście pobrany wariant obrazu na telefonie i desktopie;
• jakość na ekranie Retina, gdzie artefakty bywają lepiej widoczne;
• ustawienia cache, aby przeglądarka nie pobierała bez potrzeby tych samych zasobów.

Lighthouse może wskazać obrazy wymagające lepszego formatu lub kompresji, ale wynik punktowy nie zastępuje kontroli wizualnej. Nowoczesne formaty zmniejszają czas pobierania zasobów i mogą obniżyć LCP, lecz efekt zależy także od serwera, CDN-u, HTML-a, CSS-u i kolejności ładowania.

Na SEO WebP działa pośrednio. Google nie przyznaje dodatkowych pozycji za samo rozszerzenie .webp. Znaczenie ma szybsze i stabilniejsze działanie strony oraz wygoda użytkownika. Nie wolno przy tym zaniedbać opisu alternatywnego. Atrybut alt powinien opisywać zawartość i funkcję obrazu, nie jego format. Nazwa buty-trekkingowe-damskie.webp jest też czytelniejsza organizacyjnie niż IMG_8421.webp, choć nie należy oczekiwać, że sama zmiana nazwy wywoła zauważalny wzrost widoczności.

FAQ

Czy WebP zawsze daje mniejszy plik niż JPEG?
Nie. Zwykle pozwala zmniejszyć wagę fotografii przy podobnej jakości, ale wynik zależy od obrazu i ustawień kodera. Porównuj pliki przy podobnym wyglądzie, nie przy identycznej wartości suwaka jakości.

Czy po konwersji można usunąć oryginalne JPEG-i i PNG?
Nie z biblioteki źródłowej. Zachowaj oryginały do ponownej obróbki, druku, zmiany kadru lub eksportu do kolejnego formatu. WebP powinien być wersją publikacyjną, a nie jedyną kopią materiału.

WebP czy AVIF — co wybrać?
Dla zdjęć przygotuj oba warianty i porównaj jakość przy zbliżonej wadze. AVIF często jest mniejszy, natomiast WebP pozostaje prostszy w obróbce i bardzo szeroko obsługiwany. Na rozbudowanych stronach można serwować AVIF jako pierwszy wybór, WebP jako drugi i JPEG jako fallback.

Czy przezroczysty PNG można zawsze zamienić na WebP?
Technicznie często tak, ponieważ WebP obsługuje kanał alfa. Najpierw sprawdź jednak, czy grafika nie powinna być zapisana jako SVG. Dla logo i prostych ikon wektor będzie zwykle ostrzejszy i lżejszy.

Czy WebP poprawia Core Web Vitals?
Może obniżyć czas pobierania i poprawić LCP, jeżeli ciężki obraz jest jednym z głównych elementów strony. Nie pomoże jednak, gdy plik ma złe wymiary, jest ładowany z opóźnieniem, serwer odpowiada wolno albo stronę blokuje ciężki JavaScript.

Czy animowany WebP jest lepszy od GIF-a?
Najczęściej tak pod względem kolorów i wagi. Przy dłuższej animacji lub materiale przypominającym film sprawdź MP4 albo WebM, ponieważ mogą zapewnić znacznie lepszą kompresję.

Czy każda strona potrzebuje fallbacku JPEG lub PNG?
Nie. Na zwykłej stronie kierowanej do użytkowników aktualnych przeglądarek WebP może działać samodzielnie. Fallback jest potrzebny głównie przy starych urządzeniach, aplikacjach z nieaktualnym WebView lub specjalistycznych systemach.

Pierwszy krok nie wymaga konwersji całej biblioteki. Otwórz najważniejszą podstronę w narzędziach deweloperskich, przejdź do zakładki Network, odfiltruj obrazy i posortuj je według rozmiaru transferu. Najpierw napraw najcięższy plik widoczny na pierwszym ekranie: zmniejsz jego wymiary, przygotuj wariant mobilny, zapisz go jako WebP i usuń niepotrzebny lazy loading. Dopiero gdy ten obraz ładuje się szybko i nadal wygląda dobrze, przechodź do kolejnych elementów.