Problemy z obrazami WebP w WordPress – konwersja, AVIF, optymalizacja 2026

WebP to format Google z 2010 roku, ale dopiero od 2024 roku jest realnie wspierany przez wszystkie przeglądarki włącznie z Safari. AVIF poszedł krok dalej – kompresja lepsza o 40–50% przy zachowaniu jakości wizualnej. W praktyce zdjęcie produktu ważące 380 KB jako JPG schodzi do 95 KB w WebP i 52 KB w AVIF. Na sklepie z 50 produktami w grid'zie kategorii to różnica między 19 MB a 2,6 MB pierwszego ładowania.

Google PageSpeed Insights od 2024 roku traktuje brak nowoczesnego formatu jako krytyczne ostrzeżenie pod "Wyświetlaj obrazy w formatach następnej generacji". Jeśli twój LCP (Largest Contentful Paint) to obraz hero, konwersja na WebP potrafi obciąć czas ładowania o 1,2–1,8 sekundy. Czytaj więcej o powiązanym problemie wolnego ładowania w WordPress wolno się ładuje – przyczyny i rozwiązania.

Co konkretnie zyskujesz w 2026:
- redukcję wagi obrazów o 60–80% bez utraty jakości percepcyjnej,
- poprawę LCP średnio o 35–50% na stronach z dużą liczbą zdjęć,
- mniejszy transfer (oszczędność na hostingu i mobile dla użytkownika),
- lepszy CTR w SERP (Google premiuje szybkie strony w Page Experience).

Dla sklepów to przekłada się na realne pieniądze. Przy współczynniku konwersji 1,5% i 10 000 wejściach miesięcznie skrócenie LCP o sekundę daje średnio +12% zamówień (dane Google/SOASTA z 2017, w 2026 trend się utrzymał).

Klasyczny scenariusz: konwertujesz wszystkie obrazy do WebP, podmieniasz rozszerzenia w treści i nagle część użytkowników widzi puste prostokąty. To prawie zawsze brak fallbacku dla przeglądarek bez wsparcia.

Wsparcie WebP w 2026:
- Chrome, Edge, Opera, Brave – 100% (od 2014),
- Firefox – 100% (od wersji 65, 2019),
- Safari macOS – od 14 (2020), iOS Safari od 14 (2020),
- starsze iPhone'y z iOS 13 i niżej – brak wsparcia,
- IE11 – brak wsparcia (ale udział <0,3%).

Realnie 97% twojego ruchu obsłuży WebP natywnie. Pozostałe 3% to staruszki, które potrzebują JPG/PNG fallbacku. Najlepsze rozwiązanie to znacznik z elementami :

<picture>
  <source srcset="obraz.webp" type="image/webp">
  <img src="obraz.jpg" alt="opis" loading="lazy">
</picture>

Przeglądarka sama wybiera format – jeśli rozumie WebP, ładuje .webp, jeśli nie, spada do .jpg. Większość wtyczek (ShortPixel, Imagify, EWWW) generuje to automatycznie po włączeniu opcji "WebP delivery: picture HTML5".

Drugi sposób – rewrite w .htaccess. Plik .webp serwowany jest przy żądaniu .jpg, jeśli nagłówek Accept zawiera image/webp. Działa szybciej, ale potrafi się rozjechać z Cloudflare i innymi proxy. Polecam wyłącznie, jeśli masz pełną kontrolę nad cache (np. dedykowany serwer bez CDN). Po więcej szczegółów o konfiguracji cache zajrzyj do problemów z cache w WordPress.

Trzy wtyczki dominują rynek konwersji WebP w WordPressie. Każda ma inne mocne i słabe strony. Poniżej tabela porównawcza po teście na 1500 obrazach katalogu produktowego (sklep WooCommerce, oryginalna waga 412 MB).

Mój wybór dla większości klientów: Converter for Media (polski autor, konwersja lokalna bez limitów, wsparcie AVIF, 79 PLN jednorazowo) lub ShortPixel (jeśli potrzebujesz CDN i zaawansowanej kompresji adaptive). Smush Pro odpadł – kompresja słabsza, a cena wyższa.

