Obrazy responsywne: atrybuty srcset i sizes oraz dobór rozmiaru do ekranu

Czym są obrazy responsywne i jaki problem rozwiązują

Obraz responsywny to jeden obraz zapisany w kilku plikach o różnej szerokości, spośród których przeglądarka pobiera tylko jeden, odpowiedni dla danego urządzenia. Dzięki temu telefon nie ściąga zdjęcia przygotowanego dla dużego monitora, a ekran o wysokiej gęstości pikseli nie dostaje rozmytej miniatury. Sam znacznik img pozostaje jeden, zmienia się tylko to, który plik faktycznie trafi do użytkownika.

Stawka jest wymierna. Według opracowania Serve responsive images w serwisie web.dev wysyłanie na urządzenia mobilne obrazów przygotowanych dla komputerów może oznaczać zużycie od 2 do 4 razy większej ilości danych, niż jest potrzebne. To samo źródło podaje, że zwykle przygotowuje się od 3 do 5 wersji rozmiaru jednego obrazu.

Nie da się tego załatwić samymi stylami ani skryptem. Zmniejszenie obrazu w stylach niczego nie oszczędza, bo plik i tak zostaje pobrany w całości, a dopiero potem przeskalowany na ekranie. Informacja o wersjach pliku musi więc znajdować się bezpośrednio w kodzie HTML.

Formaty plików, teksty alternatywne i nazwy plików opisujemy osobno we wpisie o obrazach na stronie a SEO. Tutaj zajmujemy się wyłącznie doborem rozmiaru pliku do ekranu.

Jak działa atrybut srcset

Atrybut srcset to lista plików oddzielonych przecinkami, w której każdy adres ma dopisaną informację o tym, czym dany plik jest. Tę informację nazywa się deskryptorem. Są dwa rodzaje deskryptorów i w jednym atrybucie stosuje się tylko jeden z nich: albo szerokości, albo gęstości, nigdy oba naraz.

Deskryptor szerokości (w)

Zapis w rodzaju 800w oznacza, że plik ma 800 pikseli szerokości. To opis samego pliku, a nie polecenie: autor strony informuje, czym dysponuje, a nie wskazuje, na jakim urządzeniu dany plik ma zostać użyty. Sam deskryptor szerokości nie wystarcza do podjęcia decyzji, ponieważ przeglądarka musi jeszcze wiedzieć, jak szeroko obraz zostanie pokazany. Tę brakującą informację przekazuje atrybut sizes.

Deskryptor gęstości (x)

Zapis 2x oznacza, że plik jest przeznaczony dla ekranów o gęstości pikseli równej 2. Ten wariant nie wymaga atrybutu sizes i sprawdza się tam, gdzie obraz ma stałą szerokość niezależnie od ekranu, czyli przy logo, ikonach i awatarach. Przy zdjęciach, które rozciągają się razem z układem strony, lepszym wyborem są deskryptory szerokości.

<!-- logo o stałej szerokości 160 pikseli -->
<img src="logo-160.png"
     srcset="logo-160.png 1x, logo-320.png 2x"
     width="160" height="48" alt="Logo firmy">

<!-- zdjęcie skalowane z układem -->
<img src="realizacja-800.jpg"
     srcset="realizacja-400.jpg 400w,
             realizacja-800.jpg 800w,
             realizacja-1200.jpg 1200w,
             realizacja-1600.jpg 1600w"
     sizes="(min-width: 900px) 50vw, 100vw"
     width="1600" height="1067"
     alt="Łazienka po remoncie z kabiną bez brodzika">

W obu wariantach pozostaje zwykły atrybut src. Atrybut srcset go uzupełnia, a nie zastępuje. Dokumentacja Google dotycząca obrazów w wyszukiwarce zwraca uwagę, że nie wszystkie przeglądarki i roboty obsługują te atrybuty, i zaleca podawanie zastępczego adresu w src. Z tej samej strony wynika, że Google odnajduje obrazy w atrybucie src znacznika img, także wewnątrz elementu picture, natomiast obrazów wstawionych jako tło w stylach CSS nie indeksuje. Tam, gdzie prowadzone jest pozycjonowanie grafiki, plik wskazany w src powinien więc być rozsądnej jakości, a nie najmniejszą miniaturą.

