Moderne Bildoptimierung für WordPress im Jahr 2026

AVIF wird von 96,35 % der Browsernutzung akzeptiert, die caniuse erfasst (Stand 12. Oktober 2026). Das Medienkapitel des Web Almanac 2024 fand es bei 1,0 % der Bilder auf Mobilgeräten. Diese Lücke von mehr als 95 Punkten erklären nicht die Browser. Sie erklärt sich aus dem Upload-Pfad, aus dem Markup, das den Kandidaten auswählt, und aus dem Moment, in dem der Browser überhaupt erfährt, dass das Bild existiert.

Deshalb beginnt dieser Leitfaden nicht mit der Formattabelle. Er beginnt mit der Diagnose, geht über den Upload und endet bei der Auslieferung, denn in dieser Reihenfolge gehen die Dinge auf einer Website kaputt, die bereits in Produktion läuft.

Die drei Ebenen, auf denen Arbeit verloren geht, in der Reihenfolge, in der ein Bild sie durchläuft:

• Upload: welches Format und welche maximale Breite der Server überhaupt erzeugt.
• Markup: welchen Kandidaten aus dem srcset der Browser am Ende wählt.
• Entdeckung: wann der Browser erfährt, dass das Bild existiert.

#Wie man das LCP-Element in WordPress findet

Bevor Sie irgendetwas konvertieren, bestätigen Sie mit Felddaten und nicht mit einer Vermutung, welches Element in jedem Template der Largest Contentful Paint ist. Der Web Almanac 2024 hat gemessen, dass dieses Element auf 68 % der mobilen Seiten ein Bild ist, mit einem Median von 135 KB für das größte Bild. Umgekehrt gelesen: Bei den übrigen 32 % ist der LCP Text, und dort bewegt ein AVIF-Durchlauf die Metrik um keine Millisekunde.

Es gibt zwei Fälle, in denen der WordPress-Core nicht hilft, selbst wenn der LCP ein Bild ist:

1. Das LCP-Element ist kein img-Tag, das der Core gerendert hat. Ein CSS-Hintergrund, das Poster eines video oder ein Page Builder, der sein Markup außerhalb von wp_filter_content_tags() schreibt. Der Core priorisiert nicht, was er nicht sieht, also kommt das Hero-Bild nach dem Stylesheet an, das darauf verweist.
2. Das LCP-Element wechselt je nach Breakpoint. Das Kopfbild auf dem Desktop und die Karte auf dem Smartphone sind verschiedene Elemente. Eine statische Annahme trifft eines von beiden.

Für diese beiden Fälle gibt es Image Prioritizer, das Optimization Detective voraussetzt. Optimization Detective sammelt URL Metrics von echten Besuchern je Breakpoint und weiß deshalb, welches Element der LCP war, statt es aus der Dokumentreihenfolge abzuleiten. Mit diesen Daten fügt Image Prioritizer einen Preload mit hoher Priorität für das LCP-Bild ein, als LINK-Element im HTML und als HTTP-Header Link, und der Preload deckt auch CSS-Hintergründe (inline oder aus einem Stylesheet) und Video-Poster ab. Es setzt fetchpriority=high auf ein img nur dann, wenn dieses Element an allen Breakpoints der LCP ist, setzt fetchpriority=low auf Bilder im initialen Viewport, die verborgen sind (die Folien zwei und drei eines Karussells, der Klassiker), und lädt Hintergründe aus Inline-style-Attributen verzögert. Es hat keine Einstellungsseite und greift erst, wenn Besuchermetriken gesammelt wurden.

Beide Plugins stammen vom Performance-Team des Core, demselben Team, das auf make.wordpress.org/performance veröffentlicht. Es sind keine Werkzeuge von Drittanbietern, sondern das Labor für Funktionen, die später in WordPress landen. Was Sie heute als Plugin installieren, zeigt also die offizielle Richtung des Projekts.

#Wie man AVIF in WordPress aktiviert

WordPress 6.5 hat AVIF-Unterstützung hinzugefügt, im Februar 2024, angekündigt von Adam Silverstein. Seitdem lassen sich .avif-Dateien ohne Plugin hochladen und ausliefern wie ein JPEG, sofern der Imagick- oder LibGD-Build des Servers AVIF kodieren kann. Diese Bedingung hat eine eigene Ansicht im Backend: Werkzeuge > Website-Zustand > Bericht > Medienverarbeitung.

