w Divi 5 — dlaczego zwykły img nie wystarczy i jak serwować AVIF z fallbackiem

Jeśli wgrywasz obrazek do WordPressa i wstawiasz go w Divi 5, najczęściej kończysz z prostym mechanizmem: przeglądarka dostaje jeden element img, jeden format obrazu i tyle. Owszem, może dojść do tego srcset, więc urządzenie wybierze sobie lepszy rozmiar, ale nadal poruszamy się w obrębie jednego formatu. WordPressowy wp_get_attachment_image() zwraca po prostu element <img>, a nie <picture>.

Przez lata to wystarczało. Problem zaczyna się wtedy, gdy chcesz wejść poziom wyżej i serwować AVIF. To ma sens, bo nowoczesne przeglądarki AVIF obsługują, ale wsparcie nie jest stuprocentowe we wszystkich starszych wersjach przeglądarek i systemów. Tabele kompatybilności pokazują, że AVIF jest dziś szeroko wspierany, ale nie wszędzie i nie od zawsze, więc ślepe podanie jednego pliku .avif wszystkim użytkownikom nadal może skończyć się brakiem obrazu na części urządzeń.

I właśnie tu wchodzi <picture>.

Dlaczego

<picture>

w ogóle istnieje

Element <picture> powstał po to, żeby przeglądarka mogła sama wybrać najlepszą wersję obrazu na podstawie tego, co umie obsłużyć i jaki wariant pasuje do bieżącego kontekstu. MDN opisuje to wprost: przeglądarka analizuje kolejne elementy <source> i wybiera pierwszy kompatybilny wariant na podstawie srcset, media i type, a osadzony na końcu <img> pełni rolę fallbacku, gdy żaden z wcześniejszych wariantów nie będzie użyteczny.

Najprostszy przykład wygląda tak:

W takim układzie przeglądarka bierze pierwszy format, który rozumie. Jeśli obsługuje AVIF, użyje AVIF. Jeśli nie, ale obsługuje WebP, weźmie WebP. Jeśli nie rozumie żadnego z nich, zostaje zwykły JPG z elementu img. To właśnie największa przewaga <picture> nad samym img: nie tylko różne rozmiary, ale też różne formaty z bezpiecznym fallbackiem.

Dlaczego Divi 5 nie robi tego za Ciebie

I tu dochodzimy do sedna.

Divi ma moduł obrazu, potrafi korzystać z responsywnych obrazów i od dawna wspiera srcset, ale to nadal nie jest automatyczny generator <picture> z wieloma formatami. Dokumentacja i komunikacja Elegant Themes mówią o module obrazu i natywnym wsparciu srcset dla responsywnych obrazów, nie o automatycznym budowaniu picture z AVIF/WebP/JPG.

WordPress działa podobnie. Funkcja wp_get_attachment_image() zwraca element <img>, a osobna funkcja wp_get_attachment_image_srcset() generuje wartość dla atrybutu srcset. To rozwiązuje temat różnych rozmiarów, ale nie tematu wielu formatów w jednym kontenerze.

Czyli w praktyce wygląda to tak:

jeśli wgrałeś JPG, serwujesz JPG,
jeśli wgrałeś WebP, serwujesz WebP,
jeśli wgrałeś AVIF, serwujesz AVIF,

ale bez automatycznego mechanizmu: „daj AVIF, a jak się nie da, to WebP, a na końcu JPG”.

I właśnie dlatego, jeśli chcesz pójść dalej niż zwykły img, masz w Divi trzy sensowne ścieżki.

Trzy podejścia w Divi 5

Podejście A — Code Module, czyli najprościej i najbardziej bezpośrednio

Jeśli potrzebujesz <picture> w jednym konkretnym miejscu, najprostsza droga to Code Module i wklejenie HTML ręcznie.

To ma sens szczególnie wtedy, gdy chodzi o:

hero image,
wyróżniony obraz na stronie głównej,
pojedynczy ważny blok,
element, który ma wpływ na LCP.

Przykład:

To podejście ma dwie duże zalety: masz pełną kontrolę i nie zależysz od żadnej automatyki. Jednocześnie trzeba pamiętać, że loading=”eager” ma sens tylko dla obrazów naprawdę krytycznych, na przykład hero ponad linią załamania. Dla reszty obrazów lazy loading nadal zwykle będzie lepszym wyborem. Sam atrybut loading jest standardowym mechanizmem przeglądarkowym dla opóźniania lub przyspieszania ładowania obrazów.

To jest też dobra opcja, jeśli chcesz dokładnie kontrolować:

kolejność formatów,
atrybuty width i height,
zachowanie LCP,
fallback.

Podejście B — plugin albo warstwa optymalizacji, która robi to automatycznie

Druga droga to oddanie tematu warstwie optymalizacji obrazów.

