Optymalizacja obrazów na stronie: WebP, AVIF, srcset i LCP
Jak przygotować zdjęcia na stronę: WebP czy AVIF, srcset i sizes, lazy loading i fetchpriority dla lepszego LCP. Praktyczny poradnik z listą kontrolną.

Optymalizacja obrazów na stronie internetowej to cztery decyzje: jaki format wybrać, w jakich wymiarach wysłać plik, jak mocno go skompresować i kiedy przeglądarka ma go pobrać. Sama kompresja w darmowym narzędziu online to tylko jeden z tych kroków. W tym poradniku pokazuję, jak podchodzę do zdjęć w projektach dla klientów: od wyboru między WebP a AVIF, przez atrybuty srcset i sizes, po ustawienie priorytetu głównego zdjęcia, które najczęściej decyduje o wyniku LCP w Google. Na końcu znajdziesz listę kontrolną, którą możesz przejść na własnej stronie w jedno popołudnie.
TL;DR
- Zacznij od wymiarów: zdjęcie 4000 px wgrane w miejsce, które ma 800 px szerokości, to najczęstszy i najdroższy błąd.
- AVIF daje zwykle mniejsze pliki niż WebP, ale wymaga zapasowego formatu. WebP to bezpieczny standard, JPEG zostaje jako fallback.
- Atrybuty
srcsetisizespozwalają telefonowi pobrać mniejszą wersję tego samego zdjęcia. - Główne zdjęcie w pierwszym widoku ładuj bez
loading="lazy"i zfetchpriority="high". Pozostałe ładuj leniwie. - Każde zdjęcie z treścią potrzebuje opisowego atrybutu
alt: to wymóg dostępności i wsparcie dla widoczności w Grafice Google.
1. Dlaczego to właśnie obrazy najczęściej spowalniają stronę
Zespół Chrome w kursie o wydajności obrazów na web.dev wskazuje, że obrazy są często najcięższym i najczęściej występującym zasobem w sieci. Kod HTML, CSS i JavaScript strony firmowej to zwykle kilkaset kilobajtów. Jedno nieprzygotowane zdjęcie z aparatu lub telefonu potrafi ważyć kilka megabajtów.
W audytach, które robię, problem prawie nigdy nie wynika z jednego pliku. Zwykle to suma drobnych zaniedbań:
- zdjęcia wgrywane prosto z telefonu, bez zmiany wymiarów,
- jeden plik serwowany wszystkim urządzeniom, od smartfona po monitor 27 cali,
- stare formaty (PNG dla fotografii, JPEG bez kompresji),
- leniwe ładowanie włączone dla wszystkich obrazów, także tego najważniejszego na górze strony,
- brak atrybutów
widthiheight, przez co układ strony „skacze” w trakcie ładowania.
Każdy z tych punktów da się naprawić osobno. Największy efekt widać jednak wtedy, gdy obrazami zarządza się jako systemem: jeden proces przygotowania pliku, kilka rozmiarów, nowoczesny format i świadoma kolejność ładowania.
2. WebP czy AVIF: który format wybrać
To pytanie zadaje mi prawie każdy klient, który zaczyna interesować się szybkością strony. Krótka odpowiedź: oba, w odpowiedniej kolejności.
Według Alliance for Open Media, organizacji rozwijającej format AVIF, AVIF pozwala uzyskać pliki mniejsze o ponad 50% w porównaniu z JPEG przy podobnej jakości, a w porównaniu z WebP oszczędność przekracza 30%. Dodatkowo obsługuje szerszą gamę kolorów i HDR. Cloudinary w swoim przeglądzie nowoczesnych formatów opisuje WebP jako format rekomendowany przez Google do użytku w sieci, a AVIF jako kolejną generację z lepszą kompresją.
Wybór nie jest jednak zero-jedynkowy. Poradnik web.dev o wyborze formatu obrazu zaczyna od pytania, czy obraz jest w ogóle potrzebny. Ikonę lub prosty kształt często lepiej narysować w SVG albo CSS niż wysyłać jako bitmapę.
| Format | Najlepsze zastosowanie | Mocne strony | Na co uważać |
|---|---|---|---|
| AVIF | zdjęcia produktowe, hero, galerie | najmniejsze pliki, HDR, przezroczystość | dłuższe kodowanie, potrzebny fallback dla starszych przeglądarek |
| WebP | zdjęcia i grafiki z przezroczystością | bardzo szerokie wsparcie, dobra kompresja | przy tej samej jakości zwykle cięższy niż AVIF |
| JPEG | fallback dla fotografii | działa wszędzie | wyraźnie większe pliki |
| PNG | zrzuty ekranu, grafiki z ostrymi krawędziami | bezstratny | nie nadaje się do zdjęć, pliki są ogromne |
| SVG | logo, ikony, ilustracje wektorowe | ostry w każdym rozmiarze, lekki | nie zastąpi fotografii |
W praktyce stosuję element <picture>: przeglądarka dostaje najpierw AVIF, potem WebP, a na końcu JPEG. Każda pobiera pierwszy format, który rozumie, więc nikt nie zobaczy pustego miejsca zamiast zdjęcia.
3. Wymiary i kompresja: od tego zacznij
Zanim zmienisz format, sprawdź wymiary. Jeśli kontener na stronie ma 1200 px szerokości, plik o szerokości 5000 px nie poprawi jakości. Przeglądarka i tak go zmniejszy, ale dopiero po pobraniu wszystkich bajtów.
Moje robocze zasady dla typowej strony firmowej lub sklepu:
- zdjęcie w pełnej szerokości (hero): wersje 640, 1280 i 1920 px,
- zdjęcie w treści artykułu: maksymalnie około 1200 px, plus mniejsza wersja dla telefonów,
- miniatury produktów i kafelki: dokładnie tyle, ile wynosi kafelek, razy dwa dla ekranów o wysokiej gęstości pikseli,
- jakość kompresji: zaczynam od średnich ustawień i porównuję wynik z oryginałem w powiększeniu. Jeśli nie widzę różnicy, schodzę niżej.
Do pojedynczych plików wystarczy darmowy program graficzny albo narzędzie online do kompresji. Przy sklepie z setkami produktów ręczna praca przestaje mieć sens. Wtedy obrazy powinien przygotowywać sam system: CMS lub serwer generuje rozmiary i formaty automatycznie w chwili wgrania pliku. Tak buduję zarówno własny CMS dla stron firmowych, jak i sklepy, żeby osoba dodająca produkt nie musiała pamiętać o kompresji.
Nie zapominaj też o atrybutach width i height w znaczniku <img>. Dzięki nim przeglądarka rezerwuje miejsce na obraz, zanim go pobierze, a treść pod spodem nie przesuwa się w trakcie ładowania.