Najczęstsze powody, dla których wtyczka "nie działa":
1. Brak biblioteki Imagick lub GD na serwerze – sprawdź w Narzędzia → Site Health. Hostingi typu nazwa.pl czy home.pl czasem mają wyłączone funkcje. Polecam migrację na CyberFolks, gdzie Imagick + libwebp są standardem.
2. Limit pamięci PHP – konwersja dużych PNG (>5 MB) wymaga 256 MB+ pamięci. Edytuj wp-config.php: `define('WP_MEMORY_LIMIT', '512M');`.
3. Konflikt z cache'em – po konwersji wyczyść cache wtyczki cache'ującej i Cloudflare. Bez tego zobaczysz stare JPG.
4. Brak praw zapisu w /uploads – chmod 755 na katalogach, 644 na plikach.

Więcej o doborze wtyczek przeczytasz w najlepsze wtyczki do WebP.

Dwa podejścia do serwowania WebP różnią się momentem konwersji.

Pre-generated (klasyczny model): wtyczka tworzy plik .webp obok każdego .jpg/.png w /uploads i serwuje go przez znacznik lub rewrite. Plusy: działa wszędzie, nie obciąża serwera przy żądaniu, pełna kontrola nad jakością. Minusy: bulk conversion 5000 obrazów potrafi trwać 4–6 godzin, zajmuje miejsce (plik .webp + oryginał = ~150% wagi).

On-the-fly (LiteSpeed, BunnyCDN): konwersja przy pierwszym żądaniu, wynik cache'owany. Plusy: brak bulk conversion, plik .webp generowany dopiero gdy potrzebny, automatyczna obsługa nowych obrazów. Minusy: wymaga LiteSpeed Web Server albo zewnętrznego CDN, pierwsze ładowanie wolniejsze.

Jeśli korzystasz z hostingu na Apache/Nginx i nie chcesz CDN-a, idź w pre-generated z ShortPixel albo Converter for Media. Jeśli masz LiteSpeed (np. CyberFolks, LH.pl), włącz LSCWP → Image Optimization → Auto Request Cron + Image WebP Replacement. Reszta robi się sama, w cenie hostingu, bez zewnętrznych wtyczek.

Hybrydowo: ShortPixel + Cloudflare Polish to częsta kombinacja. ShortPixel konwertuje raz, a Polish robi optymalizację kontekstową na krawędzi (per country/device). Ostrożnie z double-compression – ustaw w ShortPixel quality 82%, w Polish "Lossless" żeby Cloudflare nie kompresowało drugi raz.

Tradeoff od strony performance:
- pre-generated: TTFB stabilne, build storage +50%,
- on-the-fly: pierwszy hit +200–400 ms, potem identyczne TTFB.

Częsty zarzut: "skonwertowałem na WebP i pliki ważą tyle samo albo więcej". Trzy najczęstsze przyczyny.

1. Za wysoka jakość. Domyślnie ShortPixel ustawia 90%, co dla większości zdjęć jest przesadą. Optymalne wartości w 2026:
- foto produktowe na białym tle: 78–82%,
- zdjęcia portretowe / lifestyle: 80–85%,
- screenshoty interfejsu: 85–90% (lub PNG → lossless WebP),
- thumbnaile w grid'zie kategorii: 70–75%.

Różnica między 90% a 80% to średnio –35% wagi pliku przy zerowej różnicy wizualnej dla oka.

2. PNG → lossy WebP zamiast lossless. PNG to format bezstratny, używany głównie do logo, ikon i grafik z przezroczystością. Konwertując na lossy WebP tracisz precyzję krawędzi. Rozwiązanie: ustaw w ShortPixel/Imagify osobną regułę dla PNG → lossless WebP. Plik będzie ciut większy niż lossy, ale nadal 30–50% mniejszy od oryginalnego PNG.

3. Brak rewrite oryginałów. Wtyczka konwertuje, ale nadal serwujesz JPG, bo zapomniałeś włączyć "Replace original images" albo rewrite .htaccess. Sprawdź w DevTools → Network: jaki format faktycznie się ładuje. Jeśli przeglądarka pobiera "image/jpeg", a w katalogu jest .webp – masz niedokończoną konfigurację.

Test kompresji – proste DevTools:
1. Otwórz stronę z dużym zdjęciem hero,
2. F12 → zakładka Network → Disable cache,
3. Reload strony, posortuj po Size,
4. Sprawdź największy obraz – Type i Size,
5. Powinno być "webp" i <150 KB dla full-width hero 1920x1080.

AVIF (AV1 Image File Format) to nowsza alternatywa dla WebP. W 2026 wsparcie przeglądarek osiągnęło realny zasięg produkcyjny.

