Ein 1920 Pixel breites Bild auf einer Seite wird auch von Handynutzern vollständig geladen und dann auf dem Display auf 390 Pixel herunterskaliert – fünfmal so viel Bandbreite und ein langsamerer Aufbau, ganz ohne Nutzen. Mit srcset wählt der Browser die Version, die zum Bildschirm passt, vorausgesetzt, Sie haben diese Versionen erzeugt.
Warum ein einzelnes Bild nicht reicht
Der LCP-Wert in den Core Web Vitals ist meist das große Bild im sichtbaren Bereich. Liefert man einem Handy eine 1920 Pixel breite Datei mit 400 KB, schafft der LCP selten die 2,5 Sekunden; eine 480 Pixel breite Version mit 40 KB ist bei gleicher Verbindung um eine Größenordnung schneller. Googles Seitenerfahrungs-Signal liest genau diese Zahl.
Umgekehrt wirkt ein 768 Pixel breites Bild auf einem großen Desktop-Monitor weich. Deshalb mehrere Größen, aus denen der Browser wählt.
Eine praxistaugliche Breakpoint-Tabelle
Die Breakpoints richten sich nach der tatsächlich dargestellten Breite des Bildes auf der Seite, nicht nach dem Viewport. Für die beiden häufigsten Fälle, ganzbreite Banner und Abbildungen im Artikel:
- Ganzbreite Bilder (Hero, Banner): 480, 768, 1200, 1920. Handy, Tablet, Laptop, großer Monitor.
- Artikelabbildungen (Inhaltsspalte bis etwa 800): 400, 800, 1200; die 1200 bedient Bildschirme mit 1,5x–2x.
- Vorschaubilder und Karten (dargestellt mit etwa 300): 300 und 600.
Mehr Stufen sind nicht besser. Jede bedeutet einen weiteren Export und eine weitere Datei, die gespeichert werden muss, und Browser verkraften eine Abweichung; Stufen im Abstand von 1,5–2x sind der Sweet Spot. Vier Stufen decken mehr als neun von zehn Gerätekombinationen ab.
Braucht man 2x-Versionen?
Retina- und die meisten Handy-Displays arbeiten mit 2x–3x Pixeldichte; ein mit 400 Pixel Breite dargestelltes Bild braucht dort 800 Pixel, um scharf zu wirken. Die größeren Stufen der Tabelle dienen schon als 2x-Version der kleineren – 768 ist 2x für ein 390 Pixel breites Handy, 1200 ist 2x für eine 600 Pixel breite Spalte.
Ein eigener „@2x“-Satz ist daher überflüssig. Halten Sie den Abstand zwischen den Stufen bei etwa 2x, und der Browser nimmt je nach Dichte die höhere.
Format: erst WebP, JPG als Rückfall
Bei gleicher Qualität ist WebP 25–35 Prozent kleiner als JPG, und jeder moderne Browser unterstützt es. Exportieren Sie WebP in jeder Größe und halten Sie über das picture-Element ein JPG als Rückfall für alte Browser bereit; spielen Browser von vor 2020 für Ihr Publikum keine Rolle mehr, genügt WebP allein.
AVIF ist noch kleiner, wird im Browser aber weit langsamer kodiert, was bei großen Stapeln wehtut. AVIF, WebP und JPEG im Vergleich behandelt die Abwägung im Detail.
Den ganzen Satz im Stapel exportieren
Legen Sie die Quellbilder in Bilder-Stapelverarbeitung ab und starten Sie pro Stufe einen Durchlauf, wobei Sie jedes Mal Breite und Suffix ändern:
- Größe: Breite 480, Kleine Bilder vergrößern erlauben aus, Ausgabe WebP mit 80 Prozent, Suffix -480.
- Dieselben Einstellungen bei 768 mit Suffix -768; danach 1200; danach 1920.
- Für ein JPG als Rückfall die Ausgabe auf JPG stellen, die Suffixe beibehalten und erneut starten.
Jeder Durchlauf dauert Sekunden, und das ZIP enthält bereits hero-480.webp, hero-768.webp und so weiter, fertig für den Bilderordner. Lassen Sie das Vergrößern ausgeschaltet, damit ein Original mit 1000 Pixeln nie auf 1920 gestreckt wird.
Um den Größenunterschied je Stufe an einem einzelnen Bild zu sehen, probieren Sie Bildgröße ändern mit einer Datei.
Das HTML schreiben
Für ein ganzbreites Bild:
<img src="hero-1200.jpg"
srcset="hero-480.webp 480w, hero-768.webp 768w, hero-1200.webp 1200w, hero-1920.webp 1920w"
sizes="100vw" width="1920" height="1080" alt="...">Bei Artikelabbildungen setzen Sie sizes auf die tatsächliche Breite, zum Beispiel sizes="(max-width: 840px) 100vw, 800px". Geben Sie immer width und height an, damit der Browser den Platz reserviert und die Seite nicht springt.
Ergänzen Sie danach die Tipps zu Lazy Loading und Kompression aus Bilder schneller laden lassen, und der Bildanteil Ihres Performance-Scores ist im Grunde ausgereizt.