Nowoczesna optymalizacja obrazów w WordPressie w 2026 roku

AVIF akceptuje 96,35% ruchu przeglądarek mierzonego przez caniuse (stan na 12 października 2026). Rozdział o mediach w Web Almanac 2024 znalazł go w 1,0% obrazów na urządzeniach mobilnych. Tej różnicy ponad 95 punktów nie tłumaczą przeglądarki. Tłumaczy ją ścieżka przesyłania, znacznik, który wybiera kandydata, i moment, w którym przeglądarka dowiaduje się, że obraz w ogóle istnieje.

Dlatego ten przewodnik nie zaczyna się od tabeli formatów. Zaczyna się od diagnozy, przechodzi przez przesyłanie i kończy na serwowaniu, bo w takiej kolejności psują się rzeczy na stronie, która już działa na produkcji.

Trzy warstwy, w których ginie praca, w kolejności, w jakiej przechodzi przez nie obraz:

• Przesyłanie: jaki format i jaką maksymalną szerokość serwer w ogóle wyprodukuje.
• Znacznik: którego kandydata z srcset przeglądarka ostatecznie wybierze.
• Odkrycie: w którym momencie przeglądarka dowiaduje się, że obraz istnieje.

#Jak znaleźć element LCP w WordPressie

Zanim cokolwiek przekonwertujesz, potwierdź, który element jest Largest Contentful Paint w każdym szablonie, na danych terenowych, a nie na przypuszczeniu. Web Almanac 2024 zmierzył, że na 68% stron mobilnych tym elementem jest obraz, a mediana największego obrazu wynosi 135 KB. Czytając to odwrotnie: na pozostałych 32% LCP to tekst i tam konwersja do AVIF nie ruszy metryki ani o milisekundę.

Są dwa przypadki, w których rdzeń WordPressa nie pomoże, nawet jeśli LCP faktycznie jest obrazem:

1. Element LCP nie jest tagiem img wyrenderowanym przez rdzeń. Tło CSS, plakat elementu video albo page builder, który zapisuje znaczniki poza wp_filter_content_tags(). Rdzeń nie nadaje priorytetu temu, czego nie widzi, więc obraz w hero przychodzi po arkuszu stylów, który się do niego odwołuje.
2. Element LCP zmienia się zależnie od breakpointu. Zdjęcie w nagłówku na desktopie i karta na telefonie to różne elementy. Statyczne założenie trafia w jeden z nich.

Na te dwa przypadki jest Image Prioritizer, który wymaga wtyczki Optimization Detective. Optimization Detective zbiera URL Metrics od prawdziwych odwiedzających osobno dla każdego breakpointu, więc wie, który element był LCP, zamiast zgadywać z kolejności w dokumencie. Na tej podstawie Image Prioritizer dodaje preload o wysokim priorytecie dla obrazu LCP, jako element LINK w HTML i jako nagłówek HTTP Link, a preload obejmuje też tła CSS (inline lub z arkusza stylów) i plakaty wideo. Ustawia fetchpriority=high na img tylko wtedy, gdy ten element jest LCP we wszystkich breakpointach, ustawia fetchpriority=low na obrazach w początkowym widoku, które są ukryte (slajdy drugi i trzeci karuzeli, klasyczny przypadek), i odracza ładowanie teł zadeklarowanych w atrybutach style inline. Nie ma ekranu ustawień i działa dopiero wtedy, gdy zebrano metryki odwiedzających.

Obie wtyczki pochodzą od zespołu wydajności rdzenia, tego samego, który publikuje na make.wordpress.org/performance. To nie są narzędzia firm trzecich, tylko laboratorium rzeczy, które trafiają potem do WordPressa, więc to, co dziś instalujesz jako wtyczkę, wyznacza oficjalny kierunek projektu.

#Jak włączyć AVIF w WordPressie

WordPress 6.5 dodał obsługę AVIF w lutym 2024, w zmianie ogłoszonej przez Adama Silversteina. Od tego czasu możesz przesyłać i serwować .avif tak samo jak JPEG, bez wtyczek, pod warunkiem że kompilacja Imagick lub LibGD na serwerze potrafi go kodować. Ten warunek ma własny ekran w panelu: Narzędzia > Kondycja witryny > Informacje > Obsługa mediów.

W tym miejscu warto zejść z teorii na prawdziwy hosting. Na hostingu współdzielonym (home.pl, nazwa.pl, cyber_Folks, LH.pl i podobne oferty) nie wybierasz kompilacji ImageMagick, tylko ją dziedziczysz. Wersja PHP w panelu nic nie mówi o delegatach Imagick, a migracja między pakietami tego samego dostawcy może je zmienić. Otwórz Kondycję witryny po każdej przeprowadzce i po każdej większej aktualizacji serwera, i traktuj wynik jako daną projektu, a nie jednorazowe sprawdzenie. Motyw, który zakłada AVIF na serwerze bez jego obsługi, nic nie wyprodukuje i o niczym nie ostrzeże.

Druga rzecz: rdzeń sam niczego nie konwertuje. Przesłany JPEG zostaje JPEG-iem, a jego rozmiary pośrednie też zostają JPEG-ami. Zmienia to hook image_editor_output_format, dostępny od WordPressa 5.8, który mapuje typ mime źródła na typ mime wyjścia:

add_filter( 'image_editor_output_format', function ( $formats ) {
    $formats['image/jpeg'] = 'image/avif';
    return $formats;
} );

Trzy konsekwencje, zanim wdrożysz ten filtr:

• Oryginalny plik zostaje nietknięty. Nowy format dostają tylko generowane rozmiary pośrednie i właśnie dzięki temu bibliotekę mediów da się dalej edytować.
• Działa tylko dla przyszłych przesłań. Istniejące media wymagają regeneracji.
• Jego wartość domyślna nie jest już pusta. Od WordPressa 6.7 rdzeń dodaje w tym filtrze mapowania HEIC i HEIF na JPEG, więc zwracaj tablicę, którą dostałeś, zamiast budować nową. Kto w 2023 roku napisał return array( 'image/jpeg' => 'image/avif' );, dziś po cichu wyłącza konwersję zdjęć przesyłanych z iPhone’a.

Drugie ustawienie rdzenia, które wpływa na każde przesłanie, to big_image_size_threshold, 2560 pikseli od WordPressa 5.3. Każdy obraz szerszy lub wyższy zostaje zmniejszony, a pomniejszona kopia staje się największym dostępnym rozmiarem. Przesłane pliki PNG są z tego skalowania wyłączone. Jeśli miejsce na hero jest naprawdę szersze niż 2560 pikseli, już serwujesz powiększony obraz i żadna praca nad formatem nie naprawi tej miękkości.

#Jak długo trwa kodowanie AVIF

Dokumentacja transformacji Cloudflare podaje, że kodowanie AVIF może być o rząd wielkości wolniejsze niż kodowanie do innych formatów, a jeśli obraz jest za duży, żeby zakodować go szybko, Cloudflare wraca do WebP lub JPEG. Ta sama arytmetyka obowiązuje na Twoim serwerze źródłowym, a tym bardziej na pakiecie współdzielonym z limitem procesów. Masowa konwersja biblioteki 40 000 elementów to zadanie wsadowe z kolejką i oknem czasowym, a nie kliknięcie w ekranie ustawień.

#Jak regenerować miniatury przez WP-CLI

Filtr dotyczy tylko nowych przesłań, więc istniejąca biblioteka potrzebuje osobnego przebiegu. wp media regenerate przechodzi przez załączniki i ponownie tworzy rozmiary pośrednie z bieżącą konfiguracją, w tym z formatem wyjściowym, który właśnie ustawiłeś. Dwie flagi oszczędzają większość kłopotów: --only-missing, żeby nie powtarzać pracy wykonanej w przerwanym wcześniej przebiegu, i --image_size, żeby ograniczyć przebieg do jednego rozmiaru, gdy zmienił się tylko on.

wp media regenerate --only-missing --yes

Ograniczaj samo uruchomienie, nie tylko polecenie. Na hostingu współdzielonym regeneracja dziesiątek tysięcy załączników konkuruje o ten sam procesor, który obsługuje prawdziwy ruch, a AVIF jest formatem, który zużywa go najwięcej. Dziel bibliotekę na zakresy identyfikatorów, uruchamiaj poza godzinami szczytu i zachowaj log: lista załączników, które się nie powiodły, to inwentarz uszkodzonych oryginałów, których nikt nie oglądał od lat.

Jeśli wynik nie przekonuje, wyjściem jest powtórzenie przebiegu z innym ustawieniem jakości, a nie przywracanie kopii zapasowej. Oryginał nigdy nie został ruszony.

#Jaką jakość kompresji ustawić w WordPressie

WP_Image_Editor::$default_quality wynosi 82 i jest przestarzałe od WordPressa 5.8.1 na rzecz get_default_quality(), które zwraca 86 dla WebP i te same 82 dla JPEG oraz wszystkich pozostałych formatów. JPEG przechodzi potem przez filtr jpeg_quality, który działa po wp_editor_set_quality i dlatego ma ostatnie słowo.

Oba filtry dostają inne argumenty, a ich pomylenie to typowy sposób, żeby reguła pomyślana dla jednego formatu zaczęła obowiązywać wszystkie. wp_editor_set_quality dostaje domyślną jakość, typ mime i, od WordPressa 6.8, wymiary, więc pozwala różnicować jakość według formatu i rozmiaru. jpeg_quality dostaje tylko jakość i ciąg kontekstu, na przykład image_resize. Portfolio fotograficzne i biblioteka zrzutów ekranu interfejsu nie potrzebują tej samej liczby.

Warto też wiedzieć, jak każdy format psuje się przy zbyt niskiej wartości. JPEG psuje się widocznie, blokami i obwódkami, które widać nawet na miniaturze. AVIF przy niskiej jakości wygładza drobną teksturę: ziarno, tkanina, liście i włosy tracą szczegóły, a krawędzie zostają czyste. Ten tryb błędu dużo trudniej zobaczyć w małym rozmiarze, więc przegląd trzeba robić w pełnej rozdzielczości i na prawdziwym szablonie, a nie na siatce biblioteki mediów.

I ostrzeżenie co do liczb. Pomysł, że koder wykrywa twarz, agresywnie kompresuje niebo i daje konkretne 70% oszczędności, krąży bez źródła, które by go potwierdzało. Traktuj każdą taką liczbę jako niezweryfikowaną, dopóki nie zmierzysz jej na własnej bibliotece. Panel wtyczki, który raportuje procent oszczędności, raportuje pliki na dysku, a nie to, co pobrała przeglądarka po tym, jak edge wynegocjował format. Liczą się tylko dwa pomiary: bajty dostarczone dla zasobu LCP i efekt wizualny na szablonie, na którym obraz jest publikowany.

Praktyczne sprawdzenie mieści się w dwudziestu minutach. Wybierz mały zestaw reprezentatywnych obrazów z prawdziwej biblioteki (twarz, produkt na białym tle, zrzut ekranu z drobnym tekstem i szeroki krajobraz), zakoduj go z każdym kandydującym ustawieniem i obejrzyj w pełnym rozmiarze. To chroni przed publikacją globalnej wartości, która zniszczy zdjęcia produktów.

#Jak używać srcset i sizes w WordPressie

Wydajny format w złym wymiarze nadal psuje LCP. Jeśli hero na telefonie ma 390 px szerokości w CSS, a src wskazuje plik o szerokości 2000 px, przeglądarka pobiera o megabajty za dużo, nawet w AVIF.

WordPress rejestruje rozmiary przez add_image_size(), a przy renderowaniu wp_get_attachment_image_srcset() buduje listę kandydatów. Atrybut sizes mówi przeglądarce, jakiej szerokości w CSS ma się spodziewać na każdym breakpoincie. Bez realistycznego sizes (na przykład (max-width: 768px) 100vw, 720px) przeglądarka może wybrać za dużego kandydata. Jakie rozmiary WordPress tworzy domyślnie i jak zarejestrować własne, omawiamy w przewodniku o TimThumb i natywnej obsłudze obrazów.

Krótka lista kontrolna:

• Rejestruj tylko rozmiary, których używa motyw (bez dziesiątek martwych kadrów).
• Po zmianie zregeneruj miniatury (wp media regenerate, patrz wyżej).
• Na hero sprawdź w zakładce Network w DevTools, jaką szerokość pliku wybrano, a nie tylko Content-Type.
• W blokach Gutenberga trzymaj obrazy w zgodzie z content width motywu; przesyłanie plików 5000 px “bo potem przytniemy” zwiększa zajętość dysku i czas generowania.

Przydatna dokumentacja: opis wp_get_attachment_image_srcset w Developer Handbook i materiały o obrazach na web.dev tłumaczą tę samą ideę z dwóch stron (CMS i przeglądarki).

#Fetchpriority i sizes auto w WordPressie 6.3 i 6.7

Rada, żeby ręcznie dodawać loading="eager" i fetchpriority="high", jest od trzech lat nieaktualna dla obrazów w treści. WordPress 6.3 dodał wp_get_loading_optimization_attributes(), która wylicza oba atrybuty dla obrazów przechodzących przez ścieżkę renderowania rdzenia:

• Pierwszy obraz spełniający próg dostaje fetchpriority="high". Spełnienie progu oznacza minimalną powierzchnię 50 000 pikseli, szerokość razy wysokość, regulowaną filtrem wp_min_priority_img_pixels.
• loading="lazy" jest pomijane na obrazach blisko początku dokumentu. Próg ustawia filtr wp_omit_loading_attr_threshold, którego wartość domyślna wzrosła w 6.3 z 1 do 3.
• Funkcja nigdy nie emituje razem fetchpriority="high" i loading="lazy", bo to sprzeczne instrukcje.

WordPress 6.7 dodał potem sizes="auto" dla obrazów ładowanych leniwie, przez wp_img_tag_add_auto_sizes(). To poprawka najstarszego błędu srcset w WordPressie: generowany atrybut sizes zakładał, że obraz zajmuje cały viewport, więc miniatura z paska bocznego o szerokości 300 pikseli mogła na telefonie ściągnąć kandydata 1024. Ponieważ obraz leniwy nie ładuje się, zanim układ jest gotowy, przeglądarka może użyć prawdziwej szerokości. Rdzeń dopisuje auto tylko wtedy, gdy obraz ma już loading="lazy", i dołącza małą regułę CSS (wp_enqueue_img_auto_sizes_contain_css_fix()), żeby uniknąć efektu ubocznego w układzie.

Wniosek z obu wersji razem: priorytet i szerokość nie są już decyzją motywu. Jeśli Twój szablon nadal wymusza te atrybuty ręcznie, najpewniej walczy z rdzeniem, a nie z przeglądarką.

#Jak serwować AVIF z zapasowym JPEG

Rdzeń zapisuje jeden src i jeden srcset. Nie zapisuje <picture>, co oznacza, że sam nie potrafi z tego samego znacznika serwować AVIF przeglądarkom, które go akceptują, i JPEG pozostałym. Dostajesz jeden format na każdy wygenerowany rozmiar. Są dwie sensowne odpowiedzi i w praktyce wykluczają się nawzajem.

Negocjacja treści na edge lub na serwerze. CDN czyta nagłówek Accept i z jednego adresu serwuje AVIF, WebP albo JPEG. HTML zostaje prosty. Kosztem jest to, że cache zaczyna zależeć od nagłówków żądania, więc klucze cache muszą to uwzględniać, a niedbała konfiguracja potrafi podać AVIF klientowi, który go nie akceptuje.

Zapas na poziomie znacznika. Wtyczka Modern Image Formats, część programu Performance Lab, generuje przy przesyłaniu rozmiary pośrednie w nowoczesnych formatach i od wersji 2.0.0 potrafi emitować elementy <picture> z zapasem. Domyślnie wybiera AVIF, gdy serwer go obsługuje, a w przeciwnym razie WebP, co jest właściwym ustawieniem dla wtyczki, która nie zna Twojej infrastruktury. Jej ustawienia są w Ustawienia > Media. Tak jak filtr rdzenia, działa dla nowych przesłań.

I zachowaj JPEG. Poza przeglądarką to nadal bezpieczny format dla klientów poczty, obrazów Open Graph, kart w mediach społecznościowych, czytników RSS i każdego feedu, który pobiera partner. Modern Image Formats zachowuje oryginalny przesłany plik, ale domyślnie generuje rozmiary pośrednie z JPEG i PNG wyłącznie w nowoczesnym formacie. Jeśli feed albo karta społecznościowa potrzebuje rozmiarów pośrednich w JPEG, zaznacz opcję Output fallback images w Ustawienia > Media: wtyczka wygeneruje wtedy oryginalny format obok nowoczesnego w każdym rozmiarze, kosztem miejsca na dysku i czasu przy każdym przesłaniu.

#Skalowanie obrazów przez Cloudflare w WordPressie

Transformacja na edge zdejmuje skalowanie i negocjację formatu z serwera PHP, co jest mocnym argumentem, gdy źródłem jest pakiet współdzielony. W Cloudflare oznacza to adres w postaci https://<STREFA>/cdn-cgi/image/<OPCJE>/<OBRAZ-ŹRÓDŁOWY>, gdzie źródło to bezwzględna ścieżka na serwerze albo bezwzględny URL, a opcje rozdziela się przecinkami. Tutaj liczy się format=auto, które serwuje najwydajniejszy format akceptowany przez klienta.

Trzy rzeczy z dokumentacji, które zmieniają planowanie:

• Trzeba to włączyć dla strefy w panelu, zanim jakikolwiek adres transformacji zadziała na tym hoście. To najczęstszy powód, dla którego poprawnie napisany adres zwraca oryginał bez skalowania.
• Obrazy źródłowe są domyślnie ograniczone do tej samej strefy. Dozwolone źródła wynikają z listy, którą Cloudflare opisuje osobno od formatu adresu: osobną subdomenę na media albo bucket S3 trzeba do tej listy dodać lub otworzyć strefę na dowolne źródło.
• format=auto może odmówić AVIF. Z powodu kosztu kodowania, o którym była mowa, Cloudflare wraca do WebP lub JPEG, gdy obraz jest za duży, żeby zakodować go szybko. Twój nagłówek może być AVIF-em w testach i WebP na produkcji, zależnie od wymiarów źródła, i tej różnicy nie pokaże żaden raport wtyczki.

Edge nie usuwa potrzeby poprawnych srcset i sizes (jak WordPress buduje je z add_image_size(), opisujemy w przewodniku o TimThumb i natywnej obsłudze obrazów). Przeglądarka wybiera kandydata, zanim wyśle żądanie, więc błędny znacznik prosi o złą szerokość, a edge posłusznie generuje dokładnie tę złą szerokość. Edge zastępuje stały zestaw rozmiarów WordPressa dowolnymi szerokościami, ale nie zastępuje logiki wyboru.

#Które przeglądarki obsługują JPEG XL w 2026

Tu myli się większość przewodników z 2026 roku, łącznie z wcześniejszą wersją tego tekstu. JPEG XL dopiero zaczyna docierać do serwowania.

Jedyna realna zmiana przyszła 6 października 2026. Ogłoszenie Google brzmi: “Chrome wprowadza obsługę dekodowania formatu obrazów JPEG XL (.jxl) od wersji Chrome 155” (Chrome for Developers, tłumaczenie własne). Użytkownicy Chrome na komputerach dostają ją w miarę aktualizacji przeglądarki w kolejnych tygodniach. Edge, który działa na tym samym silniku, jeszcze za nim nie poszedł.

Caniuse podaje 16,95% globalnego wsparcia JPEG XL na 12 października 2026, wobec 15,02% w chwili pisania pierwszej wersji tej sekcji, i prawie cała ta liczba to wsparcie częściowe. Stan rzeczywisty, przeglądarka po przeglądarce:

Web Almanac w 2024 roku w ogóle nie zmierzył użycia JPEG XL i podał powód: przeglądarki oparte na Chromium nie obsługiwały tego formatu. To uczciwszy sygnał niż jakikolwiek wykres adopcji, bo zbiór danych mierzący cały web nie uznał go za format do serwowania. Chrome 155 zmienia dane wejściowe następnej edycji, a nie wniosek dla strony publikowanej w tym miesiącu. Ostatni wiersz tabeli rozstrzyga sprawę wszędzie tam, gdzie ruch mobilny pochodzi głównie z Androida: ani Chrome na Androida, ani Samsung Internet go nie obsługują.

Co to oznacza w praktyce:

• Jako format archiwalny albo master JPEG XL jest naprawdę dobry. Bezstratne transkodowanie z JPEG i z powrotem to realna funkcja i realny powód, żeby trzymać mastery w JXL. To decyzja o przechowywaniu, a nie o serwowaniu, i nie dotyka Twojego srcset.
• Jeśli zdecydujesz się go serwować, musi stać jako pierwszy <source type="image/jxl"> w <picture>, ze źródłem AVIF i zapasowym JPEG za nim. Ogromna większość odwiedzających i tak dostanie jeden z zapasów, więc gałąź JXL nie zwalnia z budowy reszty.
• Nie używaj go jako argumentu za odkładaniem AVIF. AVIF to format, który dziś ma 96,35% wsparcia.

A jeśli Twój hosting nie potrafi kodować AVIF, odpowiedzią nie jest czekanie na JPEG XL, tylko WebP, przez image_editor_output_format albo ustawienie Modern Image Formats. Obsługa WebP jest znacznie powszechniejsza w starszych kompilacjach Imagick i LibGD, a różnica między JPEG i WebP jest dużo większa niż między WebP i AVIF.

#Jak optymalizować obrazy w WordPressie krok po kroku

Przepływ, który się skaluje bez operacyjnego chaosu:

1. Przesyłanie: zdjęcie źródłowe w sRGB, maksymalna szerokość dopasowana do największego breakpointu motywu (na przykład 1920 lub 2560 px, a nie 8000 px prosto z aparatu; rdzeń i tak zmniejsza wszystko powyżej 2560 px).
2. Generowanie: rdzeń tworzy rozmiary pośrednie w formacie przesłanego pliku; AVIF albo WebP daje image_editor_output_format, Modern Image Formats albo CDN.
3. Renderowanie: wp_get_attachment_image() (albo blok Obraz) z poprawnymi srcset/sizes.
4. Hero: pozwól rdzeniowi ustawić fetchpriority="high" i pominąć lazy; preload tylko wtedy, gdy hero jest tłem albo leży poza znacznikami rdzenia.
5. Reszta: lazy, bez preloadu.
6. Monitoring: PageSpeed/CrUX na prawdziwym adresie URL, z filtrem na “LCP element” i wagę obrazów.

Na hostingu współdzielonym bez AVIF w Imagick konwersja na edge CDN jest często tańsza niż zmiana serwera dla jednego kodeka.

#Częste błędy w optymalizacji obrazów w WordPressie

• PNG dla fotografii. PNG służy do elementów interfejsu i przezroczystości. Zdjęcie w PNG rozdyma dysk i transfer.
• Jakość 100 w JPEG/AVIF. Różnicę względem umiarkowanego poziomu rzadko widać na obrazie, za to widać ją w wadze pliku.
• Kadry 1:1 i 16:9 “na wszelki wypadek”, których nikt nie używa. Każde przesłanie mnoży operacje I/O i kopie zapasowe.
• Lazy na logo i hero. Opóźnia LCP, a przy braku wymiarów w znacznikach także psuje CLS.
• Dwie wtyczki optymalizujące naraz. Jedna przepisuje adresy URL, druga serwuje WebP; efekt to 404 albo podwójne przetwarzanie.
• Ignorowanie width i height. Bez wymiarów wewnętrznych układ skacze, gdy obraz się wczyta.

#Dostępność obrazów w WordPressie a przepisy

Ta część zwykle wypada z przewodników o wydajności, a w Polsce jest wymagana prawem. Od 28 czerwca 2025 Polski Akt o Dostępności, czyli ustawa z 26 kwietnia 2024 wdrażająca europejski akt o dostępności, obejmuje usługi handlu elektronicznego. Według strony rządowej nie stosuje się go do usług oferowanych przez mikroprzedsiębiorców. Wymagania prowadzą do normy EN 301 549 i przez nią do kryteriów WCAG 2.1 na poziomie AA. Jeśli projekt to sklep, uczelnia albo urząd, praca nad obrazami ma dwa kryteria do spełnienia oprócz małej wagi.

Pierwsze to alternatywa tekstowa (1.1.1). Pusty alt jest poprawny i pożądany dla obrazu dekoracyjnego, a dla obrazu niosącego informację jest wadą. WordPress przechowuje to pole w bibliotece mediów, więc audyt to zapytanie do postmeta o _wp_attachment_image_alt, a nie przegląd szablon po szablonie.

Drugie trafia prosto w ten temat: obrazy tekstu (1.4.5). Baner promocyjny z nagłówkiem wtopionym w piksele narusza kryterium, nie da się go przetłumaczyć ani zaznaczyć, a do tego jest najgorszym możliwym kandydatem dla AVIF, bo wygładzanie drobnej tekstury, które stosuje ten format, najmocniej uderza w mały krój pisma. Tekst w HTML nad obrazem rozwiązuje naraz problem prawny i problem kompresji. To samo dotyczy zrzutów ekranu interfejsu z drobnym tekstem: jeśli są ilustracją, przytnij je i powiększ przed kodowaniem, zamiast przesyłać cały ekran i ufać koderowi.

Uwaga pokrewna, gdyby pojawiła się w tym samym przeglądzie: SVG nadal jest właściwą odpowiedzią dla ikon, bo nie zależy od rozdzielczości i jeden plik obsługuje każdą gęstość ekranu bez srcset. Rdzeń domyślnie nie pozwala go przesyłać, bo SVG może zawierać skrypt. Jeśli go włączasz, sanityzuj plik przy przesyłaniu, zamiast ufać osobie, która go przesyła.

#Lista kontrolna optymalizacji obrazów przed publikacją

• Ile waży hero w typowym wariancie mobilnym w porównaniu z medianą 135 KB dla największego obrazu w Web Almanac 2024?
• Czy zakładka Network pokazuje AVIF lub WebP w samym dokumencie, a nie tylko na stronie testowej wtyczki?
• Czy sizes odpowiada faktycznej szerokości treści lub hero w CSS?
• Czy tylko jeden obraz ma fetchpriority="high"?
• Czy CDN (jeśli jest) odpowiada 200 z cache-hit po drugim żądaniu?
• Czy CLS dla hero jest stabilny (wymiary albo aspect-ratio w CSS)?
• Czy obrazy niosące informację mają tekst alternatywny, a tekst na banerach jest w HTML, a nie w pikselach?

Jeśli któryś punkt nie przechodzi, napraw ten punkt, zanim kupisz kolejne narzędzie.

#Od czego zacząć optymalizację obrazów w WordPressie

Formaty są rozstrzygnięte i nie wymagają dalszych badań. AVIF ma 96,35% wsparcia przeglądarek i natywną obsługę w WordPressie od 6.5. JPEG XL nie ma żadnej z tych rzeczy: Chrome 155 zaczął go dekodować 6 października 2026, ale Edge, Chrome na Androida i rdzeń WordPressa nie, więc na razie zostaje poza srcset. WebP to zapas, który działa wszędzie.

Nierozwiązane na prawie każdej stronie jest wszystko, co dzieje się między przesłaniem a odmalowaniem. Kolejność, z pomiarem na każdym kroku: potwierdzić element LCP w każdym szablonie na danych terenowych, sprawdzić w Kondycji witryny, co potrafi kodować serwer, włączyć konwersję rozmiarów pośrednich i partiami zregenerować istniejące media, sprawdzić, czy sizes opisuje prawdziwy układ, zobaczyć, czy edge po cichu nie serwuje WebP, bo źródło było za duże, i zamknąć przeglądem alternatyw tekstowych oraz obrazów tekstu. Te 1% adopcji z Web Almanac to wynik projektów, które zatrzymały się na drugim kroku, bo zainstalowały już wtyczkę do obrazów.

Jeśli obrazy obniżają Twoje Core Web Vitals, pierwszym przydatnym artefaktem jest krótki inwentarz: dotknięte szablony, źródło każdego obrazu oraz bieżący element LCP i jego czas w każdym szablonie. Dokładnie tę listę przechodzimy w ramach optymalizacji szybkości WordPressa.