Die besten WebP-Plugins für WordPress: Bilder konvertieren und optimieren

WebP und AVIF können WordPress-Bilder deutlich schlanker machen. Welche Lösung dafür passt, hängt aber weniger vom Dateiformat ab als von deiner Website: Wie stark ist das Hosting? Sollen Bilder den eigenen Server verlassen? Gibt es schon ein CDN? Und wie groß ist die Mediathek?

Genau daran orientiert sich dieser Vergleich. Du erfährst zuerst, welche Arten von WebP-Plugins für WordPress es gibt. Danach kannst du entscheiden, ob lokale Konvertierung, ein externer Optimierungsdienst oder ein Bild-CDN besser zu deinem Setup passt.

Die folgenden Fälle decken die meisten WordPress-Websites ab. Wenn zwei Punkte gleichzeitig passen, entscheide zuerst, ob die Bilder lokal bleiben müssen. Diese Entscheidung lässt sich später deutlich schwerer ändern als eine Qualitätsstufe.

1. Vor dem Upload: Du exportierst WebP oder AVIF selbst und lädst die fertige Datei in WordPress hoch.
2. Auf dem WordPress-Server: Ein Plugin nutzt GD oder Imagick und speichert moderne Varianten neben dem Original oder im Cache.
3. Bei einem Optimierungsdienst: WordPress schickt das Bild an eine externe API und erhält eine komprimierte Datei zurück.
4. Beim Abruf über ein CDN: Das CDN erzeugt die passende Größe und das passende Format, wenn ein Besucher das Bild anfordert.

Bei einer lokalen Lösung entscheidet das Plugin in WordPress, welche Bildgröße gebraucht wird, und erzeugt die optimierte Datei auf demselben Server. neo Optimize arbeitet mit Cache-Kopien. Originaldateien und Mediathek-Daten bleiben dabei unverändert. Das reduziert externe Datenflüsse und macht einen Wechsel einfacher, setzt aber eine funktionierende Bildbibliothek und genügend Rechenzeit voraus.

GD und Imagick müssen das gewünschte Format tatsächlich schreiben können. Dass ein Browser AVIF anzeigt, bedeutet noch nicht, dass dein Server AVIF erzeugen kann. WordPress zeigt die verfügbaren Formate unter "Werkzeuge > Website-Zustand > Bericht > Medien-Handling" an. Bei WebP ist die Unterstützung auf üblichen Hostings weit verbreitet; AVIF solltest du ausdrücklich prüfen.

Imagify und ShortPixel schicken Bilddaten an einen externen Dienst. Das schont die CPU des Hostings und macht aufwendige Komprimierung leichter planbar. Dafür musst du klären, wohin die Dateien übertragen werden, wie Kontingente gezählt werden, welche Dateigrößen erlaubt sind und ob WordPress-Thumbnails jeweils einzeln zählen. Auch das Backup-Verhalten unterscheidet sich.

Ein Bild-CDN speichert nicht nur fertige WebP-Dateien. Es kann aus einem Original für jede benötigte Breite, Qualität und Browserunterstützung eine eigene Variante erzeugen. Der Browser lädt das Bild anschließend vom CDN. Das funktioniert bequem und weltweit, bringt aber eine stärkere Abhängigkeit von Cache, URL-Struktur und Anbieter mit.

Leichte Empfehlung: AVIF. Das Format nutzt eine modernere Kompression und kann bei vergleichbarer sichtbarer Qualität kleinere Dateien liefern. neo Optimize bevorzugt AVIF deshalb standardmäßig, wenn GD oder Imagick es auf deinem Server zuverlässig und sicher erzeugen kann.

WebP bleibt trotzdem eine gute Wahl, wenn dein Hosting AVIF nicht unterstützt, die Konvertierung möglichst wenig Rechenzeit beanspruchen soll oder du Animationen verwendest. WebP ist in WordPress-Plugins, Bildwerkzeugen und Hosting-Paketen länger etabliert und lässt sich deshalb in manchen Setups unkomplizierter betreiben.