Jak działa atrybut sizes i jak przeglądarka dobiera plik

Atrybut sizes informuje przeglądarkę, jaką szerokość obraz zajmie w układzie strony przy danej szerokości okna. Nie zmienia wyglądu strony i niczego nie skaluje, od tego nadal są style. Jest wyłącznie zapowiedzią: zanim przeglądarka pozna układ, dowiaduje się z sizes, ile miejsca przewidziano na obraz, i na tej podstawie sięga po plik z listy srcset.

Wartość sizes to lista par złożonych z warunku i szerokości. Warunek zapisuje się tak jak w stylach, na przykład (min-width: 900px), a szerokość podaje się w pikselach, w jednostkach vw, czyli setnych częściach szerokości okna, albo jako działanie calc(). Nie wolno używać procentów. Przeglądarka czyta listę od lewej i zatrzymuje się na pierwszym spełnionym warunku, dlatego kolejność ma znaczenie. Ostatnia pozycja nie ma warunku i działa jako wartość domyślna.

Rachunek, który wykonuje przeglądarka

Zgodnie z opisem w kursie Descriptive syntaxes w serwisie web.dev przeglądarka dzieli szerokość każdego pliku z listy przez szerokość miejsca na obraz. Wynik mówi, jaką gęstość pikseli dany plik zapewni w tym konkretnym układzie. Następnie porównuje te wyniki z gęstością ekranu i pobiera plik najbliższy potrzebom, unikając takich, które trzeba byłoby powiększać.

Prześledźmy to na zdjęciu z poprzedniego przykładu, które ma wersje 400, 800, 1200 i 1600 pikseli oraz sizes o wartości (min-width: 900px) 50vw, 100vw. Liczby są naszym przykładem, sam sposób liczenia pochodzi ze źródła.

Z tabeli płynie wniosek, który wielu właścicieli stron zaskakuje: telefon z ekranem o wysokiej gęstości potrzebuje większego pliku niż laptop ze zwykłym ekranem, mimo że jest fizycznie kilka razy mniejszy. Obraz dobrany do ekranu to więc nie obraz o szerokości okna, tylko obraz o szerokości miejsca w układzie pomnożonej przez gęstość pikseli.

Ostatnie słowo należy do przeglądarki

Opisany rachunek jest punktem wyjścia, a nie sztywną regułą. Kurs web.dev zaznacza, że po odczytaniu listy plików i opisu układu przeglądarka może postąpić według własnego uznania i nie da się z całą pewnością przewidzieć, po który plik sięgnie. Może pobrać wersję o niższej gęstości przy słabym łączu lub włączonym oszczędzaniu danych. Zwykle nie pobiera też mniejszego pliku, jeżeli większy znajduje się już w pamięci podręcznej, bo może go po prostu pomniejszyć. To ważne przy testach: zwężenie okna na komputerze nie zawsze pokaże pobranie mniejszej wersji i nie świadczy to o błędzie.

Skąd biorą się zbyt duże obrazy na telefonach

Zbyt duże obrazy na telefonach biorą się najczęściej z rozjazdu między tym, co deklaruje sizes, a rzeczywistym układem strony. Jeżeli przeglądarka słyszy, że obraz zajmie pełną szerokość okna, a w rzeczywistości zajmuje połowę, pobierze plik dwukrotnie szerszy, niż trzeba. Atrybuty są na miejscu, lista plików jest poprawna, a mimo to telefon ściąga za dużo.

