Tła w Divi 5 i — co Divi robi natywnie, kiedy zwykły img nie wystarczy i jak podejść do AVIF z fallbackiem

[Wersja angielska wpisu]

Jeśli wrzucasz obraz do Divi 5, wszystko na pierwszy rzut oka wygląda prosto. Wybierasz plik, osadzasz go w module obrazu albo ustawiasz jako tło sekcji i gotowe.

Problem zaczyna się wtedy, gdy chcesz wejść poziom wyżej i zrobić to naprawdę sensownie: podać nowoczesny format, na przykład AVIF, ale bez ryzyka, że część użytkowników zobaczy pusty blok albo mniej przewidywalne zachowanie niż zakładałeś.

I właśnie tu wychodzi różnica między trzema rzeczami, które łatwo wrzucić do jednego worka, a nie są tym samym:

zwykły obraz osadzony jako img,
obraz podawany przez <picture>,
obraz ustawiony jako tło sekcji przez CSS.

W Divi 5 to rozróżnienie ma znaczenie, bo builder nie rozwiązuje wszystkiego za Ciebie automatycznie. Jeśli chcesz świadomie podejść do AVIF, WebP, fallbacków i teł sekcji, trzeba wiedzieć, gdzie kończy się standard Divi, a gdzie zaczyna się własne wdrożenie.

Ten poradnik właśnie to porządkuje.

Zacznijmy od podstaw: co Divi 5 robi natywnie

Jeśli wstawiasz obraz przez normalny moduł obrazu w Divi, w praktyce kończysz z klasycznym obrazem HTML. Czyli z punktu widzenia przeglądarki to nadal jest po prostu osadzony obraz, a nie jakiś specjalny mechanizm „wieloformatowy”.

To ważne, bo wiele osób zakłada, że skoro WordPress i Divi ogarniają responsywne obrazy, to temat nowoczesnych formatów też załatwia się sam. A to już nie działa tak prosto.

Natywnie dostajesz zwykle:

obraz jako img,
różne rozmiary przez srcset,
automatyczne dobieranie szerokości zależnie od urządzenia.

To jest dobre i potrzebne. Tyle że to nadal rozwiązuje przede wszystkim temat rozmiaru, a nie formatu.

Czyli:

przeglądarka może wybrać mniejszy albo większy wariant tego samego obrazu,
ale nadal dostaje jeden typ pliku.

Jeśli więc wrzuciłeś JPG, użytkownik dostaje JPG.

Jeśli wrzuciłeś WebP, dostaje WebP.

Jeśli wrzuciłeś AVIF, dostaje AVIF.

I tu właśnie zaczyna się właściwy temat tego wpisu.

Dlaczego sam

img

przestaje wystarczać

Przez lata to było zupełnie okej. Jeden obraz, jeden format, jeden src.

Dopiero nowoczesne formaty zaczęły naprawdę robić różnicę. AVIF potrafi być wyraźnie lżejszy od starszych formatów przy zachowaniu bardzo dobrej jakości, więc naturalnie pojawia się myśl:

to może po prostu wgrywać AVIF i mieć temat zamknięty?

No właśnie nie do końca.

Bo problem nie polega na tym, że AVIF jest zły. Problem polega na tym, że nie każda przeglądarka i nie każde środowisko obsługują go równie pewnie. Nowoczesne przeglądarki radzą sobie z nim dobrze, ale jeśli chcesz podejść do tematu bezpiecznie, nie możesz zakładać, że każdy użytkownik zobaczy dokładnie to samo.

I właśnie dlatego sam img z jednym plikiem zaczyna być za mały jako mechanizm.

Nie chodzi już tylko o to, jak lekki jest obraz, ale też:

kto może go odczytać,
co dostanie użytkownik, jeśli nie może,
i jak zrobić to bez ręcznego dzielenia strony na wersję dla jednych i drugich.

Tu wchodzi <picture>.

