Języki

Responsywne obrazy (srcset)

Jak serwować responsywne obrazy za pomocą atrybutów srcset i sizes oraz elementu picture, kiedy używać każdego z nich i jak responsywne obrazy naprawiają LCP i CLS, nie będąc bezpośrednim sygnałem rankingowym.

Opublikowano po raz pierwszy: 2 lip 2026 · Ostatnia aktualizacja: 3 sie 2026 · Zaawansowane
AIAutor:AI v2

Responsywne obrazy pozwalają przeglądarce (przez srcset + sizes) lub autorowi (przez <picture>) serwować obraz o odpowiednim rozmiarze dla danego urządzenia. srcset/sizes to przełączanie rozdzielczości (ten sam obraz, wybiera przeglądarka — sugestia); <picture> to kierowanie artystyczne lub zmiana formatu (kadry/formaty narzucone przez autora — polecenie). Większość witryn potrzebuje tylko srcset/sizes. To nie jest bezpośredni sygnał rankingowy i nie zmienia tego, co indeksuje Google — Google indeksuje URL src — ale to konkretna poprawka zalecana przez Lighthouse dla zbyt dużych obrazów (jego audyt „Properly size images” kończy się niepowodzeniem przy różnicy 4KiB) i w połączeniu z jawnymi atrybutami width/height zapobiega CLS. Zachowaj identyczny tekst alternatywny i stabilne URL-e obrazów w różnych punktach przerwania dla indeksowania mobile-first. Używam dokładnie tego samego wzorca srcset + width/height co w moim artykule o CLS na Ahrefs. Artykuł jest zagnieżdżony w hubie Image SEO.

TL;DR — Dwa zadania, jedna rodzina składni. srcset/sizes na <img> = przełączanie rozdzielczości (ten sam obraz, przeglądarka wybiera najlepsze dopasowanie — sugestia); <picture> = art direction lub przełączanie formatu (przycięcia/formaty narzucone przez autora — polecenie). Większość witryn potrzebuje tylko pierwszego. Obrazy responsywne nie są bezpośrednim sygnałem rankingowym i nie zmieniają tego, co Google indeksuje — Google indeksuje URL src, więc zachowaj tekst alt, nazwy plików i URL obrazów stabilne między punktami przerwania (indeksowanie mobile-first). Prawdziwa korzyść to Core Web Vitals: właściwe rozmiary obrazów to poprawka stojąca za audytem Lighthouse „Properly size images” (nieudany przy luce 4KiB), a width/height (lub aspect-ratio) — nie srcset — to zapobiega CLS. Nie ładuj leniwie obrazu LCP. Używam dokładnie tego samego wzorca srcset + width/height z mojego artykułu o CLS w Ahrefs.

Dowód potwierdzający to twierdzenie The HTML responsive-image features srcset, sizes, and picture let browsers select an appropriate image candidate. Zakres: Current HTML responsive image behavior. Poziom ufności: wysoki · Zweryfikowano: WHATWG HTML: Responsive images Dowód potwierdzający to twierdzenie Google can process responsive images and recommends src as a fallback while using srcset or picture for responsive delivery. Zakres: Current Google Images responsive-image guidance. Poziom ufności: wysoki · Zweryfikowano: Google Search Central: Responsive images

Dwa różne zadania, jedna rodzina składni

Wszystko w tym temacie sprowadza się do dwóch mechanizmów, a połowa zamieszania wynika z ich mieszania:

  1. Zmiana rozdzielczości — ten sam obraz w różnych rozmiarach lub gęstościach pikseli. Dajesz przeglądarce menu z srcset i sizes na <img>, a przeglądarka decyduje, który plik pobrać na podstawie viewportu i gęstości ekranu. To typowy przypadek.
  2. Art direction — zupełnie inny obraz dla każdego warunku: szerokie przycięcie na desktopie, wąskie pionowe przycięcie na mobile, lub całkowicie inny format pliku. Tutaj ty decydujesz o wyborze za pomocą elementu <picture>.

Kurs web.dev Learn: Responsive images ujmuje tę różnicę dokładnie tak: z srcset przeglądarka otrzymuje sugestie, natomiast “element picture wydaje polecenia.” A zdanie wyznaczające zakres, które warto powiesić na ścianie, również z web.dev: “You probably won’t need to use the picture element for most of your responsive images — the srcset and sizes attributes on the img element cover a lot of use cases.” (tłumaczenie) „Prawdopodobnie nie będziesz musiał używać elementu picture dla większości responsywnych obrazów — atrybuty srcset i sizes na elemencie img pokrywają wiele przypadków użycia.” Sięgaj po <picture> tylko wtedy, gdy faktycznie potrzebujesz innego obrazu, a nie innego rozmiaru tego samego.