Dobrze widać to na hipotetycznym sklepie z Poznania, który na telefonie pokazuje produkty w dwóch kolumnach. Każde zdjęcie zajmuje w układzie około 170 pikseli, ale szablon wstawia ogólne sizes zapowiadające obraz na całą szerokość okna, czyli 360 pikseli. Na ekranie o gęstości 3 przeglądarka szuka więc pliku o szerokości około 1080 pikseli, choć wystarczyłby plik o szerokości około 510 pikseli. Na liście z czterdziestoma produktami różnica dotyczy każdego zdjęcia z osobna.

Drugi typowy powód to brak mniejszych wersji. Jeżeli lista srcset zaczyna się od pliku o szerokości 1200 pikseli, przeglądarka nie ma czego dobrać dla małej miniatury i bierze najmniejszy z dostępnych, wciąż za duży. Trzeci to brak srcset w ogóle: obraz wstawiony ręcznie w kodzie szablonu, w suwaku albo w module strony głównej ma wtedy tylko jeden plik w src, ten sam dla wszystkich urządzeń. Czwarty to obrazy tła ustawiane w stylach, których atrybuty srcset i sizes nie dotyczą. Dla nich istnieje funkcja image-set(), która pozwala podać wersje dla różnych gęstości ekranu.

Jest też przyczyna leżąca poza obrazami. Jeżeli w nagłówku strony brakuje znacznika meta viewport z wartością width=device-width, część przeglądarek mobilnych wczytuje stronę tak, jakby okno było znacznie szersze, a potem ją pomniejsza, co zawyża wszystkie obliczenia oparte na szerokości okna.

Co oznacza zalecenie właściwego rozmiaru obrazów w Lighthouse

Zalecenie to oznacza, że strona pobrała obraz o wymiarach większych niż te, w których został on wyświetlony, i że mniejszy plik dałby ten sam efekt wizualny. Lighthouse porównuje dwie wielkości: rozmiar obrazu po wyrenderowaniu na stronie oraz rzeczywisty rozmiar pobranego pliku.

Według dokumentacji audytu Properly size images rozmiar po wyrenderowaniu uwzględnia gęstość pikseli urządzenia, a obraz nie przechodzi kontroli, gdy ten rozmiar jest co najmniej o 4 KiB mniejszy od rozmiaru rzeczywistego. Raport wymienia konkretne adresy plików i szacowaną oszczędność w kibibajtach. Dokumentacja zaznacza, że od wersji 13 audyt został włączony do szerszej analizy o angielskiej nazwie Improve image delivery, czyli usprawnienia dostarczania obrazów. Obejmuje ona także kompresję, nowoczesne formaty i zastępowanie animowanych plików GIF filmem, a pomija obrazy, przy których szacowana oszczędność nie sięga 4 KiB. W polskiej wersji narzędzi nazwy tych pozycji są przetłumaczone, dlatego najpewniej rozpoznać je po liście adresów obrazów i kolumnie z oszczędnością.

Wynik warto czytać ze zrozumieniem ograniczeń testu. Pojedynczy przebieg dotyczy jednej podstrony, jednej szerokości okna i jednej gęstości pikseli, więc obraz zgłoszony w teście mobilnym może być dobrany poprawnie dla komputera i odwrotnie. Jak uruchomić test, opisujemy we wpisie o audycie Lighthouse w Chrome, a raport dostępny w sieci we wpisie o PageSpeed Insights.

Uczciwie trzeba też powiedzieć, czego po poprawce nie należy oczekiwać. Opracowanie Optimize Largest Contentful Paint zwraca uwagę, że na większości stron sam czas pobierania pliku nie jest głównym hamulcem wskaźnika LCP, czyli czasu wyświetlenia największego elementu. Zmniejszenie obrazu oszczędza dane użytkownika, ale wynik LCP poprawi wyraźnie tylko wtedy, gdy rzeczywiście to pobieranie go opóźniało. Pozostałe przyczyny omawiamy we wpisie o poprawianiu LCP.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl

Jakie rozmiary obrazów generuje WordPress