An dieser Stelle lohnt der Schritt von der Theorie zum echten Hosting. Auf Shared Hosting (IONOS, Strato, All-Inkl und vergleichbare Tarife) wählen Sie den ImageMagick-Build nicht aus, Sie erben ihn. Die PHP-Version im Kundenmenü sagt nichts über die Imagick-Delegates, und ein Wechsel zwischen Tarifen desselben Anbieters kann sie ändern. Öffnen Sie den Website-Zustand nach jedem Umzug und nach jedem größeren Server-Update und behandeln Sie das Ergebnis als Projektdatum, nicht als einmalige Prüfung. Ein Theme, das AVIF auf einem Server ohne Unterstützung voraussetzt, erzeugt nichts und warnt auch nicht.

Zweitens: Der Core konvertiert nichts von sich aus. Ein hochgeladenes JPEG bleibt ein JPEG, und seine Zwischengrößen bleiben JPEG. Das ändert der Hook image_editor_output_format, verfügbar seit WordPress 5.8, der einem Quell-MIME-Typ einen Ausgabe-MIME-Typ zuordnet:

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

Drei Folgen, bevor Sie diesen Filter ausrollen:

• Die Originaldatei bleibt unverändert. Nur die erzeugten Zwischengrößen übernehmen das neue Format, und genau das hält die Mediathek weiter bearbeitbar.
• Er gilt nur für künftige Uploads. Bestehende Medien brauchen einen Regenerierungslauf.
• Sein Standardwert ist nicht mehr leer. Seit WordPress 6.7 enthält der Core in diesem Filter die Zuordnungen von HEIC und HEIF zu JPEG. Geben Sie also das Array zurück, das Sie erhalten haben, statt ein neues zu bauen. Wer 2023 return array( 'image/jpeg' => 'image/avif' ); geschrieben hat, schaltet heute unbemerkt die Konvertierung von iPhone-Fotos ab.

Die andere Core-Einstellung, die jeden Upload prägt, ist big_image_size_threshold, 2560 Pixel seit WordPress 5.3. Jedes breitere oder höhere Bild wird verkleinert, und die verkleinerte Kopie wird zur größten verfügbaren Größe. PNG-Uploads sind von dieser Skalierung ausgenommen. Ist Ihr Hero-Bereich tatsächlich breiter als 2560 Pixel, liefern Sie bereits ein hochskaliertes Bild aus, und keine Formatarbeit behebt diese Unschärfe.

#Wie lange die AVIF-Kodierung dauert

Die Transformationsdokumentation von Cloudflare sagt, dass AVIF-Kodierung um eine Größenordnung langsamer sein kann als die Kodierung in andere Formate, und dass Cloudflare auf WebP oder JPEG ausweicht, wenn ein Bild zu groß ist, um schnell kodiert zu werden. Dieselbe Rechnung gilt auf Ihrem Ursprungsserver, erst recht in einem Shared-Tarif mit Prozesslimit. Eine Mediathek mit 40.000 Elementen am Stück zu konvertieren ist ein Batch-Job mit Warteschlange und Zeitfenster, kein Klick in einer Einstellungsseite.

#Wie man Thumbnails mit WP-CLI neu erzeugt

Der Filter erreicht nur neue Uploads, also braucht eine bestehende Mediathek einen eigenen Durchlauf. wp media regenerate geht die Anhänge durch und erzeugt die Zwischengrößen mit der aktuellen Konfiguration neu, einschließlich des Ausgabeformats, das Sie gerade gesetzt haben. Zwei Flags ersparen den Großteil des Ärgers: --only-missing, damit ein abgebrochener Lauf nicht wiederholt, was schon fertig ist, und --image_size, um den Lauf auf eine Größe zu begrenzen, wenn sich nur diese geändert hat.

wp media regenerate --only-missing --yes

Begrenzen Sie die Ausführung, nicht nur den Befehl. Auf Shared Hosting konkurriert eine Regenerierung über Zehntausende Anhänge um dieselbe CPU, die den echten Traffic bedient, und AVIF ist das Format, das am meisten davon verlangt. Teilen Sie die Mediathek in ID-Bereiche, laufen Sie außerhalb der Stoßzeiten und behalten Sie das Log: Die Liste der fehlgeschlagenen Anhänge ist das Inventar beschädigter Originale, das seit Jahren niemand angesehen hat.