4. Obrazy responsywne: jak działa srcset i sizes
Szerokość obrazu ustawiona w CSS na 100% sprawia, że zdjęcie mieści się na ekranie. Nie zmienia jednak tego, ile bajtów pobiera telefon. Jak piszą autorzy artykułu o serwowaniu responsywnych obrazów, wysyłanie zdjęć w rozmiarze desktopowym na urządzenia mobilne może zużywać od 2 do 4 razy więcej danych, niż potrzeba.
Rozwiązaniem jest atrybut srcset, w którym podajesz kilka wersji tego samego pliku, oraz sizes, w którym mówisz przeglądarce, jak szeroki będzie obraz na danym ekranie. Przeglądarka sama wybiera najmniejszy plik, który wystarczy do ostrego wyświetlenia. Dobre polskojęzyczne wprowadzenie znajdziesz w kursie web.dev o obrazach elastycznych.
Tak wygląda kompletny przykład, który łączy formaty, rozmiary i priorytet:
<picture>
<source type="image/avif"
srcset="hero-640.avif 640w, hero-1280.avif 1280w, hero-1920.avif 1920w"
sizes="100vw">
<source type="image/webp"
srcset="hero-640.webp 640w, hero-1280.webp 1280w, hero-1920.webp 1920w"
sizes="100vw">
<img src="hero-1280.jpg"
srcset="hero-640.jpg 640w, hero-1280.jpg 1280w, hero-1920.jpg 1920w"
sizes="100vw"
width="1920" height="1080"
alt="Montaż stoiska targowego w hali wystawienniczej w Poznaniu"
fetchpriority="high">
</picture>
Kilka uwag do tego kodu:
- wartość
sizes="100vw"pasuje do zdjęcia na całą szerokość ekranu. Dla obrazu w kolumnie treści wpisz na przykład(max-width: 768px) 100vw, 800px, - deskryptor
woznacza rzeczywistą szerokość pliku w pikselach, nie szerokość na ekranie, fetchpriority="high"ustawiam tylko na jednym, głównym obrazie w pierwszym widoku.
5. Poprawa LCP: priorytet ważniejszy niż kilobajty
LCP (Largest Contentful Paint) mierzy, kiedy na ekranie pojawia się największy element treści. Na większości stron jest to właśnie zdjęcie: baner główny, zdjęcie produktu albo okładka wydarzenia. Według web.dev w tekście o częstych mitach dotyczących LCP dobry wynik to 2,5 sekundy lub mniej, a dane z prawdziwych wizyt pokazują, że strony ze słabym LCP często tracą najwięcej czasu nie na samym pobieraniu obrazu, tylko na opóźnieniu, zanim przeglądarka w ogóle zacznie go pobierać.
To zmienia kolejność działań. Najlżejszy plik AVIF nic nie da, jeśli przeglądarka odkryje go za późno. Dwie najczęstsze przyczyny, które widzę:
loading="lazy"na zdjęciu hero. Leniwe ładowanie świetnie sprawdza się dla obrazów niżej na stronie, ale dla zdjęcia w pierwszym widoku oznacza czekanie, aż przeglądarka obliczy układ strony.- Obraz wstawiony jako tło w CSS lub dodawany przez JavaScript. Przeglądarka nie widzi go w kodzie HTML, więc znajduje go dopiero po pobraniu arkuszy stylów lub skryptów.
Artykuł o Fetch Priority API na web.dev opisuje, jak atrybut fetchpriority="high" podpowiada przeglądarce, że dany obraz jest ważniejszy od innych zasobów, i wprost odradza leniwe ładowanie obrazów widocznych od razu po wejściu na stronę. Przykłady wdrożeń pokazane w tym tekście potwierdzają, że sama zmiana priorytetu potrafi wyraźnie przyspieszyć LCP.
Jest też aspekt projektowy. Główne zdjęcie to często element szerszej identyfikacji kampanii, ten sam motyw, który pojawia się w reklamach i social mediach. Jeśli pracujesz nad spójnym motywem graficznym, przydatny będzie tekst o tym, jak zaprojektować key visual, który działa w social mediach. Na stronie warto zadbać, żeby ten sam motyw był przygotowany w lekkiej wersji: bez tekstu wtopionego w grafikę (tekst lepiej zostawić w HTML) i w rozmiarach dopasowanych do ekranów.
Szybkość strony to oczywiście nie tylko obrazy. Na LCP wpływa też czas odpowiedzi serwera, dlatego przy sklepach zawsze sprawdzam infrastrukturę. Więcej piszę o tym w poradniku o tym, jak wybrać wydajny hosting dla sklepu internetowego.
6. Tekst alternatywny, nazwy plików i Grafika Google
Optymalizacja obrazów to również treść, której nie widać na pierwszy rzut oka. Zgodnie ze standardami Ośrodka Rozwoju Edukacji przygotowanymi według WCAG każda nietekstowa treść merytoryczna, czyli zdjęcia, ikony z funkcją czy wykresy, potrzebuje tekstu alternatywnego. Tę samą zasadę przywołuje dokument UOKiK o dostępności cyfrowej: dla każdej treści nietekstowej trzeba dostarczyć jej tekstowy odpowiednik. Osoba korzystająca z czytnika ekranu usłyszy właśnie treść atrybutu alt.
Google podkreśla w dokumentacji o Grafice Google, że do zrozumienia obrazu wykorzystuje tekst alternatywny, nazwę pliku i otaczającą treść strony. W praktyce:
- alt opisuje, co jest na zdjęciu i po co tam jest, np. „Czerwona sukienka midi z bawełny, widok z przodu”, a nie „sukienka sukienka tania sukienka”,
- zdjęcia czysto dekoracyjne dostają pusty atrybut
alt="", żeby czytnik ekranu je pominął, - nazwa pliku po polsku i bez polskich znaków, np.
sukienka-midi-czerwona.avifzamiastIMG_4821.jpg, - kontekst: zdjęcie produktu najlepiej działa w pobliżu nagłówka i opisu, które mówią o tym samym.
Jeśli chcesz sprawdzić dostępność całej witryny, nie tylko obrazów, przeczytaj, jak zamówić audyt WCAG i wykorzystać raport.
7. Lista kontrolna: optymalizacja zdjęć krok po kroku
Tę listę możesz przejść samodzielnie, nawet bez znajomości kodu:
- Zmierz punkt wyjścia. Uruchom PageSpeed Insights dla strony głównej i najważniejszej podstrony ofertowej. Zanotuj LCP i sprawdź, który element jest wskazany jako największy.
- Znajdź najcięższe pliki. W narzędziach deweloperskich przeglądarki (zakładka Sieć, filtr obrazów) posortuj zasoby według rozmiaru.
- Popraw wymiary. Zmniejsz pliki do rzeczywistych rozmiarów wyświetlania, z wersją dla ekranów o wysokiej gęstości pikseli.
- Zmień format. Przygotuj AVIF i WebP z JPEG jako zapasem.
- Dodaj
srcsetisizesdla zdjęć, które zmieniają szerokość wraz z ekranem. - Ustaw priorytety. Główne zdjęcie: bez lazy loadingu, z
fetchpriority="high". Reszta:loading="lazy". - Uzupełnij
width,heightialt. - Zmierz ponownie i porównaj wyniki. Dane z prawdziwych wizyt w Search Console aktualizują się z opóźnieniem, więc daj im kilka tygodni.
Obrazy to tylko jedna część technicznego SEO. Pełniejszy obraz da ci audyt SEO strony, który opisuję tutaj.
Moje podejście: obrazy planuję już w projekcie
Najwięcej problemów z obrazami widzę na stronach, gdzie projekt graficzny, wdrożenie i SEO robiły trzy różne osoby. Projektant przygotował piękny baner, programista wstawił go jako tło w CSS, a specjalista od SEO po pół roku zgłasza słaby LCP. Nikt nie popełnił błędu w swojej części, a efekt i tak jest zły.
Ponieważ projektuję w Figmie, koduję i dbam o SEO sam, decyzje o obrazach zapadają u mnie na etapie makiety. Już wtedy wiem, który element będzie LCP na telefonie, jakie rozmiary są potrzebne i gdzie wystarczy SVG. W kodzie główne zdjęcie od początku trafia do HTML z właściwym priorytetem, a CMS sam generuje formaty i rozmiary po wgraniu pliku. Klient dodaje zdjęcie tak, jak zawsze, a strona pozostaje szybka po roku, a nie tylko w dniu wdrożenia.
Uważam, że optymalizacja obrazów nie powinna być osobnym zleceniem „na poprawki”. Powinna być wbudowana w sposób, w jaki strona powstaje.
— Marcin
Potrzebujesz szybkiej strony bez ręcznego pilnowania zdjęć?
Jeśli Twoja obecna strona ładuje się wolno, a przyczyną są obrazy, mogę zająć się tym na dwa sposoby. Przy istniejącej witrynie zaczynam od audytu technicznego i optymalizacji Core Web Vitals w ramach usługi SEO i pozycjonowanie. Jeśli planujesz nową witrynę lub sklep, zobacz, jak buduję strony internetowe bez szablonów, z automatyczną obsługą obrazów od pierwszego dnia. Przykłady wdrożeń znajdziesz w realizacjach.
FAQ
Czy AVIF działa we wszystkich przeglądarkach?
Aktualne wersje popularnych przeglądarek obsługują AVIF, ale starsze urządzenia i niektóre środowiska mogą go nie rozpoznać. Dlatego zawsze stosuję element <picture> z WebP i JPEG jako zapasem. Przeglądarka wybiera pierwszy format, który zna, więc użytkownik zawsze zobaczy zdjęcie.
Czy lazy loading zawsze przyspiesza stronę?
Nie. Leniwe ładowanie przyspiesza stronę dla obrazów poniżej pierwszego widoku, bo przeglądarka nie pobiera ich od razu. Dla głównego zdjęcia na górze strony działa odwrotnie i opóźnia LCP. To zdjęcie ładuj normalnie, z fetchpriority="high".
Czy wtyczka do kompresji wystarczy na WordPressie?
Wtyczka dobrze załatwia kompresję i konwersję do WebP lub AVIF, co jest dużym krokiem naprzód. Nie poprawi jednak motywu, który wstawia baner jako tło w CSS, nie ustawi priorytetu ładowania i nie napisze sensownych tekstów alternatywnych. Warto potraktować ją jako jeden element, a resztę sprawdzić ręcznie.
Jak duże powinno być zdjęcie na stronę internetową?
Nie ma jednej liczby, bo zależy to od miejsca wyświetlania. Dobra zasada to plik nie szerszy niż dwukrotność rzeczywistej szerokości na ekranie, w kilku wersjach podanych w srcset. Ostateczną wagę sprawdzaj, porównując jakość z oryginałem, a nie według sztywnego limitu kilobajtów.
Źródła
- Image performance, web.dev
- What is AVIF?, Alliance for Open Media
- Advanced Image Formats and When to Use Them, Cloudinary
- Choose the right image format, web.dev
- Serve responsive images, web.dev
- Obrazy elastyczne, web.dev
- Common misconceptions about how to optimize LCP, web.dev
- Optimize resource loading with the Fetch Priority API, web.dev
- Standardy przygotowywania treści zgodnie z WCAG, ORE
- Wymagania dostępności cyfrowej, UOKiK
- Sprawdzone metody dotyczące Grafiki Google, Google Search Central
Rekomendacje
Potrzebujesz strony, która działa tak, jak opisuję?
Bezpłatna rozmowa, konkretna wycena w 24 h.
Czytaj dalej
Kolejne wpisy
Audyt UX strony: jak wykryć błędy, które kosztują Cię konwersje
Audyt UX Twojej strony wykrywa bariery konwersji, ocenia szybkość i dostępność oraz porządkuje zalecenia według pilności, by ułatwić wdrożenie zmian.
Design system w Figmie: od tokenów po handoff do kodu
Poznaj sposób na system projektowy w Figmie: uporządkuj tokeny, komponenty i biblioteki, a potem przekaż deweloperom gotowe specyfikacje.
Makiety w Figma: praktyczny przewodnik krok po kroku
Poznaj tworzenie makiet w Figmie krok po kroku: od szkicu i responsywnych ekranów po interaktywny prototyp oraz przekazanie projektu deweloperom.