Optymalizacja obrazów WordPress – AVIF, WebP, lazy loading i fetchpriority w praktyce
Opublikowano: 20 maja 2026 · Autor: Marcin Szewczyk-Wilgan
Obrazy stanowią średnio od 40 do 60% wagi strony WordPress. Na stronach ze zdjęciami produktów, portfolio czy galerią fotografii proporcja ta sięga 80%. To właśnie obraz jest najczęściej elementem LCP (Largest Contentful Paint), czyli główną metryką Core Web Vitals odpowiedzialną za postrzeganie szybkości ładowania. Nieprawidłowo zoptymalizowane obrazy to najpowszechniejsza przyczyna słabych wyników wydajnościowych stron WordPress, ale jednocześnie najłatwiejsze do naprawienia wąskie gardło. Konwersja do nowoczesnych formatów, prawidłowa kompresja, responsive images i właściwe zarządzanie priorytetami ładowania potrafią zmniejszyć wagę strony o ponad połowę i skrócić LCP o setki milisekund. W tym artykule opisujemy wszystkie aspekty optymalizacji obrazów w WordPress, od wyboru formatu po diagnostykę w Chrome DevTools.
Formaty obrazów: AVIF, WebP, JPEG i PNG w 2026 roku
Wybór formatu obrazu to decyzja, która ma bezpośredni wpływ na wagę strony, jakość wizualną i kompatybilność z przeglądarkami. W 2026 roku optymalną strategią jest serwowanie AVIF jako formatu pierwszego wyboru, z WebP jako fallbackiem i JPEG jako ostateczną rezerwą.
Standard 2026 roku
AVIF (AV1 Image File Format) oferuje kompresję o 30 do 50% lepszą niż WebP i o 50 do 70% lepszą niż JPEG przy porównywalnej jakości wizualnej. Obsługuje przezroczystość, HDR i zarówno kompresję stratną, jak i bezstratną. Wsparcie przeglądarek przekracza 93% globalnego ruchu (Chrome 85+, Firefox 93+, Safari 16+, Edge 90+). WordPress od wersji 6.5 (marzec 2024) obsługuje AVIF natywnie, generując miniaturki i rozmiary pośrednie. Wymaga PHP 8.1+ z biblioteką GD skompilowaną z obsługą AVIF lub Imagick z obsługą AVIF.
Bezpieczny format główny
WebP oferuje pliki o 25 do 35% mniejsze niż JPEG przy porównywalnej jakości. Wsparcie przeglądarek przekracza 96% globalnego ruchu, co czyni go najbardziej uniwersalnym formatem nowej generacji. WordPress obsługuje WebP natywnie od wersji 5.8. Obsługuje kompresję stratną, bezstratną, przezroczystość i animację. Dla stron, których serwer nie obsługuje jeszcze AVIF, WebP powinien być formatem domyślnym zamiast JPEG.
Fallback dla starszych przeglądarek
JPEG pozostaje formatem zapasowym dla przeglądarek, które nie obsługują AVIF ani WebP (poniżej 4% ruchu w 2026). PNG jest potrzebny wyłącznie tam, gdzie wymagana jest przezroczystość, a format AVIF lub WebP nie jest dostępny. Nie ma powodu serwować JPEG lub PNG jako formatu głównego na współczesnych stronach WordPress.
Automatyczny dobór formatu
Najlepsza strategia to content negotiation: serwer lub CDN sprawdza nagłówek Accept przeglądarki i serwuje AVIF, WebP lub JPEG w zależności od wsparcia. Można to realizować przez element <picture> w HTML, konfigurację serwera (Nginx z map, Apache z mod_rewrite) lub wtyczki WordPress z automatyczną konwersją. Cloudflare Polish automatycznie konwertuje i serwuje AVIF/WebP bez zmian po stronie serwera.
Kompresja i wymiary: ile optymalizacji jest za dużo?
Konwersja do nowoczesnego formatu to dopiero połowa sukcesu. Równie ważna jest prawidłowa kompresja i odpowiednie wymiary obrazu. Wgrywanie zdjęć prosto z aparatu (4000 do 8000 pikseli szerokości) to jeden z najczęstszych błędów wydajnościowych na stronach WordPress.
big_image_size_threshold), ale to wciąż za dużo dla większości zastosowań i oryginał pozostaje na serwerze.
Lazy loading, fetchpriority i priorytetyzacja ładowania obrazów
Prawidłowa priorytetyzacja ładowania obrazów to kluczowy element optymalizacji LCP. WordPress automatyzuje wiele aspektów tej optymalizacji, ale domyślne zachowanie nie zawsze jest prawidłowe, szczególnie w połączeniu z page builderami i niestandardowymi motywami.
Opóźnione ładowanie obrazów poza viewport
WordPress od wersji 5.5 automatycznie dodaje atrybut loading="lazy" do obrazów, co opóźnia ich pobranie do momentu, gdy użytkownik przewinie do nich stronę. To oszczędza transfer i przyspiesza początkowe ładowanie. Od wersji 5.9 WordPress pomija lazy loading dla pierwszych obrazów na stronie. Problem pojawia się, gdy motyw lub page builder nadpisuje to zachowanie i zastosuje lazy loading do obrazu hero (LCP), co może pogorszyć wynik LCP o setki milisekund.
Priorytet pobierania obrazu LCP
Atrybut fetchpriority="high" informuje przeglądarkę, że dany obraz powinien być pobrany z najwyższym priorytetem. Domyślnie przeglądarki traktują obrazy jako zasoby o niskim priorytecie, więc nawet obraz above the fold może czekać w kolejce za CSS i JavaScript. WordPress od wersji 6.3 automatycznie dodaje fetchpriority="high" do obrazu, który najprawdopodobniej jest elementem LCP (powyżej 50 000 pikseli kwadratowych, bez lazy loading). Poprawa LCP wynosi od 5 do 10%.
Page buildery i niestandardowe motywy
WordPress próbuje zgadnąć, który obraz jest elementem LCP, ale w przypadku Elementora, Divi czy niestandardowych bloków zgaduje źle. Logo w nagłówku może dostać fetchpriority zamiast obrazu hero. Obraz w mega menu może blokować lazy loading dla ważniejszych obrazów. W takich sytuacjach warto wyłączyć automatyczne fetchpriority WordPressa (filtr wp_min_priority_img_pixels) i ustawić priorytet ręcznie na prawidłowym obrazie.
Prawidłowa konfiguracja
Obraz LCP (hero, featured image) powinien mieć: loading="eager" (nigdy lazy), fetchpriority="high" i opcjonalnie <link rel="preload"> w sekcji <head>. Wszystkie obrazy poza początkowym viewport powinny mieć loading="lazy". Obrazy widoczne w viewport, ale nie będące elementem LCP, powinny mieć domyślny priorytet (bez fetchpriority). Stosowanie fetchpriority="high" na wielu obrazach jednocześnie osłabia jego efekt.
Responsive images: srcset, sizes i dobór rozmiaru do urządzenia
WordPress automatycznie generuje wiele rozmiarów każdego wgrywanego obrazu i dodaje atrybuty srcset i sizes do tagów <img>. Dzięki temu przeglądarka pobiera obraz o wymiarach dopasowanych do aktualnej szerokości ekranu zamiast pobierać pełnowymiarowy oryginał na telefonie.
srcset zawiera listę dostępnych rozmiarów obrazu z ich szerokościami. Atrybut sizes informuje przeglądarkę, jaką szerokość obraz zajmie w layoucie na danym urządzeniu. Na tej podstawie przeglądarka wybiera najmniejszy obraz, który pokryje potrzebną szerokość, uwzględniając gęstość pikseli ekranu (DPR). Na iPhonie z DPR 3 przeglądarka pobierze obraz trzykrotnie szerszy niż CSS width.
sizes jest trudne, bo zależy od layoutu, motywu i responsywności. WordPress wspiera atrybut sizes="auto" dla obrazów z lazy loading, który pozwala przeglądarce samodzielnie obliczyć rozmiar na podstawie aktualnego layoutu. To eliminuje błędy w ręcznie ustawionym sizes, które mogą powodować pobieranie zbyt dużych lub zbyt małych obrazów.
add_image_size) dopasowanych do faktycznych wymiarów w layoucie pozwala serwować precyzyjnie dopasowane obrazy.
srcset serwuje ten sam obraz w różnych rozmiarach. Gdy potrzebujesz innego kadru na telefonie niż na desktopie (np. panorama vs zbliżenie), użyj elementu <picture> z <source> i atrybutem media. Element <picture> pozwala też serwować AVIF z fallbackiem do WebP i JPEG: <source type="image/avif">, <source type="image/webp">, <img src="fallback.jpg">.
Optymalizacja obrazów w WooCommerce
Sklepy WooCommerce to najbardziej wymagający scenariusz pod kątem obrazów. Katalog z tysiącami produktów, wariantami i galeriami generuje dziesiątki tysięcy plików graficznych. Niestandardowe rozmiary WooCommerce (miniaturka katalogowa, miniaturka koszyka, obraz pojedynczego produktu) mnożą liczbę plików na serwerze.
woocommerce_thumbnail (katalog produktów), woocommerce_single (strona produktu) i woocommerce_gallery_thumbnail (galeria). Domyślne wartości mogą nie pasować do Twojego motywu. Dostosuj je w Wygląd → Dostosuj → WooCommerce → Obrazy produktów. Zbyt duże rozmiary marnują transfer, zbyt małe wyglądają rozmycie na ekranach Retina.
wp media regenerate --yes w WP-CLI regeneruje wszystkie rozmiary dla wszystkich obrazów. Dla dużych bibliotek mediów (powyżej 10 000 obrazów) proces ten wymaga czasu i zasobów serwera. Uruchamiaj go poza godzinami szczytu lub na środowisku staging.
loading="lazy". Pierwszy obraz galerii powinien mieć loading="eager". Niektóre wtyczki galerii i page buildery dodają fetchpriority="high" do ukrytych slajdów, co jest błędem i powinno być poprawione na fetchpriority="low".
Diagnostyka: jak sprawdzić, czy obrazy są prawidłowo zoptymalizowane
Optymalizacja obrazów bez weryfikacji wyników to zgadywanie. Poniższe narzędzia pozwalają potwierdzić, że formaty, kompresja, wymiary i priorytety ładowania są prawidłowe.
Audyt z perspektywy Google
PageSpeed Insights identyfikuje obraz LCP, mierzy czas jego załadowania i wskazuje problemy: brak fetchpriority, zastosowanie lazy loading na obrazie LCP, serwowanie JPEG zamiast WebP/AVIF, zbyt duże wymiary w stosunku do wyświetlanego rozmiaru. Sekcja „Properly size images" pokazuje, ile kilobajtów można zaoszczędzić przez dopasowanie wymiarów.
Analiza na poziomie żądań
Zakładka Network w Chrome DevTools filtrowana na typ Img pokazuje wszystkie pobierane obrazy z informacją o formacie, rozmiarze, czasie pobrania i priorytecie. Kolumna Priority pokazuje, czy obraz LCP ma wysoki priorytet. Zakładka Performance wyświetla timeline ładowania z zaznaczonym elementem LCP. Zakładka Application → Frames → Images → pozwala zobaczyć wymiary intrinsic vs displayed i wykryć oversized images.
Weryfikacja wsparcia formatów na serwerze
W panelu WordPress przejdź do Narzędzia → Kondycja witryny → Informacje → Obsługa mediów. Zobaczysz listę formatów wspieranych przez serwer (AVIF, WebP, JPEG, PNG, GIF). Jeśli AVIF nie jest wymieniony, serwer wymaga aktualizacji PHP lub doinstalowania bibliotek graficznych. Informację tę warto przekazać dostawcy hostingu.
Weryfikacja content negotiation
Polecenie curl -I -H "Accept: image/avif,image/webp" URL_OBRAZU pozwala sprawdzić, jaki format zwraca serwer w odpowiedzi na żądanie z nagłówkiem Accept. Nagłówek odpowiedzi Content-Type: image/avif potwierdza, że serwer prawidłowo negocjuje format. Nagłówek Vary: Accept informuje CDN i cache, że odpowiedź zależy od nagłówka Accept przeglądarki, co jest niezbędne dla prawidłowego cachowania.
Podsumowanie
Optymalizacja obrazów to najszybsza droga do poprawy wyników Core Web Vitals na stronie WordPress. W 2026 roku standardem jest serwowanie AVIF z fallbackiem do WebP, kompresja dostosowana do formatu (AVIF 60 do 70, WebP 75 do 85), wymiary dopasowane do layoutu, responsive images z prawidłowym srcset i sizes, fetchpriority="high" na obrazie LCP oraz loading="lazy" na wszystkim poza początkowym viewport. WordPress automatyzuje wiele z tych optymalizacji (lazy loading od 5.5, fetchpriority od 6.3, AVIF od 6.5), ale automatyka nie zawsze działa prawidłowo, szczególnie z page builderami i niestandardowymi motywami. Regularna diagnostyka w PageSpeed Insights i Chrome DevTools pozwala wychwycić problemy, zanim wpłyną na pozycje w wyszukiwarce.
W WebOptimo optymalizacja obrazów jest częścią każdego wdrożenia i planu opieki WordPress. Konfigurujemy automatyczną konwersję do AVIF/WebP, poprawiamy priorytety ładowania, dostosowujemy rozmiary do layoutu i monitorujemy wyniki Core Web Vitals. Jeśli Twoja strona traci punkty na obrazach, skontaktuj się z nami po diagnostykę i optymalizację.
Najczęstsze pytania o optymalizację obrazów WordPress
AVIF jako format pierwszy (30 do 50% mniejsze pliki niż WebP, ponad 93% wsparcia przeglądarek), WebP jako fallback (96% wsparcia), JPEG jako ostateczna rezerwa. WordPress obsługuje AVIF od wersji 6.5, WebP od wersji 5.8.
Nie. WordPress pozwala wgrywać i przetwarzać pliki w tych formatach, ale nie konwertuje automatycznie istniejących JPEG i PNG. Do konwersji potrzebna jest wtyczka (ShortPixel, Imagify, EWWW) lub usługa CDN z automatyczną konwersją (Cloudflare Polish).
Atrybut fetchpriority=high informuje przeglądarkę, by pobrała obraz z najwyższym priorytetem. Domyślnie obrazy mają niski priorytet i czekają za CSS i JS. WordPress od wersji 6.3 automatycznie dodaje go do prawdopodobnego obrazu LCP, co poprawia LCP o 5 do 10%.
Tak, jeśli jest zastosowany do obrazu LCP (above the fold). Lazy loading opóźnia pobranie do obliczenia layoutu, co dodaje setki milisekund. WordPress od wersji 5.9 pomija lazy loading dla pierwszych obrazów, ale motywy i page buildery mogą to nadpisywać. Obraz LCP powinien mieć loading=eager i fetchpriority=high.
Obrazy to 40 do 60% wagi strony. Konwersja do AVIF/WebP, kompresja, prawidłowe wymiary i responsive images mogą zmniejszyć wagę strony o 50 do 70%. Przekłada się to na szybszy LCP, niższe koszty transferu i lepsze wyniki Core Web Vitals.
Tak. Zdjęcia z aparatu (4000 do 8000 px) to częsty błąd. WordPress generuje miniaturki, ale oryginał zostaje na serwerze. Przeskaluj do maksymalnej potrzebnej szerokości (1200 do 1920 px dla pełnej szerokości) przed wgraniem. WordPress od wersji 5.3 ogranicza duże obrazy do 2560 px, ale to wciąż za dużo.