WordPress po wgraniu zdjęcia do biblioteki mediów sam tworzy kilka pomniejszonych wersji pliku, a przy wstawianiu obrazu na stronę sam dopisuje atrybuty srcset i sizes. Właściciel strony nie musi więc pisać ich ręcznie. Musi natomiast wiedzieć, jakie wersje powstają i co system wpisuje w sizes, bo to tam najczęściej kryje się problem.

Wersje plików

Podstawowe rozmiary to miniatura, średni i duży. Ich wymiary ustawia się w panelu, na ekranie Ustawienia, a następnie Media: dla miniatury podaje się szerokość i wysokość oraz decyduje, czy ma być przycinana dokładnie do tych wymiarów, a dla rozmiaru średniego i dużego podaje się maksymalną szerokość i wysokość. Oprócz nich system tworzy rozmiar pośredni o nazwie medium_large, domyślnie o szerokości 768 pikseli. Do tego dochodzą rozmiary rejestrowane przez szablon i wtyczki funkcją add_image_size(), w której podaje się nazwę, szerokość, wysokość i sposób przycinania.

Bardzo duże zdjęcia są traktowane osobno. Jak opisano w komunikacie o obsłudze dużych obrazów, plik, którego szerokość lub wysokość przekracza próg 2560 pikseli, zostaje pomniejszony do tego progu i ta wersja staje się największym dostępnym rozmiarem. Oryginał pozostaje na serwerze, a próg zmienia się lub wyłącza filtrem big_image_size_threshold.

Domyślny srcset i sizes

Z dokumentacji obrazów responsywnych WordPressa wynika, że system buduje listę srcset z wygenerowanych wersji pliku i dopuszcza do niej obrazy o szerokości nieprzekraczającej domyślnie dwóch tysięcy czterdziestu ośmiu pikseli. Granicę tę zmienia filtr max_srcset_image_width. Jeżeli w treści znajduje się już ręcznie wpisany srcset lub sizes, WordPress ich nie nadpisuje.

Domyślna wartość sizes ma jedną postać dla wszystkich obrazów: przy oknie nie szerszym niż szerokość obrazu przyjmuje się pełną szerokość okna, a przy szerszym oknie szerokość samego obrazu.

sizes="(max-width: 1024px) 100vw, 1024px"

Taka wartość jest trafna dla zdjęcia rozciągniętego na całą kolumnę treści. Przestaje być trafna tam, gdzie obraz stoi w siatce: w liście wpisów w trzech kolumnach, w kafelkach produktów, w galerii. System nie zna układu szablonu. Poprawia się to filtrem wp_calculate_image_sizes, a dla obrazów spoza treści wpisu, takich jak obrazki wyróżniające i galerie, filtrem wp_get_attachment_image_attributes. To praca dla osoby, która zna dany szablon, ponieważ wartości trzeba dobrać do rzeczywistych szerokości kolumn na każdym progu układu.

Wartość auto dla obrazów ładowanych leniwie

Nowsze wydania WordPressa dopisują na początku sizes słowo auto, ale tylko obrazom z atrybutem loading o wartości lazy, czyli ładowanym leniwie. Zgodnie z komunikatem o automatycznym sizes przeglądarka może wtedy użyć rzeczywistej szerokości obrazu w układzie, bo taki obraz pobiera się dopiero wtedy, gdy układ jest już znany. Przeglądarki, które nie znają tej wartości, korzystają z dalszej części listy. Rozwiązuje to problem ogólnego sizes dla obrazów niżej na stronie, ale nie dla tych widocznych od razu po otwarciu, które leniwie ładowane być nie powinny. Zasady opisujemy we wpisie o leniwym ładowaniu obrazów i ramek.

Kiedy potrzebny jest element picture

Element picture jest potrzebny wtedy, gdy na różnych urządzeniach ma się pojawić inny obraz, a nie tylko inna wielkość tego samego obrazu, albo gdy strona podaje ten sam obraz w kilku formatach. Do samego dopasowania rozmiaru wystarczają srcset i sizes na zwykłym znaczniku img.

