AVIF czy WebP: jakie formaty obrazów serwują polskie strony

AVIF czy WebP? Na polskim internecie to pytanie wciąż prawie nikogo nie dotyczy. Spośród popularnych stron głównych .pl z obrazami, które przeczytaliśmy, 41% serwuje gdzieś WebP, a tylko 2,4% AVIF; większość obrazów to nadal JPEG i PNG. Większy problem to kolejność, nie format: na 28% stron głównych pierwszy obraz treści jest ładowany leniwie, a tylko 15% oznacza go atrybutem fetchpriority="high". Dane od prawdziwych użytkowników Chrome pokazują, gdzie to kosztuje czas: na stronach, których największym elementem jest zwykle obraz, telefony zaczynają go pobierać w medianie 231 ms po pierwszym bajcie, gdy pierwszy obraz ma priorytet, i 346 ms, gdy jest ładowany leniwie.

Przeczytaliśmy HTML każdej strony głównej .pl z listy popularnych stron Tranco (otwiera się w nowej karcie), która odpowiedziała 30 października 2026, czyli tę samą próbkę co w badaniu WordPressa i innych CMS-ów na polskich stronach, i sprawdziliśmy każdą stronę w Chrome UX Report (otwiera się w nowej karcie), czyli danych Google o tym, jak strony działają u prawdziwych użytkowników Chrome. HTML mówi, o jakie formaty i wskazówki ładowania prosi strona; CrUX mówi, jak szybko na telefonach pojawia się jej największy obraz.

przeczytanych stron głównych .pl

7415

serwuje WebP

41%

serwuje AVIF

2,4%

ładuje leniwie pierwszy obraz

28%

AVIF czy WebP: co serwują polskie strony główne?

Przeczytaliśmy każdy <img> na każdej stronie głównej, z jego srcset, atrybutami, których używają skrypty lazy loadingu (data-src i podobne), oraz elementami <source> jego <picture>. Format braliśmy z rozszerzenia pliku, z parametru formatu w adresie (format=webp, fm=avif) albo z atrybutu type źródła w <picture>. 6802 z 7415 stron głównych pokazuje co najmniej jeden obraz rastrowy (nie SVG i nie piksel śledzący); wszystkie odsetki niżej dotyczą tych stron.

Polski internet przyjął WebP: 41% stron głównych serwuje co najmniej jeden obraz WebP. AVIF jest przy nim błędem zaokrąglenia. Niewielka grupa stron zostawia wybór usłudze obrazów, co widać w adresie (/_next/image w Next.js, f_auto w Cloudinary, format=auto w Cloudflare); taka usługa wysyła AVIF lub WebP przeglądarkom, które je akceptują.

WebP41%

AVIF2,4%

Format wybierany przez usługę obrazów2,2%

Element picture ze źródłem AVIF lub WebP9,6%

Źródło: Spis Outofplace, 30 paź 2026; lista Tranco Y8YYGPobierz CSVPobierz PNG

Pokaż dane

Pozycja	Wartość	Przedział 95%	n
WebP	41%	40%–42%	6802
AVIF	2,4%	2,1%–2,8%	6802
Format wybierany przez usługę obrazów	2,2%	1,8%–2,5%	6802
Element picture ze źródłem AVIF lub WebP	9,6%	8,9%–10%	6802

Wykres jako obraz. Możesz go użyć na licencji CC BY 4.0, podając Outofplace jako źródło i link do tej strony.

„Serwuje gdzieś WebP” to niska poprzeczka: liczy się nawet jeden baner WebP wśród trzydziestu plików JPEG. Licząc obraz po obrazie, JPEG i PNG to nadal większość tego, co wysyłają polskie strony główne, a pierwszy obraz treści nie jest nowocześniejszy od reszty.

• AVIF
• WebP
• JPEG
• PNG
• GIF, usługa obrazów, inne

Wszystkie obrazy rastrowen = 384 25423%42%25%

Pierwszy obraz treścin = 647522%36%32%

Źródło: Spis Outofplace, 30 paź 2026Pobierz CSVPobierz PNG

Pokaż dane

Pozycja	AVIF	WebP	JPEG	PNG	GIF, usługa obrazów, inne	n
Wszystkie obrazy rastrowe	1,2%	23%	42%	25%	8,2%	384 254
Pierwszy obraz treści	1,2%	22%	36%	32%	8,2%	6475