Teste Fotos, Screenshots, Logos und transparente Grafiken getrennt. Eine Qualitätsstufe, die bei einem Foto gut aussieht, kann kleine Schrift in einem Screenshot sichtbar beschädigen. Ein belastbarer Vergleich verwendet immer dieselben Pixelabmessungen und beurteilt nicht nur die Dateigröße.

Beide Formate werden von aktuellen Browsern breit unterstützt. Originale bleiben trotzdem wichtig. Social-Crawler, externe Feeds, E-Mail-Clients, Cache-Proxies oder falsch konfigurierte Server können moderne Varianten anders behandeln als ein normaler Browser.

WordPress akzeptiert WebP-Uploads seit Version 5.8. Seit WordPress 6.5 lassen sich auch AVIF-Dateien hochladen und verarbeiten, sofern die Bildbibliothek des Servers AVIF unterstützt. WordPress erzeugt aus einer hochgeladenen modernen Datei die üblichen Bildgrößen, Attachment-Daten und srcset-Angaben.

Das ist keine automatische Konvertierung deiner Mediathek. WordPress wandelt vorhandene JPG- und PNG-Dateien nicht selbstständig vollständig in WebP um. Auch ein neuer JPG-Upload wird im stabilen Core nicht generell zusätzlich als WebP und AVIF gespeichert. Dafür brauchst du ein Plugin, einen eigenen Build-Prozess oder ein CDN.

Am 10. August 2026 ist WordPress 7.0.2 die aktuelle stabile Version. Funktionen aus einer Beta oder einer angekündigten Core-Version zählen hier nicht als verfügbar. Den späteren Stand findest du in der offiziellen WordPress-Versionsübersicht.

Die technischen Hintergründe dokumentiert das Core-Team in den Beiträgen zur WebP-Unterstützung ab WordPress 5.8 und zur AVIF-Unterstützung ab WordPress 6.5.

Die folgende Auswahl ist keine Rangliste. Ein CDN-Plugin löst ein anderes Problem als ein lokaler WebP-Konverter für WordPress. Entscheidend ist, ob das technische Modell zu Hosting, Datenschutz und Mediathek passt. Preise nennen wir bewusst nicht. Funktionsumfang und Limits können sich ändern; die verlinkten Plugin-Seiten und Dokumentationen bleiben deshalb die letzte Instanz.

neo Optimize verarbeitet Bilder direkt auf deinem Server. Imagick wird bevorzugt, GD dient als Fallback. Optimierte Varianten werden im Cache gespeichert und an die tatsächlich benötigte Darstellung angepasst. Quelldateien und Mediathek-Daten bleiben unverändert. Nach dem Löschen des Caches entstehen die Varianten bei der nächsten Anfrage erneut.

Das passt gut zu Websites, die keine externe Bild-API verwenden möchten und einen nachvollziehbaren Rückweg brauchen. Die Rechenarbeit bleibt allerdings auf deinem Server. AVIF funktioniert nur, wenn die vorhandene Bildbibliothek AVIF codieren kann. Fehlt diese Unterstützung, ist WebP die zuverlässige Alternative. Mehr Details und den Download findest du auf der neoOptimize-Produktseite.

Converter for Media erzeugt moderne Varianten für neue und vorhandene Bilder und legt sie getrennt von den Originalen ab. Die Auslieferung hängt stärker von der Serverkonfiguration ab als bei einer reinen Cloud-Lösung. Apache-Regeln, Nginx-Konfiguration, MIME-Typen und Schreibrechte müssen zusammenpassen. Der freie Funktionsumfang konzentriert sich aktuell auf WebP; AVIF gehört zum erweiterten Angebot.

Das Plugin ist interessant, wenn du eine klassische Bulk-Konvertierung suchst und Serverregeln selbst kontrollieren kannst. Auf Managed Hosting solltest du vorher klären, ob die nötigen Regeln erlaubt sind. Unser Converter-for-Media-Check und die Alternativen zu Converter for Media gehen genauer auf die Unterschiede ein.

Imagify verlagert die Komprimierung an einen externen Dienst. Neue Uploads können automatisch verarbeitet werden. Für bestehende Medien gibt es eine Bulk-Optimierung, die im Hintergrund weiterläuft. Das schont lokale CPU. Die freie Nutzung ist allerdings an ein monatliches Datenkontingent gebunden.

Auf Shared Hosting ist dieser Ansatz bequem. Vor einer großen Mediathek solltest du trotzdem zählen, wie viele Thumbnail-Größen WordPress pro Original erzeugt und ob Backups zusätzlich Speicher belegen. Weitere Details findest du im Imagify Plugin-Check und bei den Imagify-Alternativen.

ShortPixel verarbeitet JPG, PNG, GIF, WebP und AVIF über einen externen Dienst. Das kostenlose Konto umfasst ein monatliches Credit-Kontingent. Abhängig von der Einstellung zählen auch erzeugte WordPress-Thumbnails. Vor einem Bulk-Lauf solltest du deshalb Backup, Thumbnail-Zählung und Auslieferungsmethode festlegen.

Die vielen Optionen sind flexibel, verlangen aber eine saubere Einrichtung. Unser ShortPixel Plugin-Check und die ShortPixel-Alternativen helfen beim Vergleich.

EWWW verbindet lokale Werkzeuge mit optionaler Cloud- und CDN-Verarbeitung. Lokales WebP kann ohne monatliches Bildkontingent funktionieren, sofern das Hosting die benötigten Programme und Rechte bereitstellt. AVIF und dynamische CDN-Auslieferung hängen stärker an den externen Diensten des Anbieters.

Das ist nützlich, wenn du bewusst zwischen lokal und extern wählen möchtest. Dokumentiere dann genau, welcher Teil aktiv ist. Sonst ist später schwer zu erkennen, ob ein Bild aus dem Uploads-Ordner, von einer API oder vom CDN kommt. Siehe auch unseren EWWW Plugin-Check und die EWWW-Alternativen.

Smush kombiniert Kompression, Größenanpassung, Lazy Loading und CDN-Funktionen. Der freie Optimierer hat aktuell unter anderem ein Dateigrößenlimit pro Bild. Lokale WebP- und AVIF-Auslieferung gehört zum erweiterten Funktionsumfang. Wer Smush ohnehin nutzt, kann mehrere Aufgaben in einem Plugin bündeln.

Prüfe dabei Überschneidungen mit Cache- und Lazy-Loading-Plugins. Zwei Systeme, die dieselben Bild-URLs oder Ladeattribute verändern, machen die Fehlersuche unnötig schwer. Details stehen im Smush Plugin-Check und bei den Smush-Alternativen.

Optimole verarbeitet Bilder in der Cloud und liefert passende Varianten über ein CDN aus. Format, Abmessungen und Qualität können sich an Browser und Gerät orientieren. Die freie Nutzung wird aktuell nach monatlichen Besuchen begrenzt und nicht wie eine klassische lokale Bulk-Konvertierung gezählt.

Das Modell eignet sich für internationale Seiten und viele responsive Größen. Vor einem Wechsel solltest du testen, wie die Website zu Original-URLs zurückkehrt, wie ein Cache-Purge funktioniert und was nach dem Erreichen eines Limits passiert. Mehr dazu im Optimole Plugin-Check und bei den Optimole-Alternativen.

Jetpack Boost kann Bilder über das Jetpack Image CDN optimieren und WebP an unterstützende Browser liefern. Die Verarbeitung findet nicht auf deinem Server statt. Das ist eine einfache Option, wenn Boost bereits installiert ist und du möglichst wenige Einstellungen möchtest.

Die aktuelle Dokumentation beschreibt WebP ausdrücklich. Eine manuelle AVIF-Auswahl für das kostenlose Image CDN solltest du nicht voraussetzen. Teste außerdem CSS-Hintergründe und dynamische Page-Builder-Komponenten, weil ein CDN sie nicht immer genauso erkennt wie normale Mediathek-Bilder.

Lokale Verarbeitung ist sinnvoll, wenn Bilddateien den eigenen Server nicht verlassen sollen. Sie vermeidet API-Kontingente und lässt sich gut rückgängig machen, solange Originale nicht überschrieben werden. Die Kehrseite ist die Serverlast: Jede Konvertierung braucht CPU, Arbeitsspeicher und Schreibzugriffe.

neo Optimize passt, wenn die Ausgabegröße zur tatsächlichen Darstellung passen und als Cache-Kopie entstehen soll. Converter for Media konzentriert sich stärker auf die klassische Konvertierung von Uploads und serverbasierte Auslieferungsregeln. EWWW bietet mehr Wege, erfordert aber auch mehr Aufmerksamkeit dafür, welche lokalen und externen Funktionen aktiv sind.

Prüfe bei jeder lokalen Lösung, ob dein Server das gewünschte Format schreiben kann, ob Originale erhalten bleiben und wie Varianten neu erzeugt werden. Nach einer Änderung der Thumbnail-Größen muss der Prozess ebenfalls weiter funktionieren. Bei großen Bibliotheken sollte ein Timeout nicht dazu führen, dass du von vorn beginnen musst.

Ein Bild-CDN kann aus einem Original bei Bedarf eine passende Kombination aus Breite, Qualität und Format erzeugen. Optimole ist in diesem Vergleich der deutlichste Vertreter dieses Modells. Jetpack Boost ist eine einfachere Möglichkeit im Jetpack-Umfeld. EWWW und Smush verbinden Bildoptimierung ebenfalls mit optionalen CDN-Funktionen.

Die Vorteile sind geringe Last auf WordPress, flexible responsive Varianten und eine weltweite Auslieferung. Die Nachteile zeigen sich beim Anbieterwechsel. CDN-Cache, umgeschriebene URLs und gespeicherte Page-Builder-Fragmente können nach der Deaktivierung weiter auf den alten Dienst zeigen. Dokumentiere deshalb, wie du zu Original-URLs zurückkehrst und welche Caches dabei geleert werden müssen.

Bei lokalen Plugins bedeutet kostenlos meist: kein monatliches Bildkontingent, dafür Rechenarbeit auf deinem Hosting. Cloud-Plugins begrenzen häufig Datenmenge oder Bildanzahl. Ein CDN kann Besuche oder Traffic zählen. Diese Modelle lassen sich mit einer einzigen Zahl kaum sinnvoll vergleichen.

Für lokales WebP ohne laufendes Bildkontingent kommen neo Optimize, der WebP-Funktionsumfang von Converter for Media und lokale EWWW-Funktionen infrage. Auf einem schwachen Server kann ein begrenzter Cloud-Dienst trotzdem die bessere kostenfreie Lösung sein. Prüfe Dateigrößenlimit, Thumbnail-Zählung, AVIF-Zugang, CDN-Traffic, Backups und das Verhalten nach Erreichen eines Limits.

Danach geht es um die Details:

• Altbestand: Wie viele Originale und erzeugte Größen gibt es tatsächlich?
• WebP oder AVIF: Reicht WebP oder kann das Setup AVIF zuverlässig erzeugen?
• Originale und Backups: Werden Quellen unangetastet gelassen, ersetzt oder separat gesichert?
• Neue Bildgrößen: Was passiert nach einem Theme-Wechsel oder geänderten WooCommerce-Einstellungen?
• Page Builder: Elementor, Bricks und andere Builder speichern CSS-Hintergründe anders als normale <img>Elemente.
• Multisite: Prüfe Speicherquoten, netzwerkweite Aktivierung und getrennte Domains.
• Datenschutz: Bei externer Verarbeitung gehören Anbieter, Region und Löschweg in die Dokumentation.
• Laufender Aufwand: Berücksichtige Thumbnails, neue Uploads, Besuche und CDN-Traffic.

Wenn du viele Dateien organisieren musst, ist die Mediathek ein eigener Arbeitsschritt. neo Library hilft bei der Übersicht. Auch die Ordnerstruktur ist unabhängig vom Dateiformat. Unser Leitfaden zeigt, wie du Datumsordner aus WordPress-Medien-URLs entfernst.

1. Backup erstellen. Sichere Datenbank und den vollständigen Uploads-Ordner. Ein Datenbank-Backup enthält keine Bilddateien.
2. Mit wenigen Bildern testen. Nutze Fotos, transparente Logos, Screenshots, große Uploads und WooCommerce-Galerien. Staging ist dafür ideal.
3. Originale behalten. Aktiviere Backups oder wähle ein Cache-Modell. Lösche JPG und PNG nicht, solange der spätere Neuaufbau ungeklärt ist.
4. Bulk-Prozess kontrolliert starten. Beobachte CPU, RAM, Laufzeit, Fehlerrate und freien Speicher. Teile große Bibliotheken in Batches.
5. Caches gezielt leeren. Dazu gehören WordPress-Page-Cache, Object Cache, Server-Cache, CDN und Browser.
6. Wichtige Seitentypen prüfen. Öffne Startseite, Beiträge, Archive, Produktseiten, Slider, Lightbox und mobile Breakpoints.
7. Network-Response kontrollieren. Maßgeblich sind Statuscode, URL und Content-Type: image/webp beziehungsweise image/avif.
8. Rollback dokumentieren. Halte fest, welche Einstellung, Rewrite-Regel und Cache-Ebene für den Rückweg geändert werden muss.

Du kannst WebP oder AVIF vor dem Upload erzeugen und direkt in der Mediathek verwenden. In einem Entwicklerteam kann auch der Build-Prozess aus JPG- und PNG-Quellen automatisch moderne Varianten erzeugen. Alternativ übernimmt ein Reverse Proxy oder CDN die Formatwahl.

Der Aufwand steckt nicht in der ersten Konvertierung, sondern im Betrieb. Neue Redakteurs-Uploads, WordPress-Thumbnails, Theme-Wechsel, srcset, MIME-Typen, Fallbacks und Cache-Invalidierung müssen zusammenpassen. Manuelle Serverregeln müssen außerdem den Browser-Request im Cache-Key berücksichtigen, damit nicht der falsche Client eine ungeeignete Variante erhält.

Für Teams mit Deployment-Pipeline und klaren Bildvorgaben ist das ein guter Weg. Für typische Redaktionsseiten und Shops ist ein einzelnes zuständiges Plugin meist leichter zu warten.

Prüfe die tatsächliche Network-Response. Häufig fehlen Rewrite-Regeln, der Page Cache enthält altes HTML oder ein CDN kennt die neue Variante noch nicht. Auch ein HTML-Minifier kann <picture>-Markup verändern.

Dann verweist das HTML auf eine Variante, die nicht existiert. Ursachen sind abgebrochene Bulk-Jobs, falsche Upload-Pfade, fehlende Schreibrechte oder gelöschte Cache-Dateien. Erzeuge die Varianten neu und leere danach die Caches.

Eine .webp-URL mit text/html als Content-Type ist meist eine Fehlerseite oder eine falsche Serverkonfiguration. Für WebP muss image/webp, für AVIF image/avif zurückkommen.

Bei On-Demand-Konvertierung muss der Server die Variante neu erzeugen dürfen. Prüfe Dateirechte, PHP-Fehlerlog, Bildbibliothek und Cache-Pfad. Bei einem CDN kann der Origin-Pfad ungültig oder durch Hotlink-Schutz blockiert sein.

Ein Cache-Plugin, ein Image Optimizer und ein CDN können dasselbe Bild nacheinander komprimieren. Das erzeugt unübersichtliche URLs und sichtbare Artefakte. Lege einen Verantwortlichen für Format und Kompression fest und schalte die Funktion in anderen Tools ab.

Nutze keine pauschale Qualitätszahl für alle Motive. Produktfotos, Screenshots mit Text, Illustrationen und transparente Grafiken reagieren unterschiedlich. Vergleiche immer bei identischen Pixelabmessungen.

WebP ersetzt keine vernünftigen Abmessungen. Ein riesiges Original kostet Speicher, Backup-Zeit und Rechenleistung. Begrenze Upload-Abmessungen oder erzeuge passende Varianten, ohne das benötigte Master für spätere Größen zu verlieren.

AVIF-Encoding und viele Thumbnail-Größen können Shared Hosting überlasten. Reduziere die Batch-Größe, nutze Hintergrundjobs oder wechsle auf externe Verarbeitung. Ein Plugin sollte Fehler protokollieren und später fortsetzen können.

Cache-Keys müssen Format und relevante Request-Header berücksichtigen. Leere die betroffenen Varianten und prüfe, ob der CDN-Cache zwischen unterschiedlichen Browsern unterscheidet.

Öffne die Entwicklerwerkzeuge, wechsle zu "Network" und filtere nach "Img". Lade die Seite ohne Cache neu. Wähle das wichtigste Bild aus und kontrolliere unter "Headers" den Content-Type. Unter "Preview" siehst du, ob die Datei intakt ist. "Initiator" zeigt, ob sie aus HTML, CSS oder JavaScript geladen wurde.

Prüfe außerdem die gerenderte Größe im Elements-Panel und die tatsächlichen Abmessungen der Datei. Erst zusammen zeigen diese Angaben, ob das WordPress-Bild korrekt konvertiert, sinnvoll dimensioniert und wirklich als WebP oder AVIF übertragen wurde.

Konvertiert WordPress JPG automatisch in WebP?

Nein. WordPress kann WebP hochladen und responsive Größen daraus erzeugen, wandelt eine bestehende JPG- oder PNG-Mediathek aber nicht automatisch vollständig in WebP um. Dafür brauchst du ein Plugin, einen Build-Prozess oder ein CDN.

Ist WebP oder AVIF besser für WordPress?

AVIF kann bei passenden Bildern effizienter sein, kostet bei der Erzeugung aber oft mehr Rechenleistung. WebP ist breit etabliert und bleibt für viele Setups die pragmatische Wahl. Teste eigene Motive und behalte einen Fallback.

Kann ich bestehende Bilder der Mediathek konvertieren?

Ja. Viele Plugins bieten Bulk-Optimierung oder erzeugen Varianten beim ersten Request. Sichere vorher Dateien und Datenbank, prüfe Speicher und Timeouts und teste den Rollback.

Soll ich die ursprünglichen JPG- oder PNG-Dateien löschen?

In der Regel nein. Originale werden für neue Thumbnail-Größen, Qualitätsänderungen, Fallback und einen Anbieterwechsel gebraucht. Ein reversibles Cache- oder Backup-Modell ist sicherer.

Verbessert WebP automatisch die Core Web Vitals?

Nein. Kleinere Übertragungen können helfen, aber LCP hängt zusätzlich von Abmessungen, srcset, Priorisierung, Serverantwort und JavaScript ab. Lazy Loading am sichtbaren LCP-Bild kann sogar schaden.

Kann ich zwei Bildoptimierungs-Plugins gleichzeitig verwenden?

Meist solltest du das vermeiden. Zwei Converter, Lazy-Loading-Systeme oder CDNs können sich überschneiden. Lege für Konvertierung, Kompression und Auslieferung jeweils einen klaren Verantwortlichen fest.

Unterstützt Elementor WebP?

Ja, Elementor kann gültige WebP- und AVIF-Dateien anzeigen. Teste trotzdem Background Images, dynamische Tags, Galerien, Lightbox und regenerierte CSS-Dateien, weil diese anders als normale Mediathek-Bilder gecacht werden können.

Ein guter WebP Converter für WordPress passt zu deinem Hosting und zum Redaktionsalltag. Lokale Lösungen geben dir Kontrolle und vermeiden externe Bildverarbeitung. Cloud-Plugins entlasten schwache Server. Bild-CDNs sind stark bei dynamischen Größen und weltweiter Auslieferung, brauchen aber einen sauberen Cache- und Ausstiegsplan.

Wenn Originale erhalten bleiben und Bilder ohne externes Kontingent auf dem eigenen Server verarbeitet werden sollen, ist neo Optimize ein sinnvoller Ausgangspunkt. Bei sehr knappen Serverressourcen oder weltweiter dynamischer Transformation ist Cloud beziehungsweise CDN die passendere Richtung. Teste in jedem Fall echte Seitentypen und kontrolliere anschließend die Response im Browser.

Funktionsstand: 11. August 2026. Anbieter können Limits und Funktionsumfang ändern.