Überzeugt das Ergebnis nicht, ist der Ausweg ein erneuter Lauf mit einer anderen Qualitätseinstellung, nicht das Zurückspielen eines Backups. Das Original wurde nie angefasst.

#Welche Kompressionsqualität man in WordPress einstellt

WP_Image_Editor::$default_quality beträgt 82 und ist seit WordPress 5.8.1 zugunsten von get_default_quality() veraltet, das 86 für WebP und dieselben 82 für JPEG und alles andere zurückgibt. JPEG läuft danach durch den Filter jpeg_quality, der nach wp_editor_set_quality ausgeführt wird und deshalb das letzte Wort hat.

Die beiden Filter erhalten unterschiedliche Argumente, und wer sie verwechselt, bekommt eine Regel für ein Format, die plötzlich für alle gilt. wp_editor_set_quality erhält die Standardqualität, den MIME-Typ und seit WordPress 6.8 die Abmessungen, erlaubt also eine Qualität je Format und je Größe. jpeg_quality erhält nur die Qualität und einen Kontext-String wie image_resize. Ein Fotoportfolio und eine Bibliothek mit Interface-Screenshots wollen nicht dieselbe Zahl.

Wichtig ist auch, wie jedes Format bei zu niedrigem Wert versagt. JPEG versagt sichtbar, mit Blöcken und Säumen, die man selbst im Thumbnail erkennt. AVIF glättet bei niedriger Qualität feine Texturen: Korn, Stoff, Laub und Haare verlieren Details, während die Kanten sauber bleiben. Dieser Fehler ist in kleiner Darstellung viel schwerer zu sehen, also muss die Prüfung in voller Auflösung und auf dem echten Template stattfinden, nicht im Raster der Mediathek.

Und eine Warnung zu den Zahlen. Die Idee, ein Encoder erkenne ein Gesicht, komprimiere den Himmel aggressiv und liefere eine konkrete Ersparnis von 70 %, kursiert ohne Quelle. Behandeln Sie jede solche Zahl als unbelegt, bis Sie sie an Ihrer eigenen Mediathek gemessen haben. Ein Plugin-Dashboard, das einen eingesparten Prozentsatz meldet, berichtet über Dateien auf der Festplatte, nicht über das, was der Browser herunterlud, nachdem die Edge das Format ausgehandelt hat. Es zählen nur zwei Messungen: die ausgelieferten Bytes der LCP-Ressource und das visuelle Ergebnis auf dem Template, in dem das Bild erscheint.

Die praktische Prüfung dauert zwanzig Minuten. Legen Sie eine kleine, feste Auswahl repräsentativer Bilder aus Ihrer echten Mediathek fest (ein Gesicht, ein Produkt auf Weiß, ein Screenshot mit kleiner Schrift und eine breite Landschaft), kodieren Sie sie mit jeder Kandidateneinstellung und betrachten Sie das Ergebnis in voller Größe. Das verhindert einen globalen Wert, der die Produktfotografie zerstört.

#Wie man srcset und sizes in WordPress verwendet

Ein effizientes Format in der falschen Abmessung ruiniert den LCP trotzdem. Hat der Hero auf dem Smartphone 390 px CSS-Breite und zeigt src auf eine Datei mit 2000 px, lädt der Browser Megabytes zu viel, selbst in AVIF.

WordPress registriert Größen mit add_image_size(), und beim Rendern baut wp_get_attachment_image_srcset() die Kandidatenliste. Das Attribut sizes teilt dem Browser mit, welche CSS-Breite je Breakpoint zu erwarten ist. Ohne realistisches sizes (zum Beispiel (max-width: 768px) 100vw, 720px) kann der Browser einen zu großen Kandidaten wählen.

Kurze Checkliste:

• Registrieren Sie nur die Größen, die das Theme tatsächlich verwendet (keine Dutzende toter Zuschnitte).
• Regenerieren Sie die Thumbnails nach jeder Änderung (wp media regenerate, siehe oben).
• Prüfen Sie beim Hero im Network-Tab der DevTools die gewählte Dateibreite, nicht nur den Content-Type.
• Halten Sie Bilder in Gutenberg-Blöcken an der Content-Breite des Themes ausgerichtet; Uploads mit 5000 px “weil wir später zuschneiden” erhöhen Speicherbedarf und Erzeugungszeit.

Nützliche Dokumentation: Die Referenz zu wp_get_attachment_image_srcset im Developer Handbook und das Bildmaterial auf web.dev erklären dieselbe Idee von zwei Seiten (CMS und Browser).

#Fetchpriority und sizes auto in WordPress 6.3 und 6.7

Der Rat, loading="eager" und fetchpriority="high" von Hand zu setzen, ist für Inhaltsbilder seit drei Jahren überholt. WordPress 6.3 hat wp_get_loading_optimization_attributes() eingeführt, die beide Attribute für Bilder berechnet, die durch den Rendering-Pfad des Core laufen:

• Das erste Bild, das die Schwelle erfüllt, erhält fetchpriority="high". Erfüllen heißt eine Mindestfläche von 50.000 Pixeln, Breite mal Höhe, einstellbar über den Filter wp_min_priority_img_pixels.
• loading="lazy" entfällt bei Bildern nahe am Dokumentanfang. Der Schwellenfilter heißt wp_omit_loading_attr_threshold, sein Standardwert stieg in 6.3 von 1 auf 3.
• Die Funktion gibt fetchpriority="high" und loading="lazy" nie zusammen aus, weil sich die Anweisungen widersprechen.

WordPress 6.7 hat danach sizes="auto" ergänzt, für verzögert geladene Bilder über wp_img_tag_add_auto_sizes(). Das behebt den ältesten srcset-Fehler in WordPress: Das erzeugte sizes-Attribut nahm an, das Bild fülle den ganzen Viewport, also konnte ein Sidebar-Thumbnail mit 300 Pixeln auf dem Smartphone einen 1024er-Kandidaten ziehen. Da ein Lazy-Bild erst lädt, wenn das Layout feststeht, kann der Browser jetzt die tatsächliche Breite verwenden. Der Core stellt auto nur voran, wenn das Bild bereits loading="lazy" trägt, und bindet eine kleine CSS-Regel ein (wp_enqueue_img_auto_sizes_contain_css_fix()), um einen Nebeneffekt im Layout zu vermeiden.

Die Lehre aus beiden Versionen: Priorität und Breite sind keine Theme-Entscheidung mehr. Erzwingt Ihr Template diese Attribute noch von Hand, kämpft es wahrscheinlich gegen den Core statt mit dem Browser.

#Wie man AVIF mit JPEG-Fallback ausliefert

Der Core schreibt ein einziges src und ein srcset. Er schreibt kein <picture>, kann also aus demselben Markup heraus nicht AVIF an Browser liefern, die es akzeptieren, und JPEG an die übrigen. Sie erhalten ein Format pro erzeugter Größe. Es gibt zwei brauchbare Antworten, und praktisch schließen sie sich gegenseitig aus.

Content Negotiation an der Edge oder auf dem Server. Das CDN liest den Accept-Header und liefert AVIF, WebP oder JPEG unter einer URL aus. Das HTML bleibt einfach. Der Preis: Das Caching hängt dann von Request-Headern ab, also müssen die Cache-Schlüssel das berücksichtigen, und eine nachlässige Konfiguration liefert AVIF an einen Client, der es nicht akzeptiert.

Fallback im Markup. Das Plugin Modern Image Formats, Teil des Performance Lab-Programms, erzeugt beim Upload Zwischengrößen in modernen Formaten und kann seit Version 2.0.0 <picture>-Elemente mit Fallbacks ausgeben. Standardmäßig wählt es AVIF, wenn der Server es unterstützt, sonst WebP, und das ist der richtige Standard für ein Plugin, das Ihre Infrastruktur nicht kennt. Die Einstellungen liegen unter Einstellungen > Medien. Wie der Core-Filter gilt es für neue Uploads.