Po co istnieje

<picture>

Najprościej mówiąc: <picture> daje przeglądarce wybór.

Nie wciskasz jednego pliku wszystkim. Zamiast tego mówisz:

jeśli umiesz AVIF, weź AVIF,
jeśli nie, spróbuj WebP,
a jeśli nie rozumiesz nic nowego, masz jeszcze zwykły JPG.

Najprostszy zapis wygląda tak:

I to jest właśnie największa różnica między zwykłym img a picture.

img mówi:

oto obraz.

picture mówi:

oto kilka wersji tego samego obrazu — wybierz najlepszą, którą rozumiesz.

Na końcu zostaje jeszcze img, czyli bezpieczny fallback. Dzięki temu nawet jeśli przeglądarka nie załapie żadnego z nowocześniejszych formatów, nadal dostanie coś, co umie wyświetlić.

To bardzo elegancki mechanizm i właśnie dlatego tak dobrze łączy się z AVIF.

Gdzie Divi kończy swoją robotę

I tu dochodzimy do rzeczy, która dla wielu osób bywa trochę rozczarowująca.

Divi 5 nie buduje za Ciebie automatycznie picture z fallbackami formatów.

Builder daje Ci wygodny moduł obrazu, ustawienia sekcji, tła, layout, responsywność, ale nie działa na zasadzie:

wrzuciłeś JPG,
system zrobił z tego AVIF i WebP,
osadził <picture>,
dorzucił fallback,
i wszystko samo się poukładało.

Tak to nie działa.

Masz więc trzy poziomy pracy:

Poziom 1: zostajesz przy tym, co daje Divi natywnie.

Poziom 2: ręcznie wchodzisz w <picture> przez Code Module.

Poziom 3: kombinujesz z tłem sekcji i wtedy wchodzisz już w temat CSS.

I właśnie ten trzeci poziom jest najciekawszy.

Najprostsza praktyczna droga: Code Module i ręczne

<picture>

Jeśli potrzebujesz jednego konkretnego obrazu w nowoczesnym formacie z fallbackiem, najprostsza droga w Divi 5 jest zaskakująco prosta:

Code Module.

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

hero image,
ważny obraz nad foldem,
wyróżniony element sekcji,
pojedynczy blok, który naprawdę ma znaczenie dla wydajności albo wyglądu.

W praktyce wrzucasz do Code Module taki kod:

I to już działa.

Tu warto dobrze rozumieć, co się dzieje:

source z AVIF jest pierwszą opcją,
jeśli nie przejdzie, przeglądarka sprawdzi WebP,
jeśli i to nie zadziała, zostaje JPG w img.

Czyli dokładnie to, czego nie daje zwykły moduł obrazu Divi.

Kiedy takie ręczne <picture> ma sens

Nie wszędzie.

Jeśli masz blog z setkami obrazów, ręczne wpisywanie takiego kodu do każdego elementu nie ma sensu. Ale jeśli mówimy o:

jednym hero,
jednym dużym obrazie w sekcji,
jednym bardzo ważnym banerze,

to już jest zupełnie rozsądne.

To podejście ma trzy duże zalety:

pełną kontrolę,
prosty fallback,
przewidywalne zachowanie.

Ale ma też ograniczenie:

jest ręczne.

To nie jest rozwiązanie „na cały serwis” bez dodatkowej logiki. To jest rozwiązanie dla miejsc, które naprawdę chcesz dopieścić.

Ważna uwaga o hero i

loading=”eager”

Jeśli taki obraz siedzi wysoko na stronie i jest częścią pierwszego ekranu, nie chcesz, żeby ładował się za późno.

Dlatego dla obrazu hero sens ma:

loading=”eager”

To sygnał, że ten obraz nie powinien czekać w kolejce jak zwykły obrazek niżej na stronie.

Ale uwaga: nie rób tak wszędzie.

Jeśli wszystko ustawisz jako eager, to przestaje to mieć sens. To ruch dla obrazów naprawdę krytycznych.

Dla reszty zwykle lepiej działa lazy loading albo po prostu domyślne podejście.

Dobrze, ale co z tłem sekcji?

I tu zaczyna się właściwie najciekawsza część.

Bo w Divi bardzo często nie chcesz osadzić obrazu „normalnie”. Chcesz go jako:

tło hero,
tło dużej sekcji CTA,
tło bannera,
tło całego bloku.

I wtedy intuicyjnie pojawia się pytanie:

czy mogę użyć <picture> jako tła sekcji?

Nie wprost.

I to jest moment, który trzeba dobrze zrozumieć.

Tło sekcji w Divi to zwykle CSS, nie HTML

Kiedy ustawiasz tło sekcji w Divi, nie osadzasz obrazu jako elementu HTML w treści. Ustawiasz go jako styl sekcji.

Czyli w praktyce kończysz z czymś w rodzaju:

background-image: url(„hero.jpg”);

To nie jest ten sam świat co <picture>.

<picture> działa w HTML.

background-image działa w CSS.

I CSS nie przyjmie znacznika HTML jako wartości tła. Nie da się więc zrobić czegoś w stylu:

„w tle sekcji użyj <picture>”.

To po prostu nie jest ten typ mechanizmu.

Czy CSS ma w ogóle jakiś odpowiednik takiego wyboru?

Tak, ale nie taki sam.

CSS ma własny mechanizm wyboru obrazu:

image-set()

I to właśnie jest ten moment, który robi się naprawdę ciekawy.

Bo jeśli w HTML masz:

picture,
source,
fallback img,

to w CSS możesz podejść do tematu tak:

.hero {
background-image: image-set(
url(„/wp-content/uploads/2026/04/hero.avif”) type(„image/avif”),
url(„/wp-content/uploads/2026/04/hero.jpg”) type(„image/jpeg”)
);
background-size: cover;
background-position: center;
}

Czyli CSS też może próbować powiedzieć:

jeśli umiesz AVIF, użyj AVIF,
jeśli nie, weź JPG.

Brzmi świetnie. I rzeczywiście jest świetne jako pomysł.

Ale tu wchodzi bardzo ważne „ale”.

Problem z CSS jest właśnie tym, co czyni temat ciekawym

To jest naprawdę fajna puenta dla całego poradnika.

Bo kończysz z sytuacją, w której:

chcesz bezpiecznie osadzić format obrazu, który nie wszędzie działa idealnie,
i robisz to przez mechanizm CSS, który też nie jest takim samym „żelaznym standardem fallbacku” jak HTML-owe <picture>.

Czyli:

używasz mechanizmu z niepełnym wsparciem, żeby lepiej osadzić obraz z niepełnym wsparciem.

To nie znaczy, że image-set() jest zły.

To znaczy tylko, że trzeba rozumieć jego miejsce.

Czy

image-set()

jest bezużyteczny? Nie

Wręcz przeciwnie — jest bardzo ciekawy i praktyczny.

Jeśli chcesz zostać przy prawdziwym tle CSS, a jednocześnie podejść nowocześniej do formatów, to image-set() jest właśnie tym mechanizmem, który warto znać.

Ma sens, gdy:

naprawdę potrzebujesz background-image,
nie chcesz robić pseudo-tła przez HTML,
akceptujesz, że to bardziej technika dla świadomego wdrożenia niż rozwiązanie „włącz i zapomnij”.

Ale jeśli obraz jest naprawdę krytyczny i chcesz możliwie najpewniejszy fallback, to HTML-owe <picture> nadal jest łatwiejsze do przewidzenia.

Czyli co wybrać w praktyce?

To najważniejsze pytanie.

Zostań przy natywnym Divi, jeśli:

obraz nie jest krytyczny,
nie potrzebujesz fallbacków formatów,
chcesz po prostu działać szybko.

Użyj Code Module i

<picture>

, jeśli:

chcesz AVIF z fallbackiem,
obraz jest ważny,
zależy Ci na kontroli,
to pojedynczy, konkretny element.

Użyj CSS

image-set()

, jeśli:

potrzebujesz prawdziwego tła sekcji,
chcesz zostać przy background-image,
rozumiesz ograniczenia tej drogi.

To właśnie daje Ci sensowną mapę decyzji.

A co jeśli chcesz mieć „tło”, ale jednak użyć

<picture>

?

To jest jeszcze jedna ważna rzecz.

Technicznie nie możesz osadzić <picture> jako background-image, ale możesz zrobić sekcję, która zachowuje się jak tło, choć tak naprawdę ma obraz jako warstwę HTML pod treścią.

Czyli:

sekcja dostaje position: relative,
obraz przez <picture> jest absolutnie pozycjonowany na całą sekcję,
treść siedzi nad nim z wyższym z-index,
img dostaje object-fit: cover.

Wizualnie wygląda to jak tło.

Technicznie nadal korzystasz z pełnego mechanizmu <picture>.

To często jest najlepszy kompromis, jeśli:

chcesz efekt tła,
ale nie chcesz rezygnować z bezpieczniejszego modelu HTML.

I to już jest bardzo praktyczny temat na osobny wpis.

Kiedy ten cały temat naprawdę ma sens

Nie przy każdym obrazku.

To ma sens wtedy, gdy:

budujesz nową stronę i chcesz świadomie podejść do wydajności,
masz duże hero images,
walczysz o LCP,
chcesz wycisnąć więcej z obrazów nad foldem,
zależy Ci na czymś więcej niż „wgrałem plik i niech się dzieje”.

Jeśli obraz jest mały, lekki i ma niewielkie znaczenie, to często szkoda komplikować wdrożenie.

Ale jeśli mówimy o głównych sekcjach strony, ten temat przestaje być niszowy. Zaczyna być po prostu sensowny.

Co sprawdzić po wdrożeniu

Po wszystkim warto zrobić jedną bardzo prostą rzecz:

otworzyć DevTools i sprawdzić, co naprawdę pobiera przeglądarka.

Nie zakładaj, że wszystko działa tylko dlatego, że wkleiłeś kod.

Sprawdź:

czy nowoczesna przeglądarka naprawdę pobiera AVIF,
czy fallback działa,
czy nie leci stary JPG mimo całej konfiguracji,
czy hero nie ładuje się za późno,
czy tło sekcji nie zachowuje się inaczej niż zakładałeś.

To jest ten moment, który oddziela „mam kod” od „mam działające wdrożenie”.

Najczęstszy błąd w tym temacie

Najczęstszy błąd nie polega na złym kodzie.

Polega na pomieszaniu trzech różnych rzeczy:

obrazu HTML,
picture,
tła CSS.

I wtedy pojawiają się pytania typu:

czemu nie mogę wkleić <picture> jako background,
czemu Divi tego nie ogarnia samo,
czemu srcset nie załatwia AVIF fallbacku,
czemu tło sekcji działa inaczej niż moduł obrazu.

Jak tylko rozdzielisz te mechanizmy, wszystko robi się dużo prostsze.

Najkrótszy wniosek z całego wpisu

Jeśli chcesz tylko wrzucić obraz do Divi 5, natywne metody zwykle wystarczą.

Jeśli chcesz pójść dalej i sensownie podawać AVIF z fallbackiem:

dla zwykłych obrazów najczyściej działa <picture>,
dla teł sekcji możesz próbować image-set(),
ale musisz rozumieć, że to nie jest dokładnie ten sam model bezpieczeństwa i fallbacku.

I właśnie dlatego ten temat jest ciekawy.

Bo nie chodzi już tylko o sam obraz.

Chodzi o to, który mechanizm wybiera go dla użytkownika.

Przejdź do Strefy Divi