Der Server antwortet in 200 Millisekunden, die Seite ist trotzdem träge. In den meisten Fällen liegt das an den Bildern, und zwar nicht daran, dass es zu viele sind, sondern daran, dass sie in einer Größe ausgeliefert werden, die nie jemand sieht.
Vier Stellschrauben entscheiden über die Bildlast: die tatsächlichen Abmessungen, das Dateiformat, das verzögerte Laden unterhalb des sichtbaren Bereichs, und die Größenangaben im Markup. Die ersten drei sparen Datenmenge, die vierte spart keine, verhindert aber Layoutsprünge und geht als eigene Kennzahl in die Bewertung ein.
1. Abmessungen: der größte Hebel
Der häufigste Befund lautet: Ein Bild wird mit 2560 Pixel Breite ausgeliefert und auf 420 Pixel dargestellt. Der Browser lädt die vollen Daten und wirft den größten Teil weg.
Als Anhaltspunkt für die nötige Breite:
| Verwendung | Anzeigebreite | Datei sollte haben |
|---|---|---|
| Kartenbild in einem Raster | ca. 400 px | 800 bis 900 px |
| Bild in einem Textblock | ca. 700 px | 1400 px |
| Bild über die volle Breite | bis 1320 px | 1800 bis 2000 px |
| Logo, Symbol | beliebig | SVG, keine Pixelgrafik |
Die doppelte Breite deckt Bildschirme mit hoher Punktdichte ab. Mehr als das Doppelte bringt keinen sichtbaren Gewinn mehr.
2. Format: WebP als Standard
WebP liefert bei vergleichbarer Qualität deutlich kleinere Dateien als JPEG und wird von allen aktuellen Browsern unterstützt. Bei Fotos sind Einsparungen von dreißig bis fünfzig Prozent üblich, ohne dass ein Unterschied sichtbar wird.
Zwei Hinweise aus der Praxis:
- Qualität um 80 genügt. Höhere Werte vergrößern die Datei spürbar, ohne sichtbaren Gewinn.
- Zusatzdaten entfernen. Kameradateien enthalten Aufnahmeort, Gerätemodell und Farbprofile. Das sind schnell mehrere hundert Kilobyte, und es ist zugleich eine Datenschutzfrage, wenn Aufnahmeorte veröffentlicht werden.
Für Symbole und Logos gilt etwas anderes: Dort ist SVG richtig, weil es in jeder Größe scharf bleibt und meist nur wenige Kilobyte groß ist.
3. Verzögertes Laden, aber nicht überall
Bilder unterhalb des sichtbaren Bereichs sollten erst geladen werden, wenn sie in die Nähe kommen. Das erledigt das Attribut loading="lazy".
Der Fehler, der dabei häufig gemacht wird: Auch das oberste Bild bekommt dieses Attribut. Genau dieses Bild ist aber in der Regel das größte sichtbare Element und damit maßgeblich für die Kennzahl, die misst, wann der Hauptinhalt erscheint. Verzögertes Laden verschlechtert sie messbar.
Regel: Die ersten zwei bis drei Bilder ohne Verzögerung, das oberste zusätzlich mit fetchpriority="high". Alles Weitere verzögert.
4. Der Punkt, den fast alle übersehen
Jedes Bild braucht width und height im Markup. Nicht zur Darstellung, dafür sorgt das Stylesheet, sondern damit der Browser den Platz reservieren kann, bevor die Datei da ist.
Ohne diese Angaben passiert Folgendes: Die Seite wird mit Text aufgebaut, dann trifft das Bild ein und schiebt alles nach unten. Wer gerade lesen wollte, verliert die Zeile, und wer klicken wollte, trifft etwas anderes. Dieses Verschieben wird als eigene Kennzahl gemessen und geht in die Bewertung ein.
Prüfen lässt sich das in der Konsole:
let ohne = 0;
document.querySelectorAll('img').forEach(i => {
if (!i.getAttribute('width') || !i.getAttribute('height')) { ohne++; console.log(i.src); }
});
console.log('Bilder ohne Größenangabe:', ohne);Der Wert sollte null sein. Bei Themes, die Bilder direkt im Template ausgeben statt über die Bildfunktionen des Systems, ist er es fast nie.
Was nichts bringt
Zwei verbreitete Ratschläge, die selten etwas ändern:
Verlustfreie Komprimierung als alleinige Maßnahme. Sie spart bei Fotos wenige Prozent. Wenn das Bild in vierfacher Größe ausgeliefert wird, ist das bedeutungslos. Erst Abmessungen, dann Format, dann Feinschliff.
Ein Auslieferungsnetzwerk für eine regionale Website. Es verkürzt den Weg zu weit entfernten Besuchern. Wenn deine Besucher im Umkreis von dreihundert Kilometern sitzen, ist der Gewinn kaum messbar, und du handelst dir eine zusätzliche externe Verbindung ein.
Ein realistischer Zielwert
Für eine Informationsseite mit Fotos ist eine Gesamtgröße von unter einem Megabyte je Seite gut erreichbar, wenn die vier Punkte oben stimmen. Der übliche Ausgangswert bei Seiten aus gekauften Themes liegt oft beim Drei- bis Fünffachen, und der größte Anteil davon sind Bilder in falscher Größe.
Wie wir das angehen
Wir messen zuerst, welche Bilder tatsächlich wie groß ausgeliefert und wie groß dargestellt werden. Aus dieser Gegenüberstellung ergibt sich die Reihenfolge von selbst, und meistens sind es fünf bis zehn Dateien, die den Großteil der Last ausmachen. Mehr dazu unter Webentwicklung und Ladezeitoptimierung.
Wie groß sollten Bilder auf einer Website sein?
Etwa doppelt so breit wie die Anzeigebreite, damit auch Bildschirme mit hoher Punktdichte scharf bleiben. Ein Kartenbild mit 400 Pixel Anzeigebreite braucht also rund 800 Pixel, mehr bringt keinen sichtbaren Gewinn.
Ist WebP besser als JPEG?
Bei Fotos ja. Bei vergleichbarer Qualität sind Einsparungen von dreißig bis fünfzig Prozent üblich, und alle aktuellen Browser unterstützen das Format. Für Symbole und Logos ist SVG die bessere Wahl.
Soll ich alle Bilder verzögert laden?
Nein. Die ersten zwei bis drei Bilder sollten sofort laden, weil das oberste Bild meist das größte sichtbare Element ist und die Kennzahl für den Hauptinhalt bestimmt. Verzögertes Laden verschlechtert sie dort messbar.
Warum brauchen Bilder width und height im Markup?
Damit der Browser den Platz reserviert, bevor die Datei geladen ist. Ohne die Angaben verschiebt das eintreffende Bild den Inhalt nach unten, und dieses Verschieben wird als eigene Kennzahl bewertet.
Passend dazu
