WordPress Bilder optimieren
WordPress Bilder optimieren: AVIF/WebP richtig einsetzen, Kompression lokal vs. Dienst, responsive srcset, Lazy-Loading und die Bild-CDN-Entscheidung.
Bilder sind auf den meisten WordPress-Seiten der größte Anteil am Seitengewicht — und damit meist der schnellste Hebel für spürbar bessere Ladezeiten. Dieser Artikel deckt die vier Entscheidungen ab, die du treffen musst: Format, Kompressionsweg, responsive Auslieferung und ob du ein Bild-CDN brauchst.
Wenn dein größtes Bild gleichzeitig dein LCP-Element ist, lies ergänzend LCP verbessern WordPress — dort geht es um fetchpriority und die Sonderregeln für das größte Element der Seite. Dieser Artikel behandelt alle anderen Bilder deiner Seite.
Format: AVIF und WebP statt JPEG/PNG
Moderne Bildformate komprimieren bei vergleichbarer wahrgenommener Qualität deutlich kleiner als die klassischen Formate: AVIF ist gegenüber WebP rund 20–30 % kleiner, WebP wiederum liegt rund 25–35 % unter JPEG (ShortPixel-Formatvergleich AVIF vs. WebP). Die Browser-Unterstützung liegt 2026 bei beiden Formaten im hohen 90er-Prozentbereich — praktisch heißt das: AVIF als primäres Format ausliefern, WebP und JPEG als Fallback über das <picture>-Element oder automatisch per Plugin.
Was du nicht brauchst: Du musst nicht jedes Bild manuell in drei Formaten exportieren. Das übernimmt jedes brauchbare Optimierungs-Plugin automatisch beim Upload.
Kompressionsgrad: verlustfrei vs. verlustbehaftet
Fast jedes Optimierungs-Plugin bietet die Wahl zwischen verlustfreier Kompression (kleinere Ersparnis, keine sichtbare Qualitätsänderung) und verlustbehafteter Kompression (deutlich kleinere Dateien, minimale Qualitätseinbußen). Für die allermeisten Website-Bilder ist verlustbehaftet bei mittlerer bis hoher Qualitätsstufe (üblicherweise im Bereich 70–85 auf einer 100er-Skala, je nach Anbieter-Bezeichnung) der bessere Kompromiss — der Unterschied ist für das menschliche Auge auf einem Bildschirm praktisch nicht wahrnehmbar, die Dateigröße aber spürbar kleiner. Bei Produktfotos in einem Shop, wo Kunden hineinzoomen, lohnt sich testweise eine höhere Qualitätsstufe.
Kompression: lokal vs. Dienst
Es gibt zwei grundsätzliche Wege, Bilder zu komprimieren:
Lokal/lose auf dem Server: Plugins wie Imagify oder EWWW Image Optimizer verarbeiten Bilder direkt auf deinem Webspace. Vorteil: keine Daten verlassen deinen Server. Nachteil: Die Rechenlast liegt bei deinem Hosting — bei Shared Hosting mit begrenzten Ressourcen kann das bei großen Mediatheken spürbar dauern oder Timeouts verursachen.
Cloud-Dienst mit API: Anbieter wie ShortPixel* oder Optimole schicken Bilder zur Kompression an eigene Server und liefern sie optimiert zurück. Vorteil: keine Serverlast bei dir, oft bessere Kompressionsalgorithmen und automatische Formatwahl je nach Browser. Nachteil: Bilder — auch wenn sie in der Regel keine personenbezogenen Daten enthalten — durchlaufen einen weiteren Dienstleister, was eine Auftragsverarbeitungs-Prüfung nötig macht.
ShortPixel* ist hier redaktionell unsere erste Empfehlung: Firmensitz in Rumänien (EU), Datenverarbeitung laut eigener Dokumentation in Deutschland und Rumänien, eigener Auftragsverarbeitungsvertrag verfügbar (ShortPixel-DPA). Optimole führen wir bewusst nur redaktionell (kein Partnerprogramm bei uns eingerichtet): Das Unternehmen sitzt zwar ebenfalls in Rumänien, liefert Bilder aber über Amazon CloudFront aus — ein US-Unternehmen als CDN-Unterbau, was die Drittlandtransfer-Frage wieder aufmacht, die du eigentlich vermeiden wolltest.
| Anbieter | Serverstandort | AV-Vertrag verfügbar | Drittlandtransfer | Empfehlung |
|---|---|---|---|---|
| ShortPixel* | Rumänien/Deutschland (EU) | Ja | Nein | Ja, redaktionell + Affiliate |
| Optimole | Rumänien, aber CDN via AWS CloudFront (USA) | teilweise | Ja (über CloudFront) | Nur redaktionell, mit Vorbehalt |
| Lokale Kompression (Imagify, EWWW) | dein eigener Server | entfällt (keine Weitergabe) | Nein | Ja, bei ausreichender Serverleistung |
Stand: Juli 2026, Angaben laut Anbieter-Dokumentation — vor Einsatz die aktuellen Datenschutzhinweise des jeweiligen Anbieters prüfen.
Responsive Auslieferung: srcset richtig nutzen
WordPress erzeugt seit Version 4.4 automatisch mehrere Bildgrößen und schreibt sie als srcset/sizes in den <img>-Tag — der Browser wählt dann selbst die passende Auflösung für Bildschirmgröße und Pixel-Dichte. Das Problem in der Praxis: Viele Themes und Page-Builder-Widgets überschreiben das Standardverhalten und liefern eine einzige, oft zu große Bildgröße an alle Geräte aus — auch an Smartphones. Prüfe im Quellcode, ob dein <img>-Tag tatsächlich ein srcset-Attribut mit mehreren Größen enthält. Fehlt es, ist das ein Theme- oder Page-Builder-Problem, kein Kompressions-Problem — Format und Qualität können optimal sein und das Bild lädt trotzdem zu groß.
Art Direction für Mobile. srcset liefert dieselbe Bildkomposition nur in unterschiedlicher Auflösung. Bei einem breiten Panorama-Hero-Bild kann es auf einem Smartphone-Bildschirm trotzdem sinnvoller sein, einen anderen Bildausschnitt zu zeigen statt nur eine verkleinerte Version — dafür ist das <picture>-Element mit unterschiedlichen <source>-Ausschnitten je nach media-Bedingung das richtige Werkzeug, nicht srcset allein. Das ist Zusatzaufwand, der sich nur bei besonders prominenten Bildern lohnt (Startseiten-Hero), nicht bei jedem Content-Bild.
Bilder außerhalb des Hauptcontents — der vergessene Anteil
Optimierungs-Plugins konzentrieren sich meist auf Beitragsbilder in der Mediathek. Häufig übersehen werden: Logo und Icons im Header (oft als PNG statt SVG eingebunden, obwohl SVG für Vektorgrafiken praktisch immer die kleinere und schärfere Wahl ist), Hintergrundbilder in Widgets und der Seitenleiste, sowie Bilder in eingebetteten Formularen oder Popup-Overlays. Ein vollständiger Bild-Audit prüft nicht nur die Mediathek, sondern die gerenderte Seite im Ganzen — dafür eignet sich ein Blick in die Netzwerk-Ansicht der Browser-DevTools, sortiert nach Dateigröße.
Lazy-Loading richtig einsetzen
Native Lazy-Loading (loading="lazy") verzögert das Laden von Bildern, bis sie sich dem Viewport nähern — sinnvoll für alles unterhalb des ersten Bildschirms, weil es Bandbreite und Ladezeit für Above-the-Fold-Inhalte spart.
Die eine Ausnahme, die zählt: Das LCP-Element (in der Regel dein Hero-Bild) darf niemals loading="lazy" bekommen. Lazy-Loading verzögert genau das Element, das so schnell wie möglich sichtbar sein soll (web.dev zu Lazy-Loading). Viele WordPress-Themes setzen Lazy-Loading pauschal auf alle Bilder im Content-Bereich — das trifft dann auch das Hero-Bild und verschlechtert den LCP-Wert messbar. Kontrolliere das nach jedem Theme-Wechsel.
Die Bild-CDN-Entscheidung: ja oder nein?
Ein Bild-CDN liefert Bilder von geografisch verteilten Servern aus und übernimmt oft zusätzlich automatische Format- und Größenwahl. Sinnvoll ist das, wenn:
- deine Besucher geografisch gestreut sind (nicht nur DACH-Traffic von einem deutschen Server aus),
- deine Mediathek groß und bildlastig ist (Magazin, E-Commerce, Portfolio),
- dein Hosting selbst keinen eigenen CDN- oder Edge-Cache mitbringt.
Was du nicht brauchst: Bei einer kleinen deutschen Business-Seite mit überwiegend deutschem Publikum und gutem Hosting bringt ein zusätzliches Bild-CDN meist wenig — die Latenzersparnis zwischen einem deutschen Server und deutschen Besuchern ist gering, während du dir einen zusätzlichen Dienstleister und eine weitere Datenschutz-Prüfung einkaufst. Miss zuerst mit unserem Speed-Test, ob Bildauslieferung überhaupt dein Engpass ist, bevor du ein CDN abonnierst.
Fällt die Entscheidung für ein CDN, ist Bunny.net* unsere Empfehlung für DSGVO-bewusste Betreiber: EU-Unternehmen mit Sitz in Slowenien, konfigurierbare EU-only-Auslieferung, keine Cookies auf CDN-Ebene. Die ausführliche Begründung inklusive Rechtslage und Alternativen steht im DSGVO-CDN-Artikel.
Der häufigste Einzelfehler: Originalgröße hochladen und WordPress skalieren lassen
Viele Betreiber laden ein Foto direkt aus der Kamera oder vom Smartphone hoch — oft 4.000 Pixel breit oder mehr — und verlassen sich darauf, dass WordPress oder das Theme es schon passend skaliert. WordPress erzeugt zwar automatisch kleinere Zwischengrößen, aber wenn ein Theme oder Page-Builder-Widget versehentlich die Originaldatei statt einer Zwischengröße einbindet, lädt der Browser ein Vielfaches der benötigten Datenmenge, komprimiert auf eine Anzeigebreite von vielleicht 800 Pixeln. Die Faustregel: Lade Bilder nie größer hoch, als sie an ihrer größten tatsächlichen Anzeigebreite auf der Seite jemals benötigt werden — meist reichen 2.000 Pixel Breite für ein vollflächiges Hero-Bild auf den größten Desktop-Bildschirmen.
Logos und Icons: SVG statt PNG
Für Vektorgrafiken wie Logos und Icons ist SVG fast immer die richtige Wahl statt PNG: Die Dateien sind in der Regel kleiner, skalieren verlustfrei auf jede Bildschirmgröße und -dichte, und lassen sich inline in den HTML-Code einbetten, ohne einen zusätzlichen HTTP-Request auszulösen. Viele WordPress-Installationen liefern Logos weiterhin als PNG aus, weil der SVG-Upload in der Mediathek aus Sicherheitsgründen standardmäßig deaktiviert ist (SVG-Dateien können Skriptcode enthalten). Wer SVG-Uploads aktiviert, sollte das nur mit einem Plugin tun, das die Dateien vorab bereinigt (sanitizing), nicht ungeprüft zulässt.
Kurz-Checkliste
- AVIF/WebP mit Fallback ausliefern lassen — automatisch per Plugin, nicht manuell.
- Kompressionsweg nach Hosting-Ressourcen wählen: schwaches Shared Hosting → Cloud-Dienst, ausreichend Serverleistung → lokal möglich.
- Bilder nie größer hochladen, als sie maximal angezeigt werden.
srcsetim Quellcode prüfen, nicht nur im Backend vertrauen.- Logos und Icons als bereinigtes SVG statt PNG.
- Lazy-Loading überall außer beim LCP-Element.
- Bild-CDN nur bei internationalem Traffic oder sehr bildlastigen Seiten — sonst erst mal messen.
Ein letzter, oft vergessener Punkt: Bildoptimierung ist kein einmaliges Projekt. Jedes neue Bild, das ein Redakteur ohne Plugin-Automatisierung hochlädt, kann die ganze Arbeit für eine einzelne Seite wieder zunichtemachen. Automatisiere die Kompression beim Upload, statt dich auf manuelle Disziplin zu verlassen — das ist der einzige Weg, der auch nach einem Jahr noch funktioniert.
Weiterführend: WordPress schneller machen für die Gesamt-Roadmap, Core Web Vitals WordPress für die Metrik-Grundlagen, oder Speed-Test starten.