Und behalten Sie das JPEG. Außerhalb des Browsers ist es weiterhin das sichere Format für E-Mail-Clients, Open-Graph-Bilder, Social Cards, RSS-Reader und jeden Feed, den ein Partner abruft. Modern Image Formats behält die hochgeladene Originaldatei, erzeugt Zwischengrößen von JPEG und PNG standardmäßig aber nur im modernen Format. Braucht ein Feed oder eine Social Card JPEG-Zwischengrößen, aktivieren Sie die Option Output fallback images unter Einstellungen > Medien: Dann erzeugt das Plugin das Originalformat neben dem modernen in jeder Größe, auf Kosten von Speicherplatz und Zeit pro Upload.

#Wie man WordPress-Bilder mit Cloudflare skaliert

Transformation an der Edge nimmt Skalierung und Formatverhandlung vom PHP-Ursprung weg, ein starkes Argument, wenn der Ursprung ein Shared-Tarif ist. Bei Cloudflare bedeutet das eine URL der Form https://<ZONE>/cdn-cgi/image/<OPTIONEN>/<QUELLBILD>, wobei die Quelle ein absoluter Pfad auf dem Server oder eine absolute URL ist und die Optionen durch Kommas getrennt werden. Entscheidend ist hier format=auto, das das effizienteste Format liefert, das der anfragende Client akzeptiert.

Drei Punkte aus der Dokumentation, die die Planung ändern:

• Die Funktion muss pro Zone im Dashboard aktiviert werden, bevor irgendeine Transformations-URL auf diesem Host auflöst. Das ist der häufigste Grund, warum eine korrekt geschriebene URL das unskalierte Original zurückgibt.
• Quellbilder sind standardmäßig auf dieselbe Zone beschränkt. Erlaubte Quellen ergeben sich aus einer Liste, die Cloudflare getrennt vom URL-Format dokumentiert: Eine eigene Medien-Subdomain oder ein S3-Bucket muss in diese Liste, oder die Zone wird für beliebige Quellen geöffnet.
• format=auto kann AVIF ablehnen. Wegen der bereits genannten Kodierkosten weicht Cloudflare auf WebP oder JPEG aus, wenn ein Bild zu groß ist, um schnell kodiert zu werden. Ihr Hero kann im Test AVIF sein und in Produktion WebP, abhängig von den Abmessungen der Quelle, und dieser Unterschied taucht in keinem Plugin-Bericht auf.

Die Edge ersetzt keine korrekten srcset- und sizes-Angaben (wie WordPress sie aus add_image_size() aufbaut, erklären wir im Leitfaden zu TimThumb und nativer Bildverarbeitung). Der Browser wählt den Kandidaten, bevor er die Anfrage stellt, also fordert falsches Markup eine falsche Breite an, und die Edge erzeugt gehorsam genau diese falsche Breite. Die Edge ersetzt den festen Größensatz von WordPress durch beliebige Breiten, nicht die Auswahllogik.

#Welche Browser JPEG XL im Jahr 2026 unterstützen

Hier liegen die meisten Leitfäden von 2026 falsch, die frühere Fassung dieses Textes eingeschlossen. JPEG XL kommt in der Auslieferung gerade erst an.

Die einzige echte Änderung kam am 6. Oktober 2026. Googles Ankündigung lautet: “Chrome liefert ab Chrome 155 Decodierungsunterstützung für das Bildformat JPEG XL (.jxl) aus” (Chrome for Developers, eigene Übersetzung). Nutzer von Chrome auf dem Desktop erhalten sie, sobald sich ihr Browser in den folgenden Wochen aktualisiert. Edge, das auf derselben Engine läuft, ist noch nicht gefolgt.

Caniuse meldet 16,95 % globale Unterstützung für JPEG XL, Stand 12. Oktober 2026, gegenüber 15,02 % bei der ersten Fassung dieses Abschnitts, und fast die gesamte Zahl ist Teilunterstützung. Der tatsächliche Stand, Browser für Browser:

Der Web Almanac hat die Nutzung von JPEG XL 2024 gar nicht gemessen und den Grund genannt: Chromium-basierte Browser unterstützten das Format nicht. Das ist ein ehrlicheres Signal als jede Adoptionskurve, denn der Datensatz, der das gesamte Web misst, hat es nicht als Auslieferungsformat betrachtet. Chrome 155 ändert die Eingangsdaten der nächsten Ausgabe, nicht das Fazit für eine Website, die diesen Monat live geht. Die letzte Tabellenzeile entscheidet die Frage überall dort, wo der mobile Traffic überwiegend von Android kommt.