Wykres jako obraz. Możesz go użyć na licencji CC BY 4.0, podając Outofplace jako źródło i link do tej strony.

Które platformy najczęściej serwują WebP?

Nowoczesne formaty idą w parze z platformą. Strony główne na Shoperze i IdoSellu, dwóch polskich platformach sklepów w abonamencie, serwują je znacznie częściej niż średnia, choć mniej więcej jedna czwarta z nich nadal nie serwuje AVIF, WebP ani formatu usługi obrazów. Strony zbudowane na frameworku JavaScript bez widocznego CMS są z nimi na równi. WordPress i PrestaShop są poniżej średniej, podobnie jak strony główne bez rozpoznanego CMS.

Shoper74%

IdoSell73%

Framework JS, bez śladu CMS68%

Inne CMS-y i platformy53%

WordPress39%

Nie rozpoznano CMS38%

PrestaShop36%

Joomla30%

Wszystkie strony główne: 43%

Źródło: Spis Outofplace, 30 paź 2026; grupy CMS z naszego badania WordPressaPobierz CSVPobierz PNG

Pokaż dane

Pozycja	Wartość	Przedział 95%	n
Shoper	74%	68%–79%	221
IdoSell	73%	66%–78%	215
Framework JS, bez śladu CMS	68%	64%–73%	409
Inne CMS-y i platformy	53%	50%–57%	695
WordPress	39%	37%–42%	1640
Nie rozpoznano CMS	38%	36%–39%	3004
PrestaShop	36%	32%–40%	500
Joomla	30%	22%–38%	118

Wykres jako obraz. Możesz go użyć na licencji CC BY 4.0, podając Outofplace jako źródło i link do tej strony.

Pozycja w rankingu nie robi widocznej różnicy: 100 najpopularniejszych stron głównych .pl serwuje nowoczesny format mniej więcej tak samo często jak pozostałe.

Format AVIF: czy jest lepszy niż WebP?

Pod względem wielkości pliku zwykle tak. Dokumentacja obrazów w Next.js (otwiera się w nowej karcie) podaje, że AVIF jest o około 20% mniejszy niż WebP, a koduje się około 50% dłużej, i nadal poleca WebP w większości zastosowań; dlatego Next.js serwuje WebP, dopóki strona nie włączy AVIF. Dekodowanie działa już wszędzie, gdzie to ważne: MDN podaje obsługę AVIF (otwiera się w nowej karcie) od Chrome 85, Firefoksa 93, Safari 16.1 i Edge 121 (stan na 7 listopada 2026), a WebP w każdej aktualnej wersji tych przeglądarek.

Nasze dane nie powiedzą, który format przyspiesza stronę: nieliczne strony z AVIF różnią się od reszty zbyt wieloma innymi cechami. Pokazują za to, gdzie leży zysk dla polskiej strony. Większość stron głównych nie zrobiła jeszcze pierwszego kroku, z JPEG i PNG na którykolwiek nowoczesny format, i dla nich wybór AVIF czy WebP ma mniejsze znaczenie niż sam ten krok. Wyszukiwarka Google indeksuje oba: jej wytyczne dotyczące obrazów (otwiera się w nowej karcie) wymieniają WebP i AVIF wśród obsługiwanych formatów, obok JPEG i PNG.

Czy lazy loading obrazków szkodzi SEO?

Nie, jeśli robi to przeglądarka. Przewodnik Google o leniwym ładowaniu (otwiera się w nowej karcie) wymienia wbudowany w przeglądarkę lazy loading jako sposób, przy którym Google nadal widzi obrazy, i ostrzega tylko przed treścią, która czeka na przewinięcie lub kliknięcie, bo Googlebot nie wchodzi w interakcję ze stroną. Chodzi o natywny atrybut loading="lazy", którego używa 51% polskich stron głównych z obrazami.

Starszy sposób to skrypt: prawdziwy adres leży w data-src, w src stoi zaślepka, a JavaScript podmienia je, gdy obraz wjeżdża w widok. 23% stron głównych z obrazami nadal ładuje tak co najmniej jeden obraz. Dla Google to działa, jeśli skrypt reaguje na widok, a nie na przewijanie, ale ukrywa obraz przed skanerem wstępnego ładowania przeglądarki (otwiera się w nowej karcie), więc nawet obraz hero czeka na skrypt.

loading="lazy"51%