Wsparcie AVIF w 2026:
- Chrome 85+ (2020),
- Firefox 93+ (2021),
- Safari 16+ (2022),
- Edge 121+ (2024),
- łączny zasięg: 94% globalnie, 96% w Polsce.

Kompresja AVIF jest średnio o 40–50% lepsza niż WebP przy tej samej jakości. Plik produktowy 95 KB w WebP zejdzie do 52 KB w AVIF. Jakość krawędzi i tekstur lepsza zwłaszcza przy silnej kompresji (q<70).

Wymagania techniczne:
- PHP 8.1+,
- biblioteka libavif w wersji 0.9+ (sprawdź w Site Health → Server),
- ImageMagick 7.1+ z `--with-avif` lub Imagick z modułem AVIF,
- czas konwersji 3–5x dłuższy niż WebP (bardziej obciąża CPU).

Hostingi obsługujące AVIF out-of-the-box w 2026: CyberFolks, LH.pl, Zenbox, Hetzner z PHP 8.3. Nazwa.pl i home.pl nadal nie wspierają libavif na shared hostingu (stan na kwiecień 2026).

Strategia 2026: serwuj AVIF z fallbackiem do WebP i JPG:

<picture>
  <source srcset="obraz.avif" type="image/avif">
  <source srcset="obraz.webp" type="image/webp">
  <img src="obraz.jpg" alt="opis" loading="lazy">
</picture>

ShortPixel, EWWW i Converter for Media generują tę strukturę automatycznie. Imagify dopiero planuje wdrożenie w Q3 2026. Jeśli liczy się każda kilo-bajta (sklepy z dużą galerią), AVIF to oczywisty kierunek.

WordPress od wersji 4.4 generuje srcset automatycznie, ale wtyczki konwertujące potrafią ten mechanizm popsuć. Najczęstszy błąd: ładujesz obraz 1920x1080 dla telefonu 360px wide, marnując 90% transferu.

Jak działa native srcset w WordPress:
1. Wgrywasz obraz 2400x1600 do biblioteki mediów,
2. WordPress generuje miniatury: 150x150, 300x200, 768x512, 1024x683, 1536x1024, 2048x1365,
3. Funkcja `wp_get_attachment_image_srcset()` buduje atrybut srcset z deskryptorami szerokości,
4. Przeglądarka wybiera najmniejszy obraz pasujący do rzeczywistego rozmiaru viewportu.

Dla WebP musi się zgadzać kilka rzeczy:
- wtyczka konwertuje wszystkie warianty miniatur (nie tylko full size),
- atrybut sizes jest dopasowany do twojego layoutu (np. `sizes="(max-width: 768px) 100vw, 50vw"`),
- nie ładujesz obrazu retina (DPR 2x) tam, gdzie nie trzeba.

Test: otwórz stronę na telefonie, F12 → Network → wybierz obraz hero. Sprawdź pole "Resource Size" – powinno odpowiadać szerokości viewportu, nie oryginalnemu plikowi 2400px. Jeśli zawsze ładuje się full-size, srcset jest popsuty (zwykle przez Elementor lub niestandardowy szablon).

Częsty problem z Elementorem – widget Image domyślnie wyłącza WordPress'owy srcset i zastępuje własną logiką, która często nie zawiera mniejszych breakpointów. Naprawa: Elementor → Settings → Performance → Improved Asset Loading + Optimized DOM Output ON.

CDN z optymalizacją obrazów to często najszybsza droga do WebP bez konfiguracji wtyczek w WordPressie. Dwa rozwiązania dominują rynek.

Cloudflare Polish (plan Pro od 25 USD/mc):
- automatyczna konwersja JPG/PNG → WebP albo AVIF na krawędzi,
- dwa tryby: Lossless (jakość pełna, –20% wagi) i Lossy (jakość 85, –50% wagi),
- działa transparentnie – żadnych zmian w WordPressie,
- wymaga aktywnego planu Pro (free plan tego nie ma),
- działa najlepiej w połączeniu z Mirage (lazy loading na krawędzi).

Setup w 5 minut: zaloguj się w Cloudflare → Speed → Optimization → Image Optimization → Polish → wybierz Lossy + WebP. Po 24h sprawdź w Network typ obrazów – powinny mieć Content-Type: image/webp. Sprawdź też przewodnik jak zainstalować Cloudflare w WordPress.

