Optymalizacja obrazów w WordPressie. Jak to zrobić?

Zasada jest prosta: im lepiej zoptymalizowane będą pliki graficzne, tym szybciej strona wyświetli się w pełnej okazałości na ekranie użytkownika. Ma to ogromne znaczenie, ponieważ każdy kolejny ułamek sekundy czekania, aż witryna się załaduje, zwiększa szanse, że użytkownik po prostu opuści stronę.

Na tym jednak nie koniec. Przypomnijmy tylko, że od 2021 roku Google uwzględnia Core Web Vitals, czyli wskaźniki opisujące wydajność strony, w swoim algorytmie rankingowym. Dwa z nich – LCP oraz CLS – są bardzo mocno uzależnione od konfiguracji obrazów. Do drugiego wrócimy na końcu artykułu, teraz zatrzymajmy się przy LCP.

Largest Contentful Paint mierzy czas od początku ładowania strony do momentu, w którym największy widoczny element witryny zostaje w pełni wyrenderowany. Łatwo się domyślić, że na większości stron tym elementem jest właśnie jakaś grafika – baner reklamowy, obrazek ilustrujący artykuł itp. Nawet jeśli cały interfejs strony wczyta się błyskawicznie, to wolno ładujący się obraz i tak podbije wartość LCP… tym samym obniżając szanse witryny na dobre pozycje w Google.

Co zatem można zrobić, aby zoptymalizować pliki graficzne na stronie? W pierwszej kolejności, jeśli cały czas korzystasz z JPEG i PNG, to zmienić ich format. Sam JPEG ma przecież swoje lata – powstał w 1992 roku i choć ma mnóstwo zalet, dziś po prostu istnieją lepsze opcje.

Obecnie standardem są formaty WebP i AVIF. Oba oferują kompresję lepszą od JPEG o kilkadziesiąt procent przy zachowaniu tej samej jakości, do tego obsługują przezroczystość – co wcześniej było domeną wyłącznie PNG – oraz znacznie lepiej radzą sobie z gradientami i szczegółami w cieniach.

Na pierwszy rzut oka AVIF jest co prawda lepszy od WebP, ale ma jedną wadę, oczywiście poza kwestią kompatybilności ze starszymi przeglądarkami. Otóż kodowanie plików w tym formacie wiąże się z o wiele większym obciążeniem serwera niż w przypadku WebP. Jeśli więc korzystasz z wtyczki, która konwertuje i kompresuje obrazy bezpośrednio na serwerze, może to być odczuwalne.

W przypadku WordPressa optymalizacja obrazów jest o tyle prosta, że do dyspozycji masz dziesiątki sprawdzonych pluginów pokroju Imagify czy Smush, które zrobią to za Ciebie. Na małej-średniej wielkości stronie nie ma w tym żadnego problemu, to świetna opcja – co innego, jeśli grafik do skompresowania jest kilka tysięcy.

Większość darmowych wtyczek do optymalizacji zdjęć WordPress działa na takiej zasadzie: przechwytują obraz w momencie wgrania na serwer, a następnie uruchamiają proces kompresji bezpośrednio w PHP… na tym samym serwerze, który obsługuje też ruch na stronie. Możesz wyobrazić sobie sklep na WooCommerce, do którego właśnie ktoś wgrał nową kolekcję 200 produktów. Każdy z nich ma 3-4 zdjęcia, które trzeba skompresować, przeskalować i zapisać w kilku rozmiarach miniatur; jeśli strona stoi na hostingu z raczej niższej półki cenowej, szansa, że ten się „zadławi”, nie jest wcale zerowa.

Dlatego też na większą skalę warto przemyśleć całą architekturę back-endu i wyjąć optymalizację obrazów poza główny wątek serwera. Można to zrobić:

• po stronie CDN-u – czyli zamiast serwować obrazy bezpośrednio z serwera, przesyłasz je przez sieć CDN (np. przez Cloudflare Images), która konwertuje i kompresuje je automatycznie na swoich węzłach brzegowych, jak najbliżej użytkownika;
• po stronie zewnętrznego serwisu, przez API – niektóre wtyczki, choćby wspomniane Imagify, działają właśnie w ten sposób, że wysyłają obraz do zewnętrznego serwera, a potem odbierają już zoptymalizowaną wersję i zapisują ją na Twoim hostingu.

Na początku pracy z WordPressem wiele osób nie wie, że gdy do biblioteki mediów WP trafia nowe zdjęcie, to CMS… automatycznie generuje dla niego miniatury w różnych rozmiarach. Więcej – niemal wszystkie motywy też tworzą kopie obrazów dostosowane do własnych szablonów, podobnie jest zresztą z niektórymi wtyczkami (np. WooCommerce generuje osobne miniatury dla kart produktów, strony produktu i koszyka).

Problem polega na tym, że większość stron przynajmniej z części tych miniatur w ogóle nie korzysta, więc zajmują niepotrzebnie miejsce na serwerze i zwiększają liczbę i-nodes.

Rozwiązanie jest dosyć proste, wystarczy dodać do pliku functions.php – koniecznie w motywie potomnym! – fragment kodu:

function remove_unnecessary_image_sizes( $sizes ) { unset( $sizes['zbędny rozmiar'] ); unset( $sizes['zbędny rozmiar'] ); unset( $sizes['zbędny rozmiar'] ); return $sizes; } add_filter( 'intermediate_image_sizes_advanced', 'remove_unnecessary_image_sizes' )

Oczywiście, zanim wyłączysz generowanie miniatur, koniecznie sprawdź w szablonach motywu oraz dokumentacji wtyczek, których używasz, jakie konkretnie rozmiary zdjęć one wywołują!

Przy okazji Core Web Vitals wspomnieliśmy o CLS, czyli Cumulative Layout Shift. Wskaźnik ten mierzy stabilność wizualną strony, czyli to, czy elementy „skaczą" podczas ładowania. Do przesunięć layoutu dochodzi najczęściej wtedy, gdy przeglądarka nie zna z góry wymiarów obrazka i musi je ustalić dopiero po jego pobraniu – pozostałe elementy interfejsu muszą zrobić miejsce dla tej grafiki, dlatego się przesuwają.

Aby tego uniknąć, każda grafika na stronie powinna mieć jawnie zdefiniowane atrybuty width oraz height.

<img src="zdjecie.avif" alt="Opis zdjęcia" width="1200" height="800" loading="”lazy”">

Od wersji 5.5 WordPress dodaje je automatycznie dla obrazków wstawianych przez edytor Gutenberg lub bibliotekę mediów; problemy mogą natomiast pojawić się przy grafikach umieszczonych ręcznie w szablonach PHP albo przez page buildery – wtedy musisz to zrobić samemu.

Z reguły nie trzeba się za to martwić o lazy loading – jak wyżej, WordPress sam dodaje atrybut loading="lazy" do wszystkich plików graficznych, tak aby przeglądarka wczytywała je dopiero, gdy użytkownik faktycznie do nich dotrze (a nie od razu przy pierwszym renderowaniu, wydłużając czas ładowania).

Jest tylko jeden wyjątek: grafika, która na danej stronie jest największym widocznym elementem po załadowaniu, nigdy nie powinna mieć atrybutu loading="lazy", bo odbije się to na wskaźniku LCP. Dla takich plików najlepiej dodać instrukcję z atrybutami loading="eager" oraz fetchpriority="high" – ten drugi to wskazówka dla przeglądarki, że dany zasób powinien być wczytany w pierwszej kolejności. I znów, od wersji 6.3 WordPress sam określa fetchpriority dla grafiki, którą rozpoznaje jako główny element strony… jednak warto to weryfikować w DevTools, bo mechanizm ten nie zawsze działa poprawnie, zwłaszcza z niestandardowymi motywami.