Lazy loading skryptem23%

srcset31%

fetchpriority="high"31%

Preload obrazka16%

Szerokość i wysokość na każdym obrazku17%

Źródło: Spis Outofplace, 30 paź 2026Pobierz CSVPobierz PNG

Pokaż dane

Pozycja	Wartość	Przedział 95%	n
loading="lazy"	51%	50%–52%	6802
Lazy loading skryptem	23%	22%–24%	6802
srcset	31%	30%–32%	6802
fetchpriority="high"	31%	30%–32%	6802
Preload obrazka	16%	15%–17%	6802
Szerokość i wysokość na każdym obrazku	17%	16%–18%	6802

Wykres jako obraz. Możesz go użyć na licencji CC BY 4.0, podając Outofplace jako źródło i link do tej strony.

Czy obraz hero ładować leniwie?

Nie. Przewodnik web.dev o LCP (otwiera się w nowej karcie) mówi wprost: nigdy nie ładuj leniwie obrazu LCP, bo przeglądarka czeka wtedy, aż układ strony pokaże, że obraz jest na ekranie, i dopiero potem zaczyna go pobierać. Bez renderowania strony nie widzimy, który obraz jest jej elementem LCP, więc wzięliśmy najlepsze przybliżenie: pierwszy obraz treści w HTML, czyli pierwszy obraz rastrowy, który nie jest pikselem śledzącym, logo, ikoną ani obrazkiem mniejszym niż 100 pikseli. W próbce sprawdzonej ręcznie 19 z 24 takich wyborów to były rzeczywiste obrazy treści.

Na 28% stron głównych ten obraz jest ładowany leniwie: na 19% atrybutem loading="lazy", na 9,1% skryptem. Część tych stron ma nad nim tło CSS albo tekst, więc nie każdy przypadek jest błędem. Ale 7,1% stron głównych z co najmniej dwoma obrazami ładuje leniwie każdy z nich, a na takich stronach obraz, który jest elementem LCP, czeka na pewno.

• Ładowany leniwie
• Domyślnie przeglądarki
• Z priorytetem

Wszystkie strony głównen = 647528%55%17%

WordPressn = 158432%43%25%

PrestaShopn = 49936%53%

Shopern = 21231%57%12%

IdoSelln = 21325%30%45%

Joomlan = 11514%85%

Framework JS, bez śladu CMSn = 39537%18%45%

Nie rozpoznano CMSn = 277121%70%

Inne CMS-y i platformyn = 68640%48%12%

Źródło: Spis Outofplace, 30 paź 2026; grupy CMS z naszego badania WordPressaPobierz CSVPobierz PNG

Pokaż dane

Pozycja	Ładowany leniwie	Domyślnie przeglądarki	Z priorytetem	n
Wszystkie strony główne	28%	55%	17%	6475
WordPress	32%	43%	25%	1584
PrestaShop	36%	53%	11%	499
Shoper	31%	57%	12%	212
IdoSell	25%	30%	45%	213
Joomla	14%	85%	0,9%	115
Framework JS, bez śladu CMS	37%	18%	45%	395
Nie rozpoznano CMS	21%	70%	8,9%	2771
Inne CMS-y i platformy	40%	48%	12%	686

Wykres jako obraz. Możesz go użyć na licencji CC BY 4.0, podając Outofplace jako źródło i link do tej strony.

Strony na frameworkach i sklepy na IdoSellu najczęściej nadają pierwszemu obrazowi priorytet, IdoSell prawie zawsze preloadem obrazu, a nie atrybutem fetchpriority. WordPress robi to na mniej więcej jednej czwartej stron głównych, co zgadza się z tym, co robi jego rdzeń od WordPressa 6.3 (otwiera się w nowej karcie): dodaje fetchpriority="high" do obrazu, który uznaje za najbardziej prawdopodobny element LCP, i zostawia pierwsze obrazy strony bez loading="lazy". Strony główne na Joomli i bez rozpoznanego CMS ładują leniwie pierwszy obraz rzadziej niż średnia. Strony bez rozpoznanego CMS rzadziej też używają natywnego lazy loadingu w ogóle: loading="lazy" ma 35% z nich, wobec 51% wszystkich stron głównych z obrazami.

Jak nadać priorytet obrazowi LCP?

