Konfiguracja WebP i AVIF

Najpierw sprawdź, co potrafi twój serwer

W sekcji „Obrazy” stoi karta „Możliwości tego serwera”. Pokazuje ona nie to, co stoi na papierze, lecz to, co zostało zmierzone na działającym PHP: biblioteka obrazów GD wraz z wersją, odczyt JPEG, odczyt PNG, odczyt WebP, zapis WebP, zapis AVIF. Pytanie zadawane jest przy tym podwójnie — funkcja musi istnieć i format musi stać w imagetypes(). To ważne, bo niektórzy hostingodawcy budują GD bez WebP albo AVIF: imagewebp() jest wtedy obecna i zawodzi dopiero przy wywołaniu.

Jeśli formatu brakuje, przynależny przełącznik pozostaje wprawdzie widoczny, ale jest wyłączony i nosi uzasadnienie. Dla WebP brzmi ono: GD musi być zbudowane z libwebp. Dla AVIF: PHP 8.1 albo nowsze z libavif. Jedno i drugie to sprawa hostingodawcy. Droga na skróty przez wywołanie AJAX nie pomoże — serwer wyraźnie odmawia włączenia niedostępnego formatu.

Wiersz „Imagick” to czysta informacja. Ten moduł nie używa Imagick; jeśli stoi tam „niedostępny”, nic ci nie brakuje.

Włącz i ustaw trzy liczby

Są trzy przełączniki i trzy pola liczbowe. „Twórz WebP” i „Twórz AVIF” są fabrycznie wyłączone, „Dostarczaj przez <picture>” jest włączone. Rozdzielenie jest zamierzone: możesz najpierw pozwolić plikom powstać, a dostarczanie dołączyć później. Odwrotnie obowiązuje: jeśli wyłączysz dostarczanie, pliki powstają nadal, ale do gości idzie niezmieniony kod HTML.

Jakość WebP stoi na 82, jakość AVIF na 50. Oba pola przyjmują wartości od 30 do 100, wszystko powyżej albo poniżej jest przycinane do tego zakresu. Różne wartości domyślne to nie przeoczenie: AVIF mierzy inaczej niż JPEG, 50 wygląda tam już bardzo czysto. Powyżej 90 plik WebP rośnie szybciej niż widoczny zysk.

Górna granica w megapikselach stoi na 40 i przyjmuje wartości od 4 do 400. Chroni ona przed limitem pamięci: zdjęcie 6000 × 4000 zajmuje przy dekodowaniu około 96 MB, niezależnie od tego, jak duży jest jego plik. Dodatkowo Kakapo przed każdym dekodowaniem przelicza to względem faktycznie jeszcze wolnej pamięci i pomija plik, zamiast pozwolić wgrywaniu umrzeć na limicie.

Jeśli zmienisz jeden z trzech przełączników, odłożony cache stron zostanie odrzucony. Jakość i granica megapikseli pozostawiają go — działają dopiero przy następnym wgraniu i nie czynią błędną żadnej już odłożonej strony.

Co dzieje się przy wgrywaniu

Konwersja działa na końcu wgrywania, gdy tylko WordPress utworzy wszystkie rozmiary obrazu. Przetwarzane są plik z metadanych i każdy utworzony rozmiar — nie zachowany przez rdzeń oryginał, który i tak nigdy nie jest dostarczany.

Każdy plik pochodny leży jako plik towarzyszący obok swojego pliku źródłowego i nosi jego pełną nazwę plus rozszerzenie: z bild.jpg powstaje bild.jpg.webp, a nie bild.webp. Powód: w tym samym folderze mogą leżeć obok siebie bild.jpg i bild.png; przy zwykłej zamianie rozszerzenia jeden plik pochodny zabiłby drugi. Jeśli w miejscu docelowym już coś leży, nie jest to ruszane.

Zapis następuje najpierw do pliku pobocznego z numerem procesu i losową częścią w nazwie. Dopiero gdy po zmierzeniu jest mniejszy niż plik źródłowy, przesuwa się przez rename na swoje miejsce. Jeśli jest większy albo tak samo duży, zostaje usunięty i pozostaje plik źródłowy. Przerwany przebieg nigdy nie zostawia dlatego zbyt dużego pliku pochodnego.

Wgrywanie ma budżet czasu 12 sekund. AVIF jest przy tworzeniu wielokrotnie wolniejszy niż WebP, a sześć rozmiarów razy dwa formaty wpadłoby inaczej w czas wykonania serwera WWW — prowadzący witrynę zobaczyłby przerwane wgrywanie. To, co się już nie mieści, nadrabia jednorazowy przebieg dodatkowy: jest planowany 30 sekund później i ma wtedy 90 sekund czasu. Zarówno załatwione, jak i pominięte jest odnotowywane przy załączniku, żeby ta sama próba nie powtarzała się przy każdym ponownym tworzeniu.

Przy plikach JPEG obrót z EXIF jest odtwarzany, ponieważ WebP i AVIF z GD nie przenoszą tej informacji. Przy plikach źródłowych PNG Kakapo próbuje najpierw WebP bezstratnie — logo, grafiki i zrzuty ekranu robią się dzięki temu często mniejsze, a krawędzie się nie strzępią. Przezroczystość zostaje zachowana w obu formatach docelowych.

Jak przebiega dostarczanie

Kakapo ujmuje <img> w <picture> i stawia przed nim źródła AVIF i WebP, najpierw AVIF — przeglądarka bierze pierwsze źródło, które rozumie. <picture> dostaje display:contents, żeby w układach flex i grid twojego motywu nie wsuwało w rozmieszczenie dodatkowego pudełka.

Świadomie wybrane przeciw alternatywie przez .htaccess: negocjacja treści potrzebuje reguł Apache, na nginx nie działa w ogóle i koliduje z pamięciami pośrednimi CDN, które nie różnicują nagłówka Accept. O <picture> decyduje przeglądarka, bez jednej linijki konfiguracji serwera.

Sięgane jest po treści wpisów i obrazki wyróżniające, z priorytetem 22 — po Lazy-Load (20), przed przepisaniem na CDN (25), żeby także nowo powstałe źródła szły przez CDN. Już istniejące bloki <picture> pozostają nietknięte, tak samo obrazy z obcych hostów i wszystko poza folderem uploads.

Jedną regułę warto znać: format jest oferowany tylko wtedy, gdy największa wersja w srcset istnieje jako plik pochodny. Jeśli brakuje średniej albo małej, przeglądarka sięga po następną większą — kilka kilobajtów więcej, ale nigdy nieostry obraz. Gdyby brakowało największej, szeroki ekran nie mógłby już dojść do pełnej rozdzielczości; właśnie ten przypadek jest wykluczony.

Gdy nic nie powstaje: odczytaj powody

Karta „Utworzone pliki & rzeczywista oszczędność” pokazuje dla każdego formatu liczbę plików, sumę plików źródłowych, sumę plików pochodnych i różnicę. Każda liczba pochodzi z porównania dwóch faktycznych rozmiarów plików w momencie tworzenia — nic nie jest szacowane ani ekstrapolowane. „Pliki źródłowe” to przy tym tylko suma plików, do których powstał plik pochodny, a nie cały twój zasób mediów.

Poniżej stoi, co nie zostało przekonwertowane, wraz z powodem. Najważniejsze:

„Wynik był większy niż plik źródłowy” — to nie błąd. Przy bardzo małych miniaturach zdarza się to z AVIF regularnie; plik źródłowy pozostaje, a pozostałe rozmiary i tak dostają swój plik pochodny.

„Nie da się zapisać” — sprawdzić uprawnienia w folderze uploads. To jedyny powód, który naprawdę wymaga twojego udziału.

„W miejscu docelowym leżał już plik” — nie został nadpisany. Zwykle pochodzi on z przebiegu zbiorczego po istniejących zasobach i jest już dokładnie tym, co miało tu powstać.

„Nie zmieściło się w pamięci” — podnieść granicę megapikseli albo limit pamięci PHP.

„Nie da się odczytać” — uszkodzony plik, JPEG w CMYK albo egzotyczna odmiana. „To nie JPEG/PNG/WebP” — animacje GIF i pliki PDF świadomie nie są ruszane.

Jeśli karta stoi pusta, włącz WebP i wgraj obraz. Obrazów, które już leżą w bibliotece mediów, tą drogą nie osiągniesz — służy do tego przebieg zbiorczy niżej na tej samej stronie.