Was das in der Praxis bedeutet:

• Als Archiv- oder Masterformat ist JPEG XL wirklich gut. Die verlustfreie Transkodierung von und zu JPEG ist eine echte Funktion und ein echter Grund, Master in JXL zu speichern. Das ist eine Speicherentscheidung, keine Auslieferungsentscheidung, und sie berührt Ihr srcset nicht.
• Wenn Sie es ausliefern, muss es als erstes <source type="image/jxl"> in einem <picture> stehen, mit einer AVIF-Quelle und einem JPEG-Fallback dahinter. Die große Mehrheit Ihrer Besucher nimmt ohnehin einen der Fallbacks, also erspart Ihnen der JXL-Zweig nicht den Bau des Rests.
• Nutzen Sie es nicht als Argument, AVIF aufzuschieben. AVIF ist das Format mit heute 96,35 % Unterstützung.

Kann Ihr Hosting kein AVIF kodieren, ist die Antwort nicht, auf JPEG XL zu warten, sondern WebP, über image_editor_output_format oder die Einstellung von Modern Image Formats. WebP-Unterstützung ist in älteren Imagick- und LibGD-Builds viel weiter verbreitet, und der Abstand zwischen JPEG und WebP ist deutlich größer als der zwischen WebP und AVIF.

#Wie man Bilder in WordPress Schritt für Schritt optimiert

Ein Ablauf, der skaliert, ohne im Betrieb Chaos zu erzeugen:

1. Upload: Masterfoto in sRGB, maximale Breite passend zum größten Breakpoint des Themes (zum Beispiel 1920 oder 2560 px, nicht 8000 px aus der Kamera; der Core verkleinert ohnehin alles über 2560 px).
2. Erzeugung: Der Core erzeugt Zwischengrößen im Format des Uploads; image_editor_output_format, Modern Image Formats oder das CDN liefern AVIF oder WebP.
3. Rendering: wp_get_attachment_image() (oder der Bild-Block) mit korrekten srcset/sizes.
4. Hero: Lassen Sie den Core fetchpriority="high" setzen und Lazy Loading weglassen; einen Preload nur dann, wenn der Hero ein Hintergrund ist oder außerhalb des Core-Markups liegt.
5. Der Rest: lazy, kein Preload.
6. Überwachung: PageSpeed/CrUX auf der echten URL, gefiltert nach “LCP element” und Bildgewicht.

Auf Shared Hosting ohne AVIF in Imagick ist die Konvertierung an der CDN-Edge oft günstiger als ein Serverwechsel wegen eines einzigen Codecs.

#Häufige Fehler bei der Bildoptimierung in WordPress

• PNG für Fotos. PNG ist für Oberflächen und Transparenz gedacht. Ein Foto als PNG bläht Speicher und Übertragung auf.
• Qualität 100 in JPEG/AVIF. Der Unterschied zu einer moderaten Stufe ist selten sichtbar, im Gewicht dagegen schon.
• Zuschnitte in 1:1 und 16:9 “für alle Fälle”, die nie verwendet werden. Jeder Upload vervielfacht I/O und Backups.
• Lazy Loading für Logo und Hero. Verzögert den LCP und verursacht CLS, wenn im Markup Abmessungen fehlen.
• Zwei Optimierungs-Plugins gleichzeitig. Das eine schreibt URLs um, das andere liefert WebP aus; das Ergebnis ist ein 404 oder doppelte Verarbeitung.
• width und height ignorieren. Ohne intrinsische Abmessungen springt das Layout, sobald das Bild ankommt.

#Barrierefreiheit von Bildern in WordPress nach BFSG

Dieser Teil fehlt in den meisten Performance-Leitfäden, und in Deutschland ist er Pflicht. Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz (BFSG), mit dem Deutschland den European Accessibility Act umsetzt, auch für Dienstleistungen im elektronischen Geschäftsverkehr mit Verbrauchern. Kleinstunternehmen, die Dienstleistungen anbieten, sind ausgenommen. Die Anforderungen führen zur Norm EN 301 549 und über sie zu den WCAG-2.1-Kriterien auf Stufe AA. Ist Ihr Projekt ein Onlineshop, eine Hochschule oder eine Behörde, muss die Bildarbeit neben geringem Gewicht zwei Kriterien erfüllen.

