---
title: "AVIF czy WebP: jakie formaty obrazów serwują polskie strony"
description: "Dwie na pięć stron głównych .pl z obrazami serwują WebP, prawie żadna AVIF, a ponad jedna czwarta ładuje leniwie pierwszy obraz. Ile to kosztuje w LCP."
canonical_url: "https://www.outofplace.space/pl/blog/avif-czy-webp-polskie-strony"
language: "pl"
last_updated: "2026-11-10"
alternates:
  en: "https://www.outofplace.space/blog/image-formats-polish-web.md"
---

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

> Dwie na pięć stron głównych .pl z obrazami serwują WebP, prawie żadna AVIF, a ponad jedna czwarta ładuje leniwie pierwszy obraz. Ile to kosztuje w LCP.

Opublikowano 2026-11-10 · Kategoria: Wydajność · Tagi: Obrazy, Core Web Vitals, Polska

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](https://tranco-list.eu/list/Y8YYG/full), która odpowiedziała 30 października 2026, czyli tę samą próbkę co w badaniu [WordPressa i innych CMS-ów na polskich stronach](https://www.outofplace.space/pl/blog/wordpress-w-polsce-popularnosc-cms), i sprawdziliśmy każdą stronę w [Chrome UX Report](https://developer.chrome.com/docs/crux), 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.

- 41% stron głównych .pl z obrazami serwuje WebP, 2,4% AVIF. Spośród wszystkich policzonych obrazów rastrowych JPEG i PNG to nadal mniej więcej dwa na trzy.
- Nowoczesne formaty idą w parze z platformą: serwuje je 74% stron głównych na Shoperze i 73% na IdoSellu, polskich platformach sklepowych, wobec 39% na WordPressie.
- 28% stron głównych ładuje leniwie pierwszy obraz treści w HTML, czyli obraz, który najpewniej jest obrazem hero.
- Pierwszy obraz z priorytetem idzie w parze z obrazem LCP, który na telefonach zaczyna się ładować wcześniej; leniwe ładowanie wszystkich obrazów z najdłuższym czekaniem. Odsetek stron z dobrym LCP prawie się nie różni.

## 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ą.

**Dwie na pięć stron głównych .pl serwują WebP; AVIF prawie nie występuje** (Odsetek stron głównych .pl z obrazem rastrowym, które co najmniej raz serwują dany format w elemencie img, źródle elementu picture lub preloadzie obrazu · przedziały 95%)

| 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 |

Source: Spis Outofplace, 30 paź 2026; lista Tranco Y8YYG. Chart: https://www.outofplace.space/data/blog/image-formats-polish-web/charts/pl/chart-dwie-na-piec-stron-glownych-pl-serwuja-webp-avif-prawie-nie-wyst.png Data: https://www.outofplace.space/data/blog/image-formats-polish-web/2026-10-30/adoption.csv

„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.

**JPEG i PNG to nadal większość obrazów na polskich stronach głównych** (Obrazy rastrowe według najnowocześniejszego formatu, jaki oferują: wszystkie elementy img ze wszystkich stron głównych razem oraz pierwszy obraz treści każdej strony · formaty usług obrazów, GIF i nierozpoznane w ostatnim segmencie)

| 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 |

Source: Spis Outofplace, 30 paź 2026. Chart: https://www.outofplace.space/data/blog/image-formats-polish-web/charts/pl/chart-jpeg-i-png-to-nadal-wiekszosc-obrazow-na-polskich-stronach-glown.png Data: https://www.outofplace.space/data/blog/image-formats-polish-web/2026-10-30/formats.csv

### 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.

**Strony główne na Shoperze, IdoSellu i frameworkach najczęściej serwują nowoczesne formaty** (Odsetek stron głównych .pl z obrazem rastrowym, które serwują jakikolwiek AVIF, WebP lub format usługi obrazów, według rozpoznanego CMS lub platformy · przedziały 95%)

| 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 |

Source: Spis Outofplace, 30 paź 2026; grupy CMS z naszego badania WordPressa. Chart: https://www.outofplace.space/data/blog/image-formats-polish-web/charts/pl/chart-strony-glowne-na-shoperze-idosellu-i-frameworkach-najczesciej-se.png Data: https://www.outofplace.space/data/blog/image-formats-polish-web/2026-10-30/adoption.csv

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](https://nextjs.org/docs/app/api-reference/components/image#formats) 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](https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Image_types#avif_image) 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](https://developers.google.com/search/docs/appearance/google-images?hl=pl#supported-image-formats) 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](https://developers.google.com/search/docs/crawling-indexing/javascript/lazy-loading?hl=pl) 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](https://web.dev/articles/preload-scanner?hl=pl), więc nawet obraz hero czeka na skrypt.

**Połowa stron głównych .pl ładuje obrazy leniwie natywnie; jedna trzecia używa fetchpriority** (Odsetek stron głównych .pl z obrazem rastrowym, które co najmniej raz używają danej wskazówki ładowania · przedziały 95%)

| 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 |

Source: Spis Outofplace, 30 paź 2026. Chart: https://www.outofplace.space/data/blog/image-formats-polish-web/charts/pl/chart-polowa-stron-glownych-pl-laduje-obrazy-leniwie-natywnie-jedna-tr.png Data: https://www.outofplace.space/data/blog/image-formats-polish-web/2026-10-30/adoption.csv

## Czy obraz hero ładować leniwie?

Nie. [Przewodnik web.dev o LCP](https://web.dev/articles/optimize-lcp?hl=pl) 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.

**Na ponad ćwierci stron pierwszy obraz ładuje się leniwie** (Jak ładuje się pierwszy obraz treści w HTML, według grupy CMS: leniwie (loading="lazy" lub skrypt), z priorytetem (fetchpriority="high" lub preload obrazu) albo domyślnie · n dla każdego wiersza w tabeli)

| 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 |

Source: Spis Outofplace, 30 paź 2026; grupy CMS z naszego badania WordPressa. Chart: https://www.outofplace.space/data/blog/image-formats-polish-web/charts/pl/chart-na-ponad-cwierci-stron-pierwszy-obraz-laduje-sie-leniwie.png Data: https://www.outofplace.space/data/blog/image-formats-polish-web/2026-10-30/adoption.csv

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](https://make.wordpress.org/core/2023/07/13/image-performance-enhancements-in-wordpress-6-3/): 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.

**Gdy pierwszy obraz ma priorytet, telefony wcześniej zaczynają pobierać obraz LCP** (Mediana wśród stron opóźnienia ładowania obrazu LCP na telefonach (p75), według tego, jak w HTML ładuje się pierwszy obraz treści · strony, których LCP jest obrazem na co najmniej połowie wyświetleń · przedziały bootstrap 95%)

| 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 |

Source: Chrome UX Report, 8 paź – 4 lis 2026; spis Outofplace, 30 paź 2026. Chart: https://www.outofplace.space/data/blog/image-formats-polish-web/charts/pl/chart-gdy-pierwszy-obraz-ma-priorytet-telefony-wczesniej-zaczynaja-pob.png Data: https://www.outofplace.space/data/blog/image-formats-polish-web/2026-10-30/field.csv

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.

```html
<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](https://pagespeed.web.dev/) 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](https://www.outofplace.space/pl/blog/jak-sprawdzic-szybkosc-strony#dane-laboratoryjne-a-dane-z-terenu-skad-roznica-z-pagespeed-insights).

## Jak mierzyliśmy

Strony główne pochodzą z naszego spisu z 30 października 2026, wykonanego przez `OutofplaceResearchBot` (zobacz, [co pobiera nasz crawler i jak go zablokować](https://www.outofplace.space/pl/bot)), który najpierw czyta robots.txt i pobiera tylko stronę główną: 7648 z 9208 domen .pl z listy Tranco odpowiedziało kodem HTML, a po połączeniu domen przekierowujących pod ten sam adres zostało 7415 różnych stron.

Czytaliśmy HTML każdej strony głównej tak, jak przyszedł, bez uruchamiania skryptów: każdy `<img>` poza `<noscript>`, `<template>`, komentarzami i skryptami, z jego `src`, `srcset`, atrybutami skryptów lazy loadingu, `loading`, `fetchpriority`, `width` i `height`; elementy `<source>` każdego `<picture>`; oraz `<link rel="preload" as="image">`. Piksele śledzące, zaślepki data: i pliki-wypełniacze nie liczą się jako obrazy. Formatem obrazu jest najnowocześniejszy format, jaki oferuje. Grupy CMS pochodzą z [naszego badania WordPressa](https://www.outofplace.space/pl/blog/wordpress-w-polsce-popularnosc-cms#ile-polskich-stron-dziala-na-wordpressie) na tym samym spisie; grupy poniżej 30 stron głównych trafiają do „Innych”.

Dane terenowe to rekord Chrome UX Report dla telefonów dla każdej strony, zebrany od 8 października do 4 listopada 2026: ma go 5771 z 7415 stron. Dobre LCP oznacza p75 najwyżej 2,5 s. Części LCP to wartości p75 z wyświetleń, w których elementem LCP jest obraz; ich mediany wśród stron mają przedziały bootstrap z 10 000 losowań, a różnice odsetków przedziały Newcombe’a. Strona ma obraz jako LCP, gdy obraz jest elementem LCP na co najmniej połowie jej wyświetleń na telefonach. Porównania ustaliliśmy przed odczytaniem danych terenowych.

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.

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

- [Optymalizacja Largest Contentful Paint (web.dev)](https://web.dev/articles/optimize-lcp?hl=pl): Cztery składowe LCP, dlaczego obrazu LCP nigdy nie ładuje się leniwie i kiedy używać fetchpriority.

- [Naprawianie leniwie ładowanych treści (Google Search Central)](https://developers.google.com/search/docs/crawling-indexing/javascript/lazy-loading?hl=pl): Jak ładować obrazy leniwie, żeby Google nadal je widział i indeksował.

- [Przewodnik po typach i formatach obrazów (MDN)](https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Image_types): AVIF, WebP, JPEG i PNG w porównaniu, z obsługą w przeglądarkach i zapasem przez  .

- [Core Web Vitals sklepów: która platforma jest najszybsza?](https://www.outofplace.space/pl/blog/core-web-vitals-sklepow-internetowych): Nasze badanie polskich sklepów: na jakich platformach działają i jak wypadają w Core Web Vitals.