Mantys CoreWarum zeigt PageSpeed Insights immer noch „Properly size images“ an, obwohl ich ein srcset habe?
Kurz gesagt: srcset bietet dem Browser eine Liste von Größen an, aber erst das sizes-Attribut sagt ihm, welche er auswählen soll. Fehlt sizes, ist es falsch oder wird es ignoriert, lädt der Browser das größte Bild der Liste herunter, und PageSpeed bemängelt das, srcset hin oder her.
Sie haben alles richtig gemacht. Ihre Bilder haben ein gut gefülltes srcset, mehrere generierte Breiten, WebP (ein Next-Gen-Bildformat, leichter als JPEG oder PNG). Und trotzdem zeigt der PageSpeed-Insights-Audit weiterhin Properly size images, mit mehreren hundert KB an möglicher Einsparung.
Das ist kein Fehler von PageSpeed. Es ist ein sehr verbreitetes Missverständnis darüber, wie responsive Bilder tatsächlich funktionieren. Klären wir das ein für alle Mal.
Was srcset tut und was es nicht
Nehmen wir einen typischen Fall:
<img
src="photo-1200.jpg"
srcset="photo-400.jpg 400w,
photo-800.jpg 800w,
photo-1200.jpg 1200w,
photo-2000.jpg 2000w">Viele denken, der Browser wähle „die passendste Variante“ aus. In Wirklichkeit ist srcset allein nur eine Speisekarte. Sie sagt: Hier sind die verfügbaren Größen und ihre tatsächliche Breite in Pixeln. Sie sagt nichts darüber aus, wie viel Platz das Bild auf Ihrer Seite einnimmt.
Ohne Information über die Anzeigebreite wendet der Browser einen Standardwert an: sizes="100vw" (vw = Viewport-Breite, die Breite des Fensters), was bedeutet: „das Bild nimmt die volle Breite des Fensters ein“. Und genau da geht alles schief.
Die eigentliche Ursache: das sizes-Attribut (und die Bildschirmdichte-Falle)
Die Berechnung, die der Browser durchführt, ist einfach:
Anzeigebreite (aus sizes) × Pixeldichte des Bildschirms (der DPR, für Device Pixel Ratio) = Zielbreite in Pixeln → er nimmt das erste Bild im srcset ≥ diesem Zielwert.
Betrachten wir zwei Szenarien auf einem 400px breiten Mobilgerät mit Retina-Display (DPR = 2, der Standard auf Mobilgeräten):
Szenario A: sizes fehlt (Standard 100vw)
Angenommene Breite: 400px (100vw)
× DPR 2 = Zielwert 800px
Ist Ihr Bild auf dem Bildschirm aber tatsächlich nur 180px breit (ein Thumbnail in einem Grid), lädt der Browser trotzdem die 800w-Variante herunter. 4× zu schwer.
Szenario B: korrektes sizes
sizes="(max-width: 600px) 180px, 300px"Reale Breite: 180px × DPR 2 = Zielwert 360px
Der Browser nimmt die 400w-Variante. Gewicht durch 4 bis 5 geteilt.
Die schmerzhafte Erkenntnis: ein srcset ohne ein korrektes sizes ist fast nutzlos. Der Browser nimmt im Zweifel zu groß, und PageSpeed sieht es.
Der DPR ist der Faktor, den jeder vergisst: Auf Mobilgeräten haben die meisten Displays DPR 2 oder 3. Ein Bild, das bei 200 physischen Pixeln angezeigt wird, benötigt eine Quelle von 400 bis 600px. Das ist keine Verschwendung, alles darüber hinaus schon.
Der Fall WordPress: das standardmäßige sizes ist oft falsch (die häufigste Ursache in der Praxis)
Wenn Sie WordPress einsetzen, kommt Ihr Problem mit hoher Wahrscheinlichkeit genau von hier, und zwar nicht von einem fehlenden sizes, sondern von einem automatischen und falschen sizes.
WordPress generiert das srcset und ein sizes von selbst. Der Standardwert, den es dabei einsetzt, sieht aber so aus:
sizes="(max-width: 1024px) 100vw, 1024px"Mit anderen Worten: „dieses Bild erstreckt sich über die volle Inhaltsbreite“. Das stimmt für ein Artikelbild in voller Breite. Es ist falsch, sobald das Bild in einem Grid, einer Spalte, einer Sidebar, einer Karte oder einer Galerie steckt, was in den meisten Fällen zutrifft. Das Ergebnis: sizes meldet eine Breite, die weit über der Realität liegt, der Browser lädt zu groß, und PageSpeed sieht es.
Schlimmer noch: Viele Page-Builder (Divi, Elementor …) und Themes passen dieses sizes nicht an die tatsächliche Spalte an. Sie haben also ein einwandfreies srcset, gut generierte Varianten … und ein sizes, das sie sabotiert. Das ist die häufigste Ursache für die Beanstandung „Properly size images“ auf einer WordPress-Seite, und genau die, die man nie überprüft, weil man ja denkt: „WordPress kümmert sich darum“.
Diagnose in 30 Sekunden (ohne zu raten)
Öffnen Sie die Chrome DevTools, Elements-Tab, fahren Sie mit der Maus über das <img>-Tag. Chrome zeigt:
- Rendered size: die Größe, mit der das Bild tatsächlich angezeigt wird.
- Rendered aspect ratio und Intrinsic size: die Größe der heruntergeladenen Datei.
- Current source: welche Variante des srcset gewählt wurde.
Das Urteil ist sofort klar: Zeigt die rendered size 180px, aber die current source ist photo-800.jpg, dann ist Ihr sizes fehlerhaft oder falsch gesetzt. Ist die rendered size 180px und die current source photo-400.jpg, liegen Sie richtig: 400 = 180 × DPR 2, aufgerundet auf die nächste Stufe.
Sie können auch den Network-Tab verwenden: nach Größe sortieren, neu laden und beobachten, welche Variante übertragen wird.
Die generische Lösung (was ein Entwickler von Hand macht)
a. Schreiben Sie ein sizes, das zu Ihrem tatsächlichen Layout passt
Das ist der Kern des Problems. sizes muss die reale Breite widerspiegeln, und zwar die von Ihrem CSS vorgegebene, bei jedem Breakpoint (der Bildschirmbreite, bei der sich das Layout ändert). Beispiel für ein Bild, das auf Mobilgeräten die volle Breite einnimmt, auf dem Desktop aber in 3 Spalten steht:
sizes="(max-width: 600px) 100vw,
(max-width: 1024px) 50vw,
33vw"b. Die richtigen Varianten generieren
Eine 2000w-Variante bringt nichts, wenn Ihr Bild auf dem Bildschirm nie mehr als 600px erreicht. Und umgekehrt: Stellen Sie die Stufen bereit, die Ihre realen Breiten × DPR abdecken (bis 2, manchmal 3).
c. Vergessen Sie nicht width und height
. Sie ändern nichts am Gewicht, verhindern aber CLS (Cumulative Layout Shift, Inhalte, die beim Laden springen), die andere wiederkehrende Beanstandung von PageSpeed.
Der Fall, in dem selbst ein perfektes sizes nicht ausreicht
Manche Elemente tragen kein srcset überhaupt: Slider (Nivo, Swiper, viele Themes), CSS-Hintergrundbilder oder jedes Markup, das ein rohes <img src="...">. Da gibt es buchstäblich nichts umzuschreiben: Kein Optimierungs-Plugin kann eingreifen, weil es kein srcset/sizes zu reparieren gibt. Das ist ein eigenständiges Problem (Bilder ohne srcset), das einen anderen Ansatz erfordert als den hier beschriebenen.
Warum die manuelle Pflege so mühsam ist
Das richtige sizes zu schreiben setzt voraus, für jedes Bild und jeden Breakpoint die tatsächliche CSS-Anzeigebreite zu kennen. Auf einer 5-seitigen Broschürenseite ist das machbar. Auf einer Website mit Dutzenden Templates, wechselnden Grids und redaktionellen Inhalten … ist es nicht mehr zu bewältigen und gerät bei jedem Redesign erneut aus dem Takt.
Genau dieses Problem löst Mantys Core, indem es misst statt rät:
Es rendert die Seite wie ein echter Browser und misst die tatsächlich angezeigte Breite jedes Bildes, bei jedem Breakpoint;
es schreibt
sizesanhand dieser Messung neu: kein Standard-100vwmehr, kein Overdownload mehr;es generiert die nützlichen Varianten (und ihre WebP-Version) passend zu diesen realen Breiten;
und für Bilder ohne
srcset(Slider, rohe Quellen) wendet es eine Substitution zur gemessenen Variante an, der Fall, den klassische Tools außen vor lassen.
Das konkrete Ergebnis: Die Beanstandung „Properly size images“ verschwindet, weil der Browser endlich die richtige Größe herunterlädt, die, die Ihr Layout tatsächlich verlangt.
Zusammengefasst
srcset= eine Speisekarte mit Größen. sizes = die Auswahlanweisung. Ohne Letzteres ist Ersteres fast nutzlos.- Der mobile DPR (×2, ×3) verdoppelt oder verdreifacht die Zielbreite, daher der Overdownload.
- Diagnose mit Rendered size vs. Current source in den DevTools.
- Die Lösung = ein
sizes, das Ihrem realen Layout treu bleibt, plus die richtigen Varianten. Von Hand ist das mühsam und fehleranfällig, gemessen und automatisiert ist es zuverlässig.