Zum Inhalt springen
NAFRUSoftware x Entwicklung
← Blog-Startseite

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

Ein altes Objektivset für eine Schmalfilmkamera im Kasten, Weitwinkel und Teleobjektiv nebeneinander.
„Vintage Juplen Combination 8mm Movie Camera Lens Set“ von Joe Haupt, CC BY 2.0, über Wikimedia Commons. Auf 3:2 beschnitten.

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

( 00-09 ) KONTAKT

Lassen Sie uns über Ihr Vorhaben sprechen und darüber, wie NAFRU helfen kann.

Starten wir das Gespräch.