3 Min. Lesezeit
In welchem Format und welcher Größe Bilder ausliefern
Schwer macht eine Seite selten der Code. Es sind Bilder, die viertausend Pixel breit geladen und mit achthundert gezeigt werden.
Furkan ÇolakDeveloper

Sehen Sie sich das Gesamtgewicht einer Seite an, und die Last tragen fast immer die Bilder: Schriften kommen auf ein paar hundert Kilobyte, Skripte auf ein paar hundert Kilobyte, Bilder dagegen mühelos auf mehrere Megabyte. Das Verhältnis ist auf den meisten Seiten dasselbe. Es hat auch eine gute Seite, denn hier ist die Korrektur am billigsten und gelingt, ohne eine einzige Codezeile anzufassen.
Die Größe kommt vor dem Format
Der häufigste Fehler ist, ein Bild in der Größe zu laden, in der es aus der Kamera kam. Ein Foto mit viertausend Pixeln Breite, in einer Karte mit achthundert dargestellt, wird vom Browser heruntergerechnet, die zusätzlichen Pixel bewirken nichts, und die Besucherin bezahlt trotzdem jedes Byte. Dreitausendzweihundert Pixel für nichts.
Die Regel ist kurz. Die ausgelieferte Breite soll das Doppelte der größten Darstellungsbreite nicht überschreiten; für Retina-Displays reicht das Doppelte reichlich, und das Dreifache bringt nichts, was jemand sehen könnte.
Diese eine Änderung senkt das Seitengewicht auf den meisten Seiten um mehr als die Hälfte, noch bevor am Format etwas geändert wurde, und kein Bild wird dabei sichtbar schlechter.
Beim Format stehen drei zur Wahl
AVIF. Erzeugt bei gleicher Bildqualität die kleinste der drei Dateien. Das Kodieren ist langsam, und weil das zur Build-Zeit anfällt, erreicht es die Besucher nie.
WebP. Fällt etwas größer aus als AVIF. Dafür kodiert es schnell, die Unterstützung reicht zurück bis zu älteren Browsern, und es kommt ohne Rückfallebene aus.
JPEG. Die Rückfallebene. Für Fotos weiterhin vertretbar, und im picture-Element steht es zuletzt, wird also nur geladen, wenn die anderen beiden nicht dekodiert werden können.
PNG bleibt für Grafiken mit harten Kanten und kleine Bilder mit Transparenz. Ein Foto als PNG auszuliefern vervielfacht die Dateigröße gegenüber demselben Foto als JPEG und gibt bei der Qualität nichts zurück.
Den Platz nicht vergessen
Breite und Höhe am Bild anzugeben lässt den Browser Platz reservieren, bevor die Datei überhaupt da ist. Fehlen sie, rutscht der Text nach unten. Dieses Rutschen wird als Cumulative Layout Shift gemessen.
Die Werte gehören auch an ein per CSS skaliertes Bild, denn der Browser liest daraus das Seitenverhältnis und erzwingt die Pixelzahlen nicht als tatsächliche Größe. Er liest nur das Verhältnis.
Die Ladereihenfolge
Das große Bild am oberen Rand ist auf den meisten Seiten das größte Inhaltselement und bestimmt damit die Messung des Largest Contentful Paint unmittelbar. Eine Datei, eine Zahl.
Setzen Sie auf dieses Bild kein Lazy Loading. Lazy Loading wurde für Bilder unterhalb des Sichtbereichs gebaut, und auf das oberste angewendet verzögert der Browser den Download absichtlich, während die Messung schlechter wird. Die Einzelheiten stehen in web.dev, „Optimize Largest Contentful Paint“.
Für alle übrigen Bilder passt Lazy Loading, weil die meisten Besucher das Seitenende nie erreichen und jene Dateien nie geladen werden.
Die Prüfliste
Vier Fragen, etwa fünf Minuten pro Seite.
Wie viele Pixel breit wird das größte Bild ausgeliefert, ist das Format AVIF oder WebP, sind Breite und Höhe angegeben? Dann noch eine Frage. Kommt das oberste Bild versehentlich mit Lazy Loading?
Stimmen alle vier, ist die Bildarbeit erledigt. Nächste Station sind die Schriften.
Empfohlene Beiträge

Eine Domain umziehen, ohne die E-Mail zu verlieren
Adress- und Mail-Einträge liegen in derselben Zone und erledigen völlig verschiedene Aufgaben. Ein Umzug berührt nur eine davon.

Eine Schriftart auswählen und richtig einbinden
Sechs Schnitte statt drei fügen der Seite ein paar hundert Kilobyte hinzu, und niemand sieht den Unterschied.

Was hreflang auf einer mehrsprachigen Website verbindet
Ein hreflang-Satz, der nicht wechselseitig ist, wird vollständig ignoriert. Jede Seite muss auch sich selbst aufführen.