Ein Bild, das die ganze Seite ausbremst
Wenn mich jemand fragt, warum seine Website „sich zäh anfühlt", schaue ich zuerst auf die Bilder — und in den allermeisten Fällen liegt es genau dort. Typisches Muster: Ein großformatiges Titelbild ganz oben, direkt aus der Kamera, mehrere Megabyte schwer. Genau dieses Bild ist auf den meisten Seiten das Largest Contentful Paint-Element — also das Element, dessen Ladezeit Google als Kennzahl für „gefühlte Geschwindigkeit" heranzieht. Ist es zu groß, ist die Seite langsam. Nicht ein bisschen: messbar, im Sekundenbereich, genau da, wo Besucher ungeduldig werden.
Rechenbeispiel: ein 4-MB-Foto auf dem Handy
Nehmen wir ein einzelnes, ganz normales Foto: 4 MB, unbearbeitet vom Smartphone. 4 MB sind rund 32 Megabit, die über die Leitung müssen. Je nach Verbindung dauert allein diese eine Übertragung:
| Verbindung | Real nutzbare Rate | Übertragung 4 MB |
|---|---|---|
| Schnelles Glasfaser | ~200 Mbit/s | ≈ 0,16 s |
| DSL / Kabel (Durchschnitt) | ~50 Mbit/s | ≈ 0,6 s |
| 4G mobil (realistisch) | ~10 Mbit/s | ≈ 3,2 s |
| Gedrosselt / voller Zug | ~2 Mbit/s | ≈ 16 s |
Und das ist ein Bild. Der LCP-Zielwert von Google liegt bei 2,5 Sekunden für die gesamte Seite. Ein Titelbild, das mobil allein 3,2 Sekunden lädt, reißt dieses Budget im Alleingang — bevor überhaupt Text, Schrift oder Interaktivität dran waren. Als WebP in passender Größe wären aus den 4 MB rund 200 KB geworden, und aus 3,2 Sekunden etwa 0,16.
Der Absprung passiert in den ersten Sekunden
Was danach passiert, ist gut untersucht: Je länger die Seite zum Erscheinen braucht, desto mehr Menschen sind schon wieder weg. Auf dem Desktop verzeiht man ein, zwei Sekunden — auf dem Handy, unterwegs, mit halbem Balken, nicht. Und mobil kommt ein zweiter Faktor dazu: Datenvolumen. Ein 9-MB-Seitenaufruf (drei Bilder à 3 MB) frisst spürbar am Tarif. Wer auf Reisen oder mit knappem Volumen surft, merkt sich, welche Seiten „Datenfresser" sind — und kommt nicht wieder.
Google sieht die langsamen Bilder
Seit die Core Web Vitals ein bestätigtes Ranking-Signal sind, ist das Thema nicht mehr nur eine Frage der Höflichkeit gegenüber dem Besucher. Zwei der drei Kennzahlen hängen direkt an Bildern: LCP (meist ein Bild) und CLS (Layout-Sprünge, oft durch Bilder ohne feste Maße). Wer hier schlecht abschneidet, verschenkt Sichtbarkeit an schnellere Wettbewerber. Wie man Bilder gezielt suchmaschinenfreundlich aufbereitet, steht im Beitrag Bilder-SEO.
CLS: das Bild, das den Text wegschubst
Ein unterschätzter Nebeneffekt unoptimierter Einbindung: Bilder ohne angegebene Breite und Höhe. Der Browser weiß erst beim Laden, wie viel Platz das Bild braucht — und schiebt den bereits gelesenen Text nach unten, sobald es eintrifft. Dieses Ruckeln ist der Cumulative Layout Shift, und er ist nicht nur nervig, sondern zählt ebenfalls in die Bewertung. Die Lösung kostet nichts: feste width/height bzw. ein aspect-ratio im CSS.
Über ein ganzes Projekt hochgerechnet
Ein einzelnes zu großes Bild ist ärgerlich — über eine ganze Website multipliziert sich der Effekt. Was aus „drei Bildern pro Seite, ein paar Megabyte pro Bild" auf 1200 Seiten an Speicher und Traffic wird, habe ich in einer eigenen Beispielrechnung durchgezogen: Wie groß wird eine Website durch unoptimierte Bilder? Die kurze Antwort: zweistellige Gigabyte, mit einem Optimierungshebel von etwa Faktor 15.
Woran ich erkenne, dass Bilder das Problem sind
Die Diagnose dauert keine fünf Minuten, und man braucht dafür kein teures Werkzeug:
- Netzwerk-Tab öffnen (in den Entwicklertools des Browsers), Seite laden, nach Dateigröße sortieren. Stehen ganz oben Bilder mit mehreren MB, ist die Ursache gefunden.
- Einzelbild prüfen. Ziehe ein verdächtiges Bild in das Bild-Info-Tool — es zeigt Dimensionen, Format und Dateigröße lokal an, ganz ohne Upload. Ein 4000-Pixel-Bild in einem 800-Pixel-Slot ist ein sicheres Zeichen.
- LCP-Element identifizieren. Lighthouse oder die Web-Vitals-Anzeige markieren das langsamste Element — auffällig oft ist es das Titelbild.
Der Ausweg — in drei Handgriffen
Ist die Ursache gefunden, ist die Behebung meist trivial: auf die Anzeigegröße skalieren, ins moderne Format konvertieren und komprimieren. Alles läuft bei JNRT Pixel lokal im Browser, ohne dass ein Bild dein Gerät verlässt. Den vollständigen Ablauf inklusive Einbindung beschreibt der Komprimier-Leitfaden.
Quellen
web.dev — Web Vitals · web.dev — Largest Contentful Paint (LCP) · web.dev — Cumulative Layout Shift (CLS) · Google Search Central — Page Experience.