srcset i sizes — zmiana rozdzielczości

Deskryptory w vs. deskryptory x

srcset przyjmuje listę kandydatów oddzielonych przecinkami, każdy oznaczony deskryptorem. Są dwa rodzaje:

  • Deskryptory szerokości (w) — podajesz wewnętrzną szerokość pikselową każdego pliku (puppy-2000.jpg 2000w). Przeglądarka łączy to z wartością sizes, aby ustalić, który plik najlepiej pasuje do przestrzeni oraz gęstości pikseli urządzenia. To elastyczna opcja, której będziesz używać najczęściej.
  • Deskryptory gęstości pikseli (x) — podajesz, który plik jest dla jakiego współczynnika pikseli urządzenia (logo.png 1x, logo@2x.png 2x). Użyj ich dla obrazów o stałym rozmiarze (awatar, logo), gdzie wyświetlany rozmiar się nie zmienia; nie potrzebujesz sizes z deskryptorami x.

Zasada kciuka: płynne obrazy o szerokości treści → deskryptory w + sizes; obrazy UI o stałym rozmiarze → deskryptory x.

Dlaczego sizes ma znaczenie (i co się stanie, jeśli je pominiesz)

Z deskryptorami w, sizes nie jest opcjonalną ozdobą — to sposób, w jaki przeglądarka wie, jak duży obraz zostanie wyrenderowany, aby mogła wybrać przed układem. Według web.dev, sizes “tells the browser what size you expect the image to be displayed at under different conditions,” (tłumaczenie) „informuje przeglądarkę, w jakim rozmiarze obraz ma być wyświetlany w różnych warunkach”, jako lista warunków medialnych i szerokości oddzielona przecinkami:

sizes="(max-width: 600px) 480px, 1000px"

Czytaj to jako: “jeśli viewport ma 600px lub mniej, obraz będzie miał około 480px szerokości; w przeciwnym razie około 1000px.” Pomiń sizes, a przeglądarka założy, że obraz wypełnia pełną szerokość viewportu (100vw) — więc na szerokim ekranie może pobrać największy plik dla obrazu, który faktycznie renderuje się na 400px, cicho niwecząc cały sens. Brak sizes to najczęstszy błąd srcset.

Nie zgaduj tych wartości szerokości z układu w głowie — sprawdź rzeczywistą wyrenderowaną szerokość CSS obrazu w przeglądarce (DevTools → Elements → obliczona szerokość ramki <img>) na każdym breakpoincie, który Cię interesuje, i ustaw sizes tak, aby pasowały. Wartość sizes, która nie pasuje do rzeczywistej wyrenderowanej szerokości, nadal powoduje, że przeglądarka wybiera niewłaściwego kandydata, nawet jeśli znaczniki są składniowo poprawne — sama walidacja składni tego nie wykryje; zobacz sprawdzenie currentSrc poniżej, aby potwierdzić, co faktycznie zostało załadowane.

Przykład z praktyki (mój powtarzalny wzorzec)

To dokładny wzorzec z mojego artykułu na Ahrefs, What Is Cumulative Layout Shift (CLS) & How To Improve It, rozszerzony o sizes:

<img
  src="puppy-1000.jpg"
  srcset="puppy-1000.jpg 1000w,
          puppy-2000.jpg 2000w,
          puppy-3000.jpg 3000w"
  sizes="(max-width: 600px) 480px, 1000px"
  width="1000" height="1000"
  alt="Puppy with balloons" />

Każdy element jest istotny: src to wersja zapasowa i adres URL indeksowany przez Google; srcset zawiera listę kandydatów z deskryptorami w; sizes informuje przeglądarkę o wyrenderowanej szerokości; width/height rezerwują miejsce (poprawka CLS — więcej poniżej); alt pozostaje identyczny niezależnie od tego, który plik się wczytuje.

Element picture — kierowanie artystyczne i przełączanie formatów

Kiedy naprawdę go potrzebujesz

Użyj <picture> do dwóch rzeczy, których srcset nie potrafi:

  1. Kierowanie artystyczne — inny kadr dla każdego punktu granicznego. Przykład z web.dev: na wąskim telefonie możesz serwować wysoki, ciasny kadr; na szerokim monitorze — krótki, szeroki. Ten sam temat, celowo inne kadrowanie.
  2. Przełączanie formatów — zaoferuj AVIF/WebP z zapasowym JPEG przez <source type="…">, pozwalając przeglądarce wybrać pierwszy obsługiwany format. To bezpośrednio wiąże się z wytycznymi dotyczącymi formatów w centrum SEO obrazów.

Składnia (i zasada wersji zapasowej)

Element <picture> zawiera jeden lub więcej elementów <source> i zawsze kończy się zwykłym <img>:

<!-- Art direction: different crop per breakpoint -->
<picture>
  <source media="(max-width: 600px)" srcset="hero-crop-mobile.jpg">
  <img src="hero-crop-desktop.jpg" width="1200" height="675"
       alt="Product hero shot">
</picture>

<!-- Format switching: modern format with a fallback -->
<picture>
  <source type="image/avif" srcset="hero.avif">
  <source type="image/webp" srcset="hero.webp">
  <img src="hero.jpg" width="1200" height="675" alt="Product hero shot">
</picture>

Ten końcowy <img src> nie jest opcjonalny. Google stwierdza to wprost: zgodnie z sekcją 4.8.1 standardu HTML, “make sure that you provide an img element as a fallback with a src attribute when using the picture element.” (tłumaczenie) „upewnij się, że podajesz element img jako wersję zapasową z atrybutem src, gdy używasz elementu picture.” To plik, do którego odwołują się starsze przeglądarki i roboty indeksujące — i, ponownie, ten, który Google indeksuje.

Czy srcset pomaga SEO? Bezpośrednio vs. pośrednio

Oto ujęcie, które gubi każdy konkurencyjny przewodnik, więc będę bezpośredni.

Bezpośrednio: nie. Znaczniki obrazów responsywnych nie są sygnałem rankingowym tak, jak tekst alternatywny czy nazwy plików w wyszukiwarce obrazów. Dodanie srcset nie podnosi Twoich pozycji i nie zmienia tego, co pojawia się w Grafice Google. Google indeksuje obraz wskazany w src; warianty srcset/<picture> są mechanizmem dostarczania, a nie osobno indeksowanymi zasobami. Trzymaj tekst alt, nazwę pliku i dane strukturalne przypisane do tego głównego obrazu src.

Pośrednio: tak, i to jedna z największych dźwigni, jakie masz. Obrazy o odpowiednim rozmiarze są najskuteczniejszą konkretną poprawką dla dwóch podstawowych wskaźników internetowych — LCP i CLS — które zasilają sygnały doświadczenia strony w Google. To cała korzyść. To ten sam schemat, co historia WebP/AVIF w centrum SEO obrazów: brak wzmocnienia dla samego formatu, wygraną jest szybkość.

Obrazy responsywne a LCP

Obrazy o zbyt dużych rozmiarach to jedna z najczęstszych przyczyn wolnego Largest Contentful Paint, a obrazy responsywne to zalecana poprawka w Lighthouse. Audyt Lighthouse „Obrazy o odpowiednich rozmiarach” wymienia “all images in your page that aren’t appropriately sized, along with the potential savings” (tłumaczenie) „wszystkie obrazy na Twojej stronie, które nie są odpowiednio zwymiarowane, wraz z potencjalnymi oszczędnościami” — wszystko, co jest większe niż potrzeba, “just results in wasted bytes and slows down page load time.” (tłumaczenie) „po prostu skutkuje zmarnowanymi bajtami i spowalnia czas ładowania strony”. Jego poprawka, dosłownie: “With responsive images, you generate multiple versions of each image, and then specify which version to use in your HTML or CSS using media queries, viewport dimensions, and so on.” (tłumaczenie) „Dzięki obrazom responsywnym generujesz wiele wersji każdego obrazu, a następnie określasz, której wersji użyć w HTML lub CSS, korzystając z zapytań o media, wymiarów okna przeglądarki i tak dalej”.

Dwie konkretne rzeczy, które warto znać:

  • Próg błędu to 4 KiB. Lighthouse flaguje obraz tylko wtedy, gdy “the rendered size is at least 4KiB smaller than the actual size.” (tłumaczenie) „wyrenderowany rozmiar jest co najmniej 4 KiB mniejszy niż rzeczywisty rozmiar”. Małe przekroczenia się nie liczą; serwowanie pliku 3000px do slotu 400px — tak.
  • Skrót narzędziowy. Google zaleca RespImageLint, “a helpful bookmarklet for identifying the optimal srcset and sizes values for your images.” (tłumaczenie) „przydatny bookmarklet do identyfikowania optymalnych wartości srcset i sizes dla Twoich obrazów”. Uruchom go, zanim ręcznie obliczysz punkty graniczne.

Nie ładuj leniwie obrazu LCP

To jest zasada, którą ludzie łamią najczęściej. srcset na hero jest w porządku — ale nigdy nie łącz go z leniwym ładowaniem na elemencie LCP. Największy obraz powyżej linii zagięcia powinien ładować się z fetchpriority="high", dokładnie jak opisano w hubie Image SEO. A gdy budujesz responsywny <picture> hero, zachowaj natywną logikę zamiany: Google ostrzega, że “nie wczyta treści wymagających interakcji użytkownika”, takich jak przesuwanie czy klikanie, więc schemat JS, który ładuje prawdziwy obraz dopiero po interakcji, ukrywa go przed Google.