BunnyCDN Optimizer (9,5 USD/mc + bandwidth):
- automatyczna konwersja na krawędzi,
- AVIF dostępny od 2024,
- responsive images via URL parameters (?width=800&format=webp),
- dynamic resizing per request,
- tańszy bandwidth niż Cloudflare ($0,01/GB w EU vs $0/GB w CF).

Porównanie kosztów dla średniej wielkości sklepu (50 GB transferu/mc):
- Cloudflare Pro + Polish: 25 USD/mc (transfer w cenie),
- BunnyCDN Optimizer: 9,5 + 0,5 = 10 USD/mc,
- ShortPixel + free Cloudflare: 4,99 USD/mc (best value).

Mój wybór dla większości klientów: BunnyCDN dla sklepów z dużym ruchem (>30 GB/mc), Cloudflare Polish jeśli już masz plan Pro z innych powodów, ShortPixel + free Cloudflare dla małych witryn (<10k pageviews).

Sama konwersja na WebP to dopiero połowa optymalizacji. Druga połowa to ładowanie obrazów dopiero gdy są potrzebne.

Native lazy loading (od WordPress 5.5):
WordPress automatycznie dodaje `loading="lazy"` do każdego znacznika poniżej viewportu. Działa we wszystkich nowoczesnych przeglądarkach (Chrome, Firefox, Safari 15.4+, Edge). Nic nie musisz instalować.

Co nie powinno być lazy:
- obraz hero (LCP element),
- logo w headerze,
- pierwsze 1–2 obrazy widoczne above-the-fold.

Te obrazy powinny mieć `fetchpriority="high"` zamiast lazy. Inaczej Google Page Speed pokaże ostrzeżenie "Largest Contentful Paint image was lazily loaded", co kosztuje ~0,5 s w czasie LCP.

Konfiguracja w popularnych themesach:
1. Astra: Customize → Performance → LCP Image Preload → ON,
2. Kadence: Theme Options → Performance → Critical CSS + Preload Hero Image,
3. GeneratePress Premium: Module Performance → Lazy Load Images + Preload Hero,
4. Elementor: Site Settings → Performance → Optimized DOM Output + Improved Asset Loading.

Wtyczki polecam ostrożnie. WP Rocket, Perfmatters, FlyingPress mają własne lazy loadery z Intersection Observer i fallbackiem dla starych przeglądarek. Działają dobrze, ale często konfliktują z lazy loaderem wbudowanym w themesach. Wybierz jedno źródło prawdy. Więcej w problemach z lazy loading.

Dane z testów na 12 sklepach klientów (2026 Q1): włączenie native lazy loading + preload hero image dało średnio –1,1 s w LCP i +14 punktów w PageSpeed Insights (mobile).

Konwersja na WebP bez pomiaru to wróżenie z fusów. Trzy źródła danych, które musisz znać.

1. PageSpeed Insights (lab data):
Prowadzi syntetyczny test w warunkach laboratoryjnych. Idealny do A/B porównania przed/po. Sprawdź szczególnie:
- LCP: cel <2,5 s,
- INP: cel <200 ms,
- CLS: cel <0,1.

Po konwersji WebP LCP powinien spaść o 0,8–1,5 s na typowej stronie z hero image. Jeśli różnica jest mniejsza niż 0,3 s, sprawdź czy serwujesz właściwy format (DevTools → Network).

2. Chrome User Experience Report (real data):
To dane z prawdziwych użytkowników Chrome. Dostępne w Search Console (Core Web Vitals) i PageSpeed Insights ("Origin Summary"). Aktualizacja co 28 dni. Przed konwersją zrób screenshot, wróć po miesiącu i porównaj.

3. Google Search Console → Page Experience:
Pokazuje liczbę URL-i w stanie "Good", "Needs improvement", "Poor". Cel: minimum 75% URL-i w "Good". To bezpośrednio wpływa na ranking.

Realne wyniki z optymalizacji 8 sklepów WooCommerce (Q1 2026):

Średnia poprawa LCP: –48%. Średni wzrost konwersji: +15,3%. To realne dane z naszych wdrożeń stron internetowych i optymalizacji SEO w pierwszym kwartale 2026.

Jeśli twój sklep ma LCP >3 s i obrazy w JPG, optymalizacja WebP to najszybsza droga do dwucyfrowego wzrostu konwersji. Skontaktuj się przez formularz albo zadzwoń +48 604 939 140 – zrobimy darmowy audyt Twoich obrazów i pokażemy, ile możesz zyskać.