Jak wyjaśnia kurs Prescriptive syntaxes, picture sam niczego nie wyświetla. Jest opakowaniem, które decyduje, jaki plik pokaże znajdujący się w środku znacznik img. Wewnątrz umieszcza się elementy source, każdy z własnym warunkiem i własną listą srcset. Przeglądarka przegląda je po kolei i używa pierwszego, który pasuje, dlatego kolejność jest tu równie istotna jak w sizes. Znacznik img stoi na końcu i pełni rolę wartości domyślnej oraz wersji dla przeglądarek, które elementu picture nie znają.

Różnica wobec srcset jest zasadnicza: srcset i sizes opisują pliki i pozostawiają decyzję przeglądarce, natomiast picture z atrybutem media wydaje polecenie. Pierwsze zastosowanie to inny kadr na innym ekranie. Szerokie zdjęcie zespołu hipotetycznej kancelarii z Krakowa, czytelne na monitorze, na telefonie zamienia twarze w drobne punkty, więc dla wąskich okien przygotowuje się ciaśniejszy kadr. Drugie zastosowanie to formaty: atrybut type informuje, w jakim formacie jest plik, a przeglądarka pomija źródła, których nie potrafi odczytać, bez pobierania ich.

<picture>
  <source media="(min-width: 1200px)" srcset="zespol-szeroki.jpg"
          width="1600" height="600">
  <img src="zespol-ciasny.jpg" width="800" height="800"
       alt="Zespół kancelarii w sali konferencyjnej">
</picture>

<picture>
  <source type="image/webp" srcset="biuro.webp">
  <img src="biuro.jpg" width="1200" height="800" alt="Biuro kancelarii">
</picture>

Przy różnych kadrach zmieniają się proporcje obrazu, a znacznik img przyjmuje tylko jedną parę wymiarów. Dlatego elementy source mogą mieć własne atrybuty width i height, dzięki którym przeglądarka rezerwuje właściwą ilość miejsca dla każdego wariantu i układ nie przeskakuje podczas ładowania. Szerzej o tym zjawisku piszemy we wpisie o przesunięciach układu strony.

Najczęstsze błędy w szablonach

Najczęstsze błędy w szablonach to ogólne sizes niepasujące do układu, zbyt krótka lista plików, obrazy wstawione z pominięciem biblioteki mediów oraz leniwe ładowanie zdjęcia widocznego od razu po otwarciu strony. Żaden z nich nie psuje wyglądu, dlatego potrafią pozostać niezauważone przez lata.

Pierwszy błąd omówiliśmy już przy WordPressie: sizes zapowiada pełną szerokość okna dla obrazu, który zajmuje jej część. Jego odwrotność bywa równie dotkliwa. Gdy sizes deklaruje szerokość mniejszą od rzeczywistej, przeglądarka pobiera za mały plik i zdjęcie jest nieostre. Zdarza się to po przebudowie układu, kiedy kolumna została poszerzona, a wartości w kodzie pozostały stare.

Drugi błąd to wstawianie w edytorze pełnego rozmiaru zdjęcia tam, gdzie wystarczyłby średni. Dokumentacja Lighthouse zaleca przy WordPressie wgrywanie obrazów przez bibliotekę mediów, wstawianie ich w odpowiednim rozmiarze i unikanie pełnego rozmiaru, jeżeli jego wymiary nie odpowiadają miejscu użycia. Hipotetyczny hydraulik z Łodzi, który wgrywa zdjęcia realizacji prosto z telefonu i wstawia je do wpisu w pełnym rozmiarze, obciąża stronę właśnie w ten sposób.

Trzeci błąd to obrazy wpisane na stałe w plikach szablonu, zwykle logo, zdjęcie w nagłówku, banery i suwaki. Omijają one mechanizmy WordPressa i mają jeden plik dla wszystkich urządzeń. Czwarty to mieszanie obu rodzajów deskryptorów w jednej liście, co standard HTML traktuje jako błąd zapisu, albo sizes z procentami zamiast jednostek vw.

Piąty błąd dotyczy najważniejszego obrazu na stronie. Zdjęcie widoczne od razu po otwarciu nie powinno być ładowane leniwie, a źródła web.dev zalecają, by obrazowi, który prawdopodobnie jest elementem LCP, nadać atrybut fetchpriority o wartości high. Ostrzegają jednocześnie, że nadanie wysokiego priorytetu więcej niż jednemu lub dwóm obrazom odbiera temu oznaczeniu sens. Mechanizm priorytetów opisujemy we wpisie o preload, preconnect i fetchpriority.

Szósty błąd to brak atrybutów width i height. Kurs Responsive images zaleca podawanie ich zawsze, gdy wymiary są znane, ponieważ przeglądarka wylicza z nich proporcje i rezerwuje miejsce jeszcze przed pobraniem pliku.

• Każdy obraz treści ma atrybut src oraz listę srcset z kilkoma wersjami szerokości.
• Najmniejsza wersja na liście pasuje do najmniejszego miejsca, w jakim obraz występuje.
• Wartość sizes odpowiada szerokości kolumny na każdym progu układu, także w siatkach.
• W jednej liście srcset występuje tylko jeden rodzaj deskryptora.
• Obraz widoczny od razu po otwarciu strony nie ma leniwego ładowania.
• Każdy obraz ma atrybuty width i height zgodne z proporcjami pliku.

Jak sprawdzić obrazy na własnej stronie i w jakiej kolejności je poprawiać

Sprawdzanie warto zacząć od raportu Lighthouse dla najważniejszych typów podstron, a poprawki od tych szablonów, które powtarzają się na największej liczbie adresów. Jedna zmiana w szablonie listy produktów poprawia setki podstron naraz, podczas gdy ręczna podmiana pojedynczych zdjęć daje efekt tylko na jednej.

1. Test reprezentatywnych podstron

   Wystarczy po jednej podstronie każdego typu: strona główna, kategoria lub lista wpisów, karta produktu lub usługi, wpis na blogu. Test wykonuje się osobno w trybie mobilnym i dla komputera.

2. Odczytanie listy zgłoszonych obrazów

   Przy każdym adresie pliku raport podaje szacowaną oszczędność. Warto ustalić, w którym miejscu szablonu dany obraz się pojawia i czy ma w kodzie srcset oraz sizes.

3. Pomiar rzeczywistej szerokości

   W narzędziach deweloperskich przeglądarki po wskazaniu obrazu widać jego szerokość w układzie. Tę wartość, zmierzoną dla kilku szerokości okna, porównuje się z tym, co deklaruje sizes.

4. Poprawienie sizes i listy plików

   Wartość sizes dopasowuje się do zmierzonych szerokości, a brakujące mniejsze wersje rejestruje jako nowe rozmiary i generuje dla starszych zdjęć.

5. Ponowny test i kontrola jakości

   Po zmianie trzeba sprawdzić nie tylko raport, lecz także ostrość zdjęć na ekranie o wysokiej gęstości pikseli.

Samodzielnie da się zrobić sporo: ustawić rozsądne wymiary na ekranie Ustawienia, a następnie Media, wstawiać zdjęcia w rozmiarze dopasowanym do miejsca i nie wgrywać plików prosto z aparatu. Pomoc specjalisty staje się potrzebna, gdy zgłoszenia dotyczą obrazów generowanych przez szablon lub kreator, gdy trzeba dopisać filtry w kodzie albo gdy sklep ma tysiące zdjęć i wymaga ponownego wygenerowania miniatur bez przeciążenia serwera. Przy większych serwisach poprawki obrazów najlepiej zaplanować razem z innymi pracami nad szybkością, które porządkuje audyt SEO, a przy budowie nowego serwisu uwzględnić je już wtedy, gdy powstaje projekt strony. W bieżącej obsłudze zajmuje się tym SEO techniczne.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl