Die wichtigste Erkenntnis: WordPress generiert seit Version 4.4 automatisch srcset- und sizes-Attribute für jedes Bild — das Problem auf den meisten Websites ist kein fehlendes Feature, sondern ein falscher sizes-Wert, der dem Browser stillschweigend sagt, er solle eine größere Datei herunterladen, als das Layout tatsächlich benötigt. Dieses eine Attribut zu korrigieren, ist meist die wirkungsvollste Änderung an responsiven Bildern, die du vornehmen kannst.
Was srcset und sizes wirklich tun
Ein responsives <img>-Tag in WordPress sieht ungefähr so aus:
<img src="image-1024x683.jpg"
srcset="image-300x200.jpg 300w, image-768x512.jpg 768w, image-1024x683.jpg 1024w"
sizes="(max-width: 600px) 100vw, 600px">
srcset listet die verfügbaren Dateikandidaten und ihre tatsächlichen Pixelbreiten auf. sizes teilt dem Browser mit, wie breit das Bild bei verschiedenen Viewport-Breiten tatsächlich angezeigt wird. Der Browser kombiniert beides zusammen mit der Bildschirmdichte des Geräts, um die kleinste Datei zu wählen, die noch scharf aussieht — bevor überhaupt etwas heruntergeladen wird.
Das ist der Teil, den man unterstreichen sollte: Der Browser trifft die Entscheidung, nicht WordPress und nicht ein Plugin. Wenn sizes korrekt ist, trifft der Browser automatisch eine gute Entscheidung. Wenn sizes falsch ist, trifft der Browser eine selbstsichere, schnelle und falsche Entscheidung — meist zugunsten einer größeren Datei "zur Sicherheit".
Wo Wordpress' Standardschätzung versagt
WordPress berechnet einen Standard-sizes-Wert nach einer einfachen Regel: Es wird angenommen, dass das Bild in seiner eigenen intrinsischen Breite angezeigt wird, bis maximal zur Viewport-Breite. Diese Annahme stimmt für einen einfachen einspaltigen Blogbeitrag. Sie versagt bei vielen gängigen WordPress-Layouts:
- Grid- und Spaltenlayouts — ein Produktraster mit 3 Bildern pro Zeile zeigt jedes Bild bei etwa einem Drittel der Container-Breite an, nicht bei der vollen intrinsischen Breite des Bildes.
- Page-Builder-Layouts — Elementor, Divi und ähnliche Builder setzen Container-Breiten oft über CSS, worauf die PHP-seitige
sizes-Berechnung von WordPress keinen Einblick hat. - Themes mit Sidebar — die eigentliche Inhaltsspalte ist schmaler als der Viewport, aber die Standardberechnung weiß das nicht.
In jedem Fall wird dem Browser gesagt "dieses Bild wird nahe der vollen Viewport-Breite angezeigt", also lädt er einen dafür dimensionierten Kandidaten herunter — selbst wenn das Bild auf dem Bildschirm viel kleiner gerendert wird.
So prüfst du, ob deine Website dieses Problem hat
- Öffne die Seite in Chrome, klicke mit rechts auf ein Inhaltsbild und wähle Untersuchen.
- Finde im Elements-Panel das
sizes-Attribut am<img>-Tag. - Vergleiche es mit der tatsächlich gerenderten Breite des Bildes — sichtbar im Computed-Panel als
width. - Wenn
sizesetwas nahe der vollen Viewport-Breite behauptet, das Bild aber bei z.B. 33% der Container-Breite gerendert wird, lädt der Browser sehr wahrscheinlich eine 2-3x größere Datei als nötig.
Ein schnellerer Check: Öffne den Network-Tab, filtere nach Img und vergleiche die Pixelabmessungen der heruntergeladenen Datei (im Preview-Tab sichtbar) mit ihrer gerenderten CSS-Größe. Eine große Lücke zwischen beiden ist das Kennzeichen eines defekten sizes-Werts.
Das sizes-Attribut korrigieren
Bei den meisten Themes bedeutet das, WordPress' Standardberechnung mit dem wp_calculate_image_sizes-Filter durch einen Wert zu überschreiben, der zu deinem tatsächlichen Layout passt:
add_filter('wp_calculate_image_sizes', function ($sizes, $size) {
return '(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw';
}, 10, 2);
Die genauen Breakpoints sollten zum tatsächlichen CSS-Grid oder Container-Verhalten deines Themes passen — dieses Beispiel geht von einem Layout aus, das auf Mobilgeräten eine Spalte, auf Tablets zwei und auf Desktops drei Spalten zeigt. Prüfe die echten Breakpoints im Stylesheet deines Themes, statt sie zu raten.
Die richtigen Bildgrößen von Anfang an registrieren
srcset kann nur Kandidaten anbieten, die tatsächlich existieren. Wenn dein Theme nur eine 1024px- und eine 300px-Thumbnail-Größe registriert, hat der Browser keine 600px-Option für einen mittelgroßen Viewport zur Auswahl — er muss die nächstgelegene verfügbare wählen, die oft immer noch zu groß ist. Das Registrieren von Zwischengrößen mit add_image_size() gibt dem Browser feinere Auswahlmöglichkeiten:
| Größenname | Breite | Typische Verwendung |
|---|---|---|
| thumbnail | 150px | Admin-Listen, Related-Post-Karten |
| medium | 600px | Mobile Inhaltsbreite |
| medium_large | 900px | Tablet-Inhaltsbreite |
| large | 1200px | Desktop-Inhaltsbreite |
| full | Original-Upload | Selten die richtige Wahl für die direkte Auslieferung |
Eine Größe zu registrieren, generiert sie nicht rückwirkend für bereits hochgeladene Bilder — neue Größen gelten nur für zukünftige Uploads oder nach dem Ausführen eines Regenerierungstools für vorhandene Medien.
Ein konkretes Beispiel
Bei einem kürzlichen Audit eines WordPress-Blogs mit einem 3-spaltigen Related-Posts-Raster behauptete das Standard-sizes-Attribut, dass jedes Thumbnail bei allen Bildschirmgrößen bei 100vw (volle Viewport-Breite) angezeigt wird. In Wirklichkeit wurde jedes Thumbnail auf dem Desktop bei etwa 320px gerendert.
| Vor der Korrektur | Nach der Korrektur | |
|---|---|---|
| Vom Browser gewählter Kandidat | 1024px breite Datei | 384px breite Datei |
| Durchschnittliche Dateigröße pro Thumbnail | 145 KB | 38 KB |
| Gesamtgewicht für ein 6-Thumbnail-Raster | 870 KB | 228 KB |
Die Korrektur eines einzigen sizes-Filters sparte auf dieser einen Seite rund 640 KB — mehr, als die meisten Bildkomprimierungseinstellungen allein erreichen würden, weil das Problem nicht die Komprimierung war, sondern die Anforderung einer viermal größeren Datei als angezeigt.
Wo Formatoptimierung weiterhin eine Rolle spielt
srcset/sizes korrekt einzurichten, steuert, welche Abmessungen heruntergeladen werden. Es steuert nicht das Format dieser Dateien. Ein korrekt dimensioniertes 384px-JPEG ist immer noch größer als nötig, wenn eine 384px-WebP- oder AVIF-Version bei kleinerer Dateigröße identisch aussehen würde. Hier setzt Erdo Image Optimizer als ergänzende Lösung an, nicht als Ersatz: Es konvertiert automatisch jede registrierte Bildgröße — einschließlich der kleineren srcset-Kandidaten, die WordPress generiert — in WebP und AVIF, sodass die vom Browser korrekt gewählte Größe auch im kleinstmöglichen nutzbaren Format ausgeliefert wird.
Mehr zur Formatseite findest du in unserer Anleitung zur Konvertierung von WordPress-Bildern in WebP und in unserer umfassenderen PageSpeed-Insights-Checkliste, die zeigt, wo responsive Bilder ins größere Performance-Bild passen.
Weiterführende Informationen
Für die vollständige technische Spezifikation, wie Browser srcset und sizes auswerten, ist web.devs Leitfaden zu responsiven Bildern die zuverlässigste Referenz — er behandelt dichtebasierte Auswahl, Art Direction mit dem <picture>-Element und Grenzfälle, auf die diese Anleitung nicht eingeht.
Fazit
Responsive Bilder in WordPress sind standardmäßig nicht kaputt — der Mechanismus funktioniert seit 2015 automatisch. Was kaputtgeht, ist der sizes-Wert bei Layouts, die komplexer sind als ein einspaltiger Blog, der Browsern stillschweigend sagt, sie sollen Dateien herunterladen, die zwei- bis dreimal größer sind als tatsächlich angezeigt. Prüfe das Attribut gegen dein reales Layout, bevor du annimmst, deine responsiven Bilder funktionieren bereits korrekt, und kombiniere die Korrektur mit der Formatkonvertierung für den vollen Gewinn.