Responsywne obrazy i CLS

Oto pułapka: sam srcset nie robi nic dla przesunięcia układu. Przełączanie rozdzielczości decyduje, który plik się ładuje; nie rezerwuje dla niego miejsca. Bez podanych wymiarów, zgodnie z przewodnikiem web.dev Optimize CLS, “gdy obrazy się ładują, tekst przesuwa się w dół strony, aby zrobić im miejsce” — ponieważ miejsce “nie może być dla niego przydzielone, dopóki przeglądarka nie zacznie go pobierać i nie będzie mogła określić jego wymiarów.”

Rozwiązaniem są jawne wymiary, które współgrają z responsywnym znacznikiem:

  • Ustaw atrybuty width i height na <img>. Nowoczesne przeglądarki “ustawiają domyślny współczynnik proporcji obrazów na podstawie atrybutów width i height obrazu”, więc te dwie liczby rezerwują odpowiednie pole przed pobraniem jakiegokolwiek wariantu srcset. (web.dev)
  • Połącz je z height: auto w CSS dla płynnych kontenerów. To część, która wygląda na sprzeczną, ale nie jest: zalecenie samego web.dev to “użyj CSS, aby zmienić rozmiar obrazu do szerokości kontenera” i “ustaw height: auto;, aby uniknąć używania stałej wartości dla wysokości obrazu.” Atrybuty HTML ustawiają wewnętrzny współczynnik proporcji; CSS pozwala obrazowi płynnie skalować się. Razem zapobiegają CLS i pozostają responsywne.
  • Lub użyj CSS aspect-ratio, aby zarezerwować miejsce, gdy nie możesz ustawić atrybutów.

To obala trwały mit: atrybuty width/height nie psują płynnych układów. Atrybuty + height: auto to właściwa kombinacja, a nie konflikt. Omawiam pełną mechanikę przesunięcia układu w moim artykule Ahrefs CLS; w skrócie: “zarezerwuj miejsce, aby nie było przesunięcia” i pozwól obrazowi je wypełnić.

Implikacje indeksowania mobile-first

Google indeksuje głównie mobilną wersję Twoich stron, więc dwie zasady mają teraz większe znaczenie niż kiedyś, gdy serwujesz responsywne warianty:

Podsumowanie Google dotyczące dlaczego warto to robić jest proste: “projektowanie responsywnych stron internetowych prowadzi do lepszego doświadczenia użytkownika, ponieważ ludzie mogą uzyskać do nich dostęp na wielu różnych urządzeniach.”

A co z Bing?

Nie ma wytycznych specyficznych dla Binga dotyczących srcset, sizes ani elementu <picture> — publiczna dokumentacja Binga w ogóle nie porusza kwestii znaczników obrazów responsywnych. Więc nie uzasadniaj obrazów responsywnych hakiem algorytmu Binga; argumentem są wydajność i UX, które Bing (podobnie jak Google) traktuje jako jakość doświadczenia strony, a nie coś, na co można wskazać jako udokumentowaną regułę dotyczącą obrazów responsywnych.

Częste błędy

  • Zapominanie o sizes z deskryptorami w — przeglądarka zakłada 100vw i może pobrać największy plik dla małego miejsca.
  • Pomijanie zapasowego src w <picture> — naruszenie specyfikacji, które Google wyraźnie flaguje, i to jest URL indeksowany przez crawlerów.
  • Niedopasowany stosunek width/height do faktycznie serwowanego obrazu — nadal powoduje przesunięcie.
  • Leniwe ładowanie obrazu LCP — opóźnia LCP bez powodu; ładuj go eagerly z fetchpriority="high".
  • Regenerowanie URL-i obrazów przy każdym żądaniu — łamie cache Google i mobilną zasadę „stabilnego URL”.
  • Sięganie po <picture>, gdy wystarczy srcset/sizes — niepotrzebna złożoność; web.dev mówi, że większość stron tego nie potrzebuje.

Gdzie to się znajduje

To jest szczegółowy przewodnik dotyczący rozmiaru i dostarczania w ramach szerszego hubu Image SEO — wydajnościowa połowa SEO obrazów, równolegle do tego, jak przewodnik po tekście alternatywnym zajmuje się połową związaną z wyszukiwaniem obrazów. Pełne mechanizmy przesunięcia układu znajdziesz w moim artykule Ahrefs CLS; jeśli chodzi o LCP, fetchpriority i strategię ładowania, to praca nad Core Web Vitals w przebraniu obrazów.

Dodaj notatkę eksperta

Przypnij cytat eksperta

Nowa osoba? Najpierw utwórz jej nieprzejęty profil na /admin/experts/ → Przypnij cytat eksperta .