Das erste ist die Textalternative (1.1.1). Ein leeres alt ist für ein dekoratives Bild korrekt und erwünscht, für ein Bild mit Information ist es ein Mangel. WordPress speichert dieses Feld in der Mediathek, also ist ein Audit eine Abfrage auf postmeta nach _wp_attachment_image_alt und keine Prüfung Template für Template.

Das zweite trifft dieses Thema direkt: Bilder von Text (1.4.5). Ein Werbebanner mit der Überschrift in den Pixeln verletzt das Kriterium, lässt sich weder übersetzen noch markieren und ist zugleich der schlechteste Kandidat für AVIF, weil die Glättung feiner Texturen, die dieses Format anwendet, kleine Schrift am stärksten trifft. HTML-Text über dem Bild löst das rechtliche Problem und das Kompressionsproblem zugleich. Dasselbe gilt für Interface-Screenshots mit winziger Schrift: Sind sie illustrativ, schneiden Sie sie zu und vergrößern sie vor der Kodierung, statt den ganzen Bildschirm hochzuladen und dem Encoder zu vertrauen.

Eine verwandte Anmerkung, falls sie in derselben Prüfung auftaucht: SVG bleibt die richtige Antwort für Icons, weil es auflösungsunabhängig ist und eine Datei jede Pixeldichte ohne srcset abdeckt. Der Core erlaubt den Upload standardmäßig nicht, weil ein SVG Skript transportieren kann. Wenn Sie ihn freischalten, bereinigen Sie die Datei beim Upload, statt der hochladenden Person zu vertrauen.

#Checkliste zur Bildoptimierung vor der Veröffentlichung

• Wie viel wiegt der Hero in der typischen mobilen Variante, verglichen mit dem Median von 135 KB für das größte Bild im Web Almanac 2024?
• Zeigt der Network-Tab AVIF oder WebP im eigentlichen Dokument, nicht nur auf der Testseite des Plugins?
• Entspricht sizes der tatsächlichen CSS-Breite von Inhalt und Hero?
• Hat nur ein einziges Bild fetchpriority="high"?
• Antwortet das CDN (falls vorhanden) ab der zweiten Anfrage mit 200 und cache-hit?
• Ist der CLS des Heros stabil (Abmessungen oder aspect-ratio im CSS)?
• Haben informative Bilder einen Alternativtext, und ist Text in Bannern HTML statt Pixel?

Scheitert ein Punkt, beheben Sie genau diesen Punkt, bevor Sie weitere Werkzeuge kaufen.

#Womit man bei der Bildoptimierung in WordPress anfängt

Die Formate sind entschieden und brauchen keine weitere Recherche. AVIF hat 96,35 % Browserunterstützung und native Unterstützung in WordPress seit 6.5. JPEG XL hat keins von beidem: Chrome 155 dekodiert es seit dem 6. Oktober 2026, Edge, Chrome für Android und der WordPress-Core nicht, also bleibt es vorerst außerhalb des srcset. WebP ist der Fallback, der überall funktioniert.

Ungelöst ist auf fast jeder Website alles zwischen Upload und Darstellung. Die Reihenfolge, mit einer Messung bei jedem Schritt: das LCP-Element je Template mit Felddaten bestätigen, im Website-Zustand prüfen, was der Server kodieren kann, die Konvertierung der Zwischengrößen aktivieren und den Bestand in Batches regenerieren, prüfen, ob sizes das echte Layout beschreibt, kontrollieren, ob die Edge still WebP liefert, weil die Quelle zu groß war, und mit der Prüfung von Textalternativen und Bildern von Text abschließen. Die 1 % Verbreitung im Web Almanac sind das, was passiert, wenn ein Projekt beim zweiten Schritt stehen bleibt, weil schon ein Bild-Plugin installiert ist.

Bremsen Bilder Ihre Core Web Vitals, ist das erste nützliche Artefakt ein kurzes Inventar: die betroffenen Templates, die Herkunft jedes Bildes und das aktuelle LCP-Element mit seiner Zeit je Template. Genau diese Liste arbeiten wir in der WordPress-Geschwindigkeitsoptimierung ab.