Atrybutem fetchpriority="high" na tym jednym <img> albo preloadem obrazu w <head>, gdy obraz jest tłem CSS, które przeglądarka znalazłaby późno. 15% stron głównych daje pierwszemu obrazowi treści fetchpriority="high", a 6% go preloaduje.

Ta wskazówka często trafia w zły obraz. Spośród stron głównych z fetchpriority="high" na jakimkolwiek obrazie 14% daje go tylko logo, ikonie lub plikowi SVG, a na 0,8% stron głównych z obrazami jeden obraz ma jednocześnie loading="lazy" i fetchpriority="high", czyli dwie wskazówki, które ciągną w przeciwne strony.

Ile kosztuje w LCP leniwe ładowanie obrazu hero?

Chrome UX Report dzieli LCP obrazu na cztery części: czas do pierwszego bajtu, opóźnienie ładowania zasobu (od pierwszego bajtu do chwili, gdy przeglądarka zaczyna pobierać obraz), czas pobierania i opóźnienie renderowania. Lazy loading i fetchpriority działają na drugą z nich. Na 3757 stronach elementem LCP jest obraz na co najmniej połowie wyświetleń na telefonach. Porównaliśmy 3529 z nich, których strona główna ma pierwszy obraz treści, według tego, jak ten obraz się ładuje.

Ładowany leniwie346 ms

Domyślnie przeglądarki315 ms

Z priorytetem231 ms

0 ms100 ms200 ms300 ms400 ms

Źródło: Chrome UX Report, 8 paź – 4 lis 2026; spis Outofplace, 30 paź 2026Pobierz CSVPobierz PNG

Pokaż dane

Pozycja	Wartość	Zakres	n
Ładowany leniwie	346 ms	326 ms–372 ms	1062
Domyślnie przeglądarki	315 ms	298 ms–328 ms	1783
Z priorytetem	231 ms	217 ms–249 ms	673

Wykres jako obraz. Możesz go użyć na licencji CC BY 4.0, podając Outofplace jako źródło i link do tej strony.

Kolejność jest taka, jak przewidują zalecenia: mediana 231 ms przy pierwszym obrazie z priorytetem, 315 ms przy domyślnym ładowaniu i 346 ms przy leniwym. Grupa z priorytetem wyraźnie odstaje od dwóch pozostałych; różnica między leniwym a domyślnym ładowaniem jest mniejsza.

Na główny wskaźnik ta różnica ledwo się przekłada. 85% polskich stron z danymi terenowymi ma dobre LCP na telefonach (najwyżej 2,5 s przy p75), a mediana LCP wynosi 1681 ms. Wśród stron, których LCP jest obrazem, dobre LCP ma 85% stron z leniwie ładowanym pierwszym obrazem, 87% z domyślnym i 88% z priorytetem, a przedziały na siebie zachodzą. Opóźnienie ładowania to jedna z czterech części i różnica tej wielkości rzadko decyduje o tym, czy strona przechodzi próg.

Wyjątkiem są strony główne, które ładują leniwie każdy swój obraz; to porównanie obejmuje wszystkie strony w CrUX, nie tylko te z obrazem jako LCP. 372 takich stron z danymi o opóźnieniu ładowania ma jego medianę 499 ms wobec 317 ms u pozostałych 4731. Spośród 387 takich stron z danymi o LCP dobre LCP ma 82%, wobec 86% pozostałych; 95-procentowy przedział tej różnicy ledwo nie obejmuje zera.

To korelacje, nie eksperymenty. Strony różnią się platformą, hostingiem, wagą i odbiorcami; CrUX obejmuje wszystkie strony serwisu, nie tylko główną; a pierwszy obraz treści w HTML zastępuje element LCP.

Obrazy w tle CSS: czego HTML nie pokazuje

Obraz hero ustawiony jako tło CSS nigdy nie pojawia się jako <img>, więc większość tego badania go nie widzi. HTML daje dolną granicę: 37% stron głównych ustawia co najmniej jedno tło obrazkowe w atrybucie style lub bloku <style>. Do tego dochodzą tła w zewnętrznych arkuszach stylów, których nie pobieraliśmy. Tło nie przyjmie loading="lazy" ani fetchpriority na własnym elemencie; przeglądarka znajduje je dopiero po pobraniu arkusza stylów i do tego służy preload obrazu w <head>.

Jak serwować AVIF z WebP jako zapasem i ładować hero najpierw

Lista kontrolna w kolejności, w jakiej przeglądarka spotyka obraz:

1. Zaproponuj AVIF, WebP i zapas w jednym elemencie picture

   Wypisz źródła od najwydajniejszego do najmniej wydajnego; przeglądarka bierze pierwszy typ, który obsługuje. W <img> zostaw JPEG lub PNG dla pozostałych i podaj prawdziwe width i height, żeby strona nie przeskakiwała w trakcie ładowania.

   <picture>
     <source type="image/avif" srcset="/hero-800.avif 800w, /hero-1600.avif 1600w" sizes="100vw" />
     <source type="image/webp" srcset="/hero-800.webp 800w, /hero-1600.webp 1600w" sizes="100vw" />
     <img src="/hero-1600.jpg" width="1600" height="900" alt="Co przedstawia obraz" fetchpriority="high" />
   </picture>

2. Albo zostaw wybór usłudze obrazów, która czyta nagłówek Accept

   Komponent obrazów Next.js, Cloudinary (f_auto), imgix (auto=format) i Cloudflare Images (format=auto) wysyłają z jednego adresu AVIF lub WebP przeglądarkom, których nagłówek Accept o nie prosi. Wtedy wystarczy jeden <img> z srcset.

3. Nigdy nie ładuj leniwie obrazu na górze strony

   Nie dawaj obrazowi hero atrybutu loading (albo ustaw loading="eager") i nie oddawaj go skryptowi lazy loadingu. Sprawdź wtyczki i kreatory stron: na WordPressie wtyczka do lazy loadingu potrafi cofnąć to, co robi rdzeń.

4. Nadaj wysoki priorytet jednemu obrazowi

   Daj fetchpriority="high" obrazowi, który najpewniej jest elementem LCP, a nie logo. Jeśli hero to tło CSS, preloaduj je: <link rel="preload" as="image" href="/hero.avif" type="image/avif" fetchpriority="high">.

5. Wszystko poniżej pierwszego ekranu ładuj leniwie, natywnie

   Dawaj loading="lazy" obrazom niżej na stronie. Nie potrzeba do tego skryptu, a Google indeksuje tak ładowane obrazy.

6. Sprawdź wynik na prawdziwych telefonach

   Otwórz PageSpeed Insights (otwiera się w nowej karcie) dla swojej strony głównej: dane terenowe to ten sam Chrome UX Report, którego użyliśmy, a rozbicie LCP pokazuje, jak długo obraz czekał, zanim zaczął się ładować. Wyniki laboratoryjne i terenowe często się różnią; nasz poradnik wyjaśnia, skąd różnica między danymi laboratoryjnymi a terenowymi.

Jak mierzyliśmy

Jak sprawdziliśmy regułę pierwszego obrazu treści

Wylosowaliśmy próbkę stron głównych z ustalonym ziarnem, w połowie takich, których pierwszy obraz treści reguły uznały za ładowany leniwie, a w połowie pozostałych, i ręcznie przeczytaliśmy znacznik wybranego obrazu i jego sąsiadów. 19 z 24 wyborów to były obrazy treści (zdjęcia, banery, produkty, obrazy artykułów); pozostałe pięć to grafika nawigacji, logo partnera, dekoracja, ikona aplikacji zmniejszona przez CSS i odznaka BIP. Format, loading i fetchpriority były odczytane poprawnie we wszystkich 24. Odsetki dotyczące pierwszego obrazu to więc przybliżenie obrazu hero, a nie liczba obrazów LCP; etykiety są w zbiorze danych.

Czego te dane nie powiedzą

Widzieliśmy tylko stronę główną, w HTML, jaki przyszedł, i nie uruchamialiśmy niczego. Obrazy wstawiane skryptem po załadowaniu, obrazy w zewnętrznych arkuszach stylów i format negocjowany przez CDN bez śladu w adresie (jak Cloudflare Polish) są dla nas niewidoczne, więc odsetki nowoczesnych formatów to dolna granica. Pierwszy obraz treści w HTML nie zawsze jest elementem LCP: może nim być drugi slajd slidera, tło CSS albo nagłówek. Strony główne większe niż 1 MiB (319) były ucinane, co może ukryć obrazy niżej. Dane terenowe obejmują wszystkie strony serwisu, nie tylko główną, a każda różnica w nich to korelacja między stronami, które różnią się też hostingiem, platformą, wagą strony i odbiorcami.

Do poczytania