Ihre Bilder sind optimiert – warum ist die Website trotzdem langsam?

Das Hero-Bild ist als WebP gespeichert. Die Dateigröße sieht vernünftig aus. Lighthouse zeigt trotzdem eine langsame Hauptansicht, und auf dem Smartphone erscheint zuerst eine fast leere Fläche.

Das klingt widersprüchlich, ist aber ein sehr typisches Website-Problem: Ein Bild kann komprimiert sein und trotzdem falsch ausgeliefert werden.

Performance scheitert selten an nur einer großen Datei. Häufiger liegt es an mehreren kleinen Entscheidungen, die zusammen dafür sorgen, dass der Browser das wichtigste Bild zu spät entdeckt, die falsche Größe lädt oder Platz erst nachträglich reserviert. Für Nutzer fühlt sich das nicht wie ein technisches Detail an. Es fühlt sich an wie eine langsame, unruhige oder unfertige Website.

Red Flag 1: Das wichtigste Bild wird lazy geladen

Lazy Loading ist für Bilder unterhalb des sichtbaren Bereichs sinnvoll. Beim zentralen Hero- oder Produktbild kann es jedoch genau das Gegenteil bewirken.

Wenn das vermutlich größte sichtbare Element erst verzögert angefordert wird, wartet die Seite auf eine Ressource, die eigentlich früh geladen werden sollte. Besonders problematisch wird es, wenn das Bild zusätzlich durch JavaScript, einen Slider oder eine CSS-Hintergrunddefinition versteckt ist und der Browser es deshalb spät entdeckt.

Prüfen Sie:

• Hat das erste große sichtbare Bild loading="lazy"?
• Wird es erst nach einer Client-Hydration oder Slider-Initialisierung eingefügt?
• Steckt die Bild-URL nur in CSS oder einem JavaScript-Objekt?
• Gibt es mehrere konkurrierende Hero-Bilder im DOM?

Für ein tatsächlich kritisches Bild kann fetchpriority="high" dem Browser zusätzlich signalisieren, dass diese Ressource wichtiger ist. MDN weist ausdrücklich darauf hin, diese Priorisierung sparsam zu verwenden: Wenn jedes Bild wichtig sein soll, ist am Ende keines mehr wirklich priorisiert.

Red Flag 2: Mobilgeräte erhalten das Desktop-Bild

Ein 2.000 Pixel breites Bild kann auf einem großen Monitor sinnvoll sein. Auf einem Smartphone, auf dem es mit 360 oder 430 CSS-Pixeln dargestellt wird, ist dieselbe Datei oft unnötig schwer.

Responsive Images bedeuten nicht nur, dass sich ein Bild per CSS verkleinert. Der Browser sollte über srcset und sizes eine Datei auswählen können, die zur tatsächlichen Darstellung und Pixeldichte passt. Chrome beschreibt das Grundprinzip sehr klar: Eine Seite sollte möglichst keine Bilder ausliefern, die deutlich größer sind als ihre gerenderte Größe.

Ein häufiger Fehler ist ein vorhandenes srcset mit einem unpassenden sizes-Wert. Dann wählt der Browser trotz mehrerer Varianten weiterhin eine übergroße Datei.

Prüfen Sie in den DevTools nicht nur die sichtbare Breite, sondern auch:

• die tatsächlich geladene Bild-URL,
• die übertragenen Bytes,
• die intrinsischen Bildabmessungen,
• den verwendeten sizes-Wert,
• das Verhalten bei verschiedenen Viewport-Breiten und Gerätepixeldichten.

Red Flag 3: Breite und Höhe fehlen

Wenn der Browser die Abmessungen eines Bildes nicht kennt, kann er den benötigten Platz unter Umständen erst nach dem Download reservieren. Text, Buttons oder Formulare springen dann sichtbar.

Das ist mehr als ein kosmetisches Problem. Ein Nutzer will gerade auf einen Button tippen, das Bild erscheint, und der Button rutscht weg. Solche Layout-Verschiebungen erzeugen Fehlklicks und lassen eine Website technisch unsauber wirken.

Geben Sie Bildern verlässliche width- und height-Attribute oder ein passendes Seitenverhältnis. Responsive CSS kann das Bild weiterhin flexibel skalieren. Entscheidend ist, dass der Browser den Platz vor dem vollständigen Laden berechnen kann.

Red Flag 4: Das Format ist modern, aber die Kodierung schlecht

WebP oder AVIF im Dateinamen ist kein Qualitätsbeweis. Ein Bild kann auch in einem modernen Format unnötig groß sein, wenn:

• die Qualitätsstufe zu hoch gewählt wurde,
• Metadaten nicht entfernt wurden,
• fotografische Inhalte verlustfrei gespeichert werden,
• Transparenz oder Animation unnötig teuer ist,
• bei jeder CMS-Größe dieselbe Originaldatei verwendet wird.

Chrome empfiehlt unter anderem passende Dimensionen, moderne Formate, Kompression und responsive Varianten. Der sinnvolle Vergleich lautet nicht einfach „JPEG gegen WebP“, sondern: Welche sichtbare Qualität brauchen wir bei dieser konkreten Größe und Nutzung?

Red Flag 5: Die Bild-Pipeline endet beim Upload

Viele Websites optimieren Bilder nur einmal beim Launch. Danach laden Redakteure neue Dateien direkt aus Kamera, Canva oder Stock-Portalen hoch. Innerhalb weniger Monate besteht die Startseite wieder aus mehreren Megabyte.

Ein belastbarer Prozess braucht deshalb mehr als eine einmalige Aufräumaktion:

1. maximale Upload-Größen und Abmessungen,
2. automatische Derivate für relevante Breakpoints,
3. sinnvolle Standardqualität,
4. moderne Formate mit Fallback,
5. feste Regeln für Hero-, Karten- und Content-Bilder,
6. regelmäßige Performance-Prüfungen nach Inhaltsänderungen.

Der schnelle Selbsttest

Öffnen Sie Ihre wichtigste Landingpage in einem privaten Browserfenster, aktivieren Sie in den DevTools eine mobile Netzwerkdrosselung und laden Sie die Seite neu. Beobachten Sie nicht nur den Score. Fragen Sie:

• Erscheint das wichtigste Bild früh oder bleibt lange eine leere Fläche?
• Springt Inhalt, sobald Bilder eintreffen?
• Wird auf Mobilgeräten eine überraschend große Datei übertragen?
• Laden Bilder unterhalb des sichtbaren Bereichs bereits sofort?
• Kommt das Hero-Bild aus HTML oder wird es erst durch JavaScript entdeckt?
• Sind dekorative Bilder klar von inhaltlich wichtigen Bildern getrennt?

Dieser Test dauert wenige Minuten und zeigt oft mehr als die pauschale Aussage „Wir verwenden bereits WebP“.

Was Website-Pflichtencheck dabei prüft

Ein Performance-Check betrachtet die vollständige Auslieferungskette: Bildabmessungen, Dateigewicht, Formate, srcset, sizes, Ladeprioritäten, Lazy Loading, Layout-Stabilität, CMS-Derivate, Cache-Verhalten und reale Darstellung auf verschiedenen Viewports.

Dabei geht es nicht darum, jedes Bild maximal kleinzurechnen. Es geht darum, das richtige Bild in der richtigen Größe zum richtigen Zeitpunkt auszuliefern.

Wenn Ihre Website trotz „optimierter Bilder“ langsam wirkt, liegt das Problem möglicherweise nicht im Bildeditor. Es liegt in der Implementierung. Genau dort lohnt sich eine strukturierte Prüfung, bevor mobile Nutzer weiter für Dateien bezahlen, die sie nie in voller Größe sehen.