Na rynku są rozwiązania, które potrafią automatycznie konwertować obrazy do formatów next-gen i podawać je odpowiednim przeglądarkom. EWWW promuje w Easy IO automatyczne kompresowanie, skalowanie i konwersję do WebP/AVIF, a ShortPixel Adaptive Images komunikuje automatyczne serwowanie WebP i AVIF do wspieranych przeglądarek oraz działanie z page builderami.

To podejście ma sens, jeśli:

masz dużo obrazów,
nie chcesz ręcznie wstawiać <picture>,
chcesz mieć rozwiązanie bardziej systemowe niż pojedyncze Code Module.

W praktyce nie zawsze będzie to dosłownie „wstawianie <picture> w kodzie strony” w każdym narzędziu, bo część rozwiązań robi to na poziomie CDN, część przez przepisywanie outputu, a część przez logikę serwera. Z punktu widzenia efektu najważniejsze jest jednak to, że przeglądarka wspierająca AVIF/WebP dostaje lżejszy wariant, a reszta fallback.

Podejście C — filtr PHP, czyli pełna kontrola dla własnego motywu lub child theme

Trzecia droga to własny kod po stronie WordPressa.

Skoro wp_get_attachment_image() zwraca HTML obrazka, możesz ten HTML przechwycić filtrem i zastąpić własnym znacznikiem picture. WordPress dokumentuje samą funkcję i fakt, że zwraca ona string HTML z obrazem, więc technicznie taki kierunek jest możliwy.

Szkic idei może wyglądać tak:

add_filter(’wp_get_attachment_image’, function ($html, $attachment_id) {
// tutaj budujesz własne <picture>
return $html;
}, 10, 2);

To rozwiązanie ma sens tylko wtedy, gdy:

masz child theme,
chcesz pełnej kontroli,
umiesz utrzymać taki kod,
nie chcesz opierać się na pluginie.

Do pojedynczego hero to przerost formy nad treścią. Do własnego, bardziej systemowego wdrożenia — już niekoniecznie.

Kiedy to ma sens, a kiedy nie

Nie każdy obrazek na stronie wymaga ręcznie budowanego <picture>.

To rozwiązanie naprawdę ma sens, gdy:

budujesz nową stronę i możesz to zaplanować od początku,
zależy Ci na LCP,
masz ciężkie hero images,
chcesz wycisnąć więcej z formatów next-gen,
pracujesz nad najważniejszymi obrazami, a nie nad każdą miniaturą na blogu.

Mniejsze znaczenie będzie to miało wtedy, gdy:

obraz jest mały i lekki,
masz już warstwę cache/optymalizacji, która robi replacement automatycznie,
zysk z AVIF będzie pomijalny względem całego kosztu wdrożenia.

Tu warto wspomnieć o LiteSpeed Cache. Oficjalna dokumentacja pokazuje, że w ustawieniach obrazu można konfigurować WebP lub AVIF Replacement, czyli automatyczną podmianę obrazów JPG na format next-gen w określonych atrybutach i miejscach. Jeśli to masz włączone i dobrze skonfigurowane, część roboty jest już wykonana bez ręcznego grzebania w Divi.

Innymi słowy: zanim zaczniesz ręcznie pisać <picture>, sprawdź, czy Twoja obecna warstwa optymalizacji nie robi już tego za Ciebie albo nie rozwiązuje problemu wystarczająco dobrze.

Jak to sprawdzić w praktyce

Najprostszy test zrobisz w DevTools.

Otwórz stronę, przejdź do zakładki Network, odfiltruj Images i zobacz:

czy przeglądarka pobiera .avif,
czy pobiera .webp,
czy jednak leci oryginalny .jpg albo .png.

To bardzo szybko pokazuje, czy:

Twój picture działa,
plugin naprawdę podmienia format,
LiteSpeed rzeczywiście robi replacement,
czy tylko wydaje Ci się, że „coś jest zoptymalizowane”.

Przy takich testach warto też sprawdzać stronę w więcej niż jednej przeglądarce, bo cała idea picture polega właśnie na tym, że różne przeglądarki mogą wybrać różne warianty obrazu. Kompatybilność AVIF nadal zależy od wersji przeglądarki, co dobrze pokazują aktualne tabele wsparcia.

Najważniejsza rzecz do zapamiętania

Sam img z srcset rozwiązuje temat rozmiarów.

<picture> rozwiązuje temat formatów i fallbacków.

Jeśli więc po wpisie o AVIF chcesz zrobić krok dalej i naprawdę wdrożyć nowoczesne obrazy w Divi 5, to pytanie nie brzmi już: „czy AVIF jest lżejszy?”, tylko raczej:

jak podać AVIF tak, żeby nowoczesne przeglądarki dostały AVIF, a starsze nadal zobaczyły obraz?

I właśnie na to odpowiada <picture>.

Przejdź do Strefy Divi