WebP und AVIF einrichten
Zuerst nachsehen, was dein Server kann
Im Bereich „Bilder" steht die Karte „Fähigkeiten dieses Servers". Sie zeigt nicht, was auf dem Papier steht, sondern was am laufenden PHP gemessen wurde: GD-Bildbibliothek samt Version, JPEG lesen, PNG lesen, WebP lesen, WebP schreiben, AVIF schreiben. Gefragt wird dabei doppelt — die Funktion muss existieren und das Format muss in imagetypes() stehen. Das ist wichtig, weil manche Hoster GD ohne WebP oder AVIF bauen: imagewebp() ist dann vorhanden und scheitert erst beim Aufruf.
Fehlt ein Format, bleibt der zugehörige Schalter zwar sichtbar, ist aber abgeschaltet und trägt die Begründung. Für WebP heißt sie: GD muss mit libwebp gebaut sein. Für AVIF: PHP 8.1 oder neuer mit libavif. Beides ist Sache deines Hosters. Ein Umweg über den AJAX-Aufruf hilft nicht — der Server lehnt das Einschalten eines nicht verfügbaren Formats ausdrücklich ab.
Die Zeile „Imagick" ist reine Information. Dieses Modul benutzt Imagick nicht; steht dort „nicht vorhanden", fehlt dir nichts.
Einschalten und die drei Zahlen setzen
Es gibt drei Schalter und drei Zahlenfelder. „WebP erzeugen" und „AVIF erzeugen" sind ab Werk aus, „Über <picture> ausliefern" ist an. Die Trennung ist Absicht: Du kannst die Dateien erst einmal entstehen lassen und die Auslieferung später zuschalten. Umgekehrt gilt: Schaltest du die Auslieferung ab, entstehen die Dateien weiterhin, an die Besucher geht aber unverändertes Markup.
WebP-Qualität steht auf 82, AVIF-Qualität auf 50. Beide Felder nehmen Werte von 30 bis 100 an, alles darüber oder darunter wird auf den Bereich gestutzt. Die unterschiedlichen Vorgaben sind kein Versehen: AVIF misst anders als JPEG, 50 sieht dort bereits sehr sauber aus. Über 90 wächst bei WebP die Datei schneller als der sichtbare Gewinn.
Die Obergrenze in Megapixeln steht auf 40 und nimmt Werte von 4 bis 400. Sie schützt vor dem Speicherlimit: Ein 6000 × 4000-Foto belegt beim Decodieren rund 96 MB, unabhängig davon, wie groß seine Datei ist. Zusätzlich rechnet Kakapo vor jedem Decodieren gegen den tatsächlich noch freien Speicher und überspringt, statt den Upload am Limit sterben zu lassen.
Änderst du einen der drei Schalter, wird der abgelegte Seiten-Cache verworfen. Qualität und Megapixel-Grenze lassen ihn stehen — sie wirken erst beim nächsten Upload und machen keine bereits abgelegte Seite falsch.
Was beim Hochladen passiert
Die Umwandlung läuft am Ende des Uploads, sobald WordPress alle Bildgrößen erzeugt hat. Bearbeitet werden die Datei aus den Metadaten und jede erzeugte Größe — nicht das vom Kern aufbewahrte Original, das ohnehin nie ausgeliefert wird.
Jede Ableitung liegt als Begleitdatei neben ihrer Vorlage und trägt deren vollen Namen plus Endung: aus bild.jpg wird bild.jpg.webp, nicht bild.webp. Grund: Im selben Ordner dürfen bild.jpg und bild.png nebeneinander liegen; beim bloßen Ersetzen der Endung schriebe die eine Ableitung die andere tot. Liegt am Zielort schon etwas, wird es nicht angefasst.
Geschrieben wird zuerst in eine Nebendatei mit Prozessnummer und Zufall im Namen. Erst wenn sie nachgemessen kleiner ist als die Vorlage, rückt sie per rename an ihren Platz. Ist sie größer oder gleich groß, wird sie gelöscht und es bleibt bei der Vorlage. Ein abgebrochener Lauf hinterlässt deshalb nie eine zu große Ableitung.
Der Upload hat ein Zeitbudget von 12 Sekunden. AVIF ist beim Erzeugen um ein Vielfaches langsamer als WebP, und sechs Größen mal zwei Formate laufen sonst in die Ausführungszeit des Webservers — der Betreiber sähe einen abgebrochenen Upload. Was nicht mehr hineinpasst, holt ein einmaliger Nachlauf: Er wird 30 Sekunden später eingeplant und hat dann 90 Sekunden Zeit. Erledigtes wie Übersprungenes wird am Anhang vermerkt, damit derselbe Versuch nicht bei jeder Neuerzeugung wiederholt wird.
Bei JPEGs wird eine EXIF-Drehung nachgezogen, weil WebP und AVIF aus GD diese Angabe nicht mittragen. Bei PNG-Vorlagen probiert Kakapo WebP zuerst verlustfrei — Logos, Grafiken und Screenshots werden so oft kleiner, ohne dass Kanten ausfransen. Transparenz bleibt in beiden Zielformaten erhalten.
Wie ausgeliefert wird
Kakapo fasst das <img> in ein <picture> und stellt AVIF- und WebP-Quellen davor, AVIF zuerst — der Browser nimmt die erste Quelle, die er versteht. Das <picture> bekommt display:contents, damit es in Flex- und Grid-Layouts deines Themes keinen zusätzlichen Kasten in die Anordnung schiebt.
Bewusst gewählt gegen die Alternative über .htaccess: Content-Negotiation braucht Apache-Regeln, wirkt auf nginx gar nicht und kollidiert mit CDN-Zwischenspeichern, die den Accept-Header nicht variieren. <picture> entscheidet der Browser, ohne eine Zeile Server-Konfiguration.
Gegriffen wird auf Beitragsinhalte und Beitragsbilder, mit Priorität 22 — nach dem Lazy-Load (20), vor der CDN-Umschreibung (25), damit auch die neu entstandenen Quellen über das CDN laufen. Bereits vorhandene <picture>-Blöcke bleiben unangetastet, ebenso Bilder von fremden Hosts und alles außerhalb des Uploads-Ordners.
Eine Regel lohnt sich zu kennen: Angeboten wird ein Format nur, wenn die größte Fassung im srcset als Ableitung vorliegt. Fehlt eine mittlere oder kleine, greift der Browser zur nächstgrößeren — ein paar Kilobyte mehr, aber nie ein unscharfes Bild. Fehlte die größte, könnte ein breiter Bildschirm nicht mehr auf die volle Auflösung kommen; genau dieser Fall wird ausgeschlossen.
Wenn nichts entsteht: die Gründe lesen
Die Karte „Erzeugte Dateien & echte Ersparnis" zeigt je Format die Zahl der Dateien, die Summe der Vorlagen, die Summe der Ableitungen und die Differenz. Jede Zahl stammt aus dem Vergleich zweier tatsächlicher Dateigrößen im Moment der Erzeugung — nichts ist geschätzt oder hochgerechnet. „Vorlagen" ist dabei nur die Summe der Dateien, zu denen eine Ableitung entstanden ist, nicht dein gesamter Medienbestand.
Darunter steht, was nicht umgewandelt wurde, mit Grund. Die wichtigsten:
„Ergebnis war größer als die Vorlage" — kein Fehler. Bei sehr kleinen Miniaturen passiert das mit AVIF regelmäßig; die Vorlage bleibt und die übrigen Größen bekommen ihre Ableitung trotzdem.
„Nicht schreibbar" — die Rechte im Uploads-Ordner prüfen. Das ist der einzige Grund, der wirklich nach dir verlangt.
„Am Zielort lag bereits eine Datei" — sie wurde nicht überschrieben. Meist stammt sie aus dem Stapellauf über den Bestand und ist bereits genau das, was hier entstehen sollte.
„Nicht in den Speicher gepasst" — Megapixel-Grenze oder PHP-Speicherlimit anheben.
„Nicht lesbar" — defekte Datei, CMYK-JPEG oder eine exotische Variante. „Kein JPEG/PNG/WebP" — GIF-Animationen und PDFs werden bewusst nicht angefasst.
Steht die Karte leer, schalte WebP ein und lade ein Bild hoch. Bilder, die schon in der Mediathek liegen, erreichst du nicht darüber, sondern über den Stapellauf weiter unten auf derselben Seite.