Der eigene Onlineshop lädt langsam – wie lassen sich Probleme beim Laden von Bildern ermitteln?

Eine langsame Ladezeit der eigenen Website ist ein häufiger Anlass, Bilder zu überprüfen. Dennoch sollten Bilder nicht allein deshalb pauschal komprimiert werden, weil eine Seite viele davon enthält. Große Bilder im sichtbaren Bereich, die zu langsam geladen werden, verzögert erkannte Bildanfragen, schlechte Verbindungen zu Knoten in Übersee oder langsame Serverantworten können dazu führen, dass Nutzer den Eindruck haben, die Bilder würden „einfach nicht erscheinen“. Ermitteln Sie zunächst, welche Bilder und welche Ladephase die Seite verlangsamen. Entscheiden Sie dann, ob Sie die Dateien, den Seitencode oder die Auslieferungskette überprüfen müssen.

Eine zielführende technische Analyse sollte drei Fragen beantworten: Welches Bild ist langsam? Entsteht die Verzögerung vor dem Start der Anfrage oder während der Übertragung? Und werden die Hauptinhalte für Nutzer im Zielmarkt nach der Optimierung tatsächlich schneller sichtbar?

Zunächst prüfen, ob Bilder der Hauptengpass sind

Öffnen Sie im Chrome-Entwicklertool den Bereich „Network“ und aktivieren Sie „Disable cache“, um die Anfragen während des Seitenaufrufs aufzuzeichnen. Testen Sie nach dem ersten Aufruf mit aktiviertem Cache erneut, damit sich das Erlebnis bei leerem Cache mit dem bei wiederholten Besuchen vergleichen lässt. Filtern Sie nach Bildtypen und prüfen Sie Dateigröße, Anfragestart, Dauer und Wasserfalldiagramm. Verwenden Sie beim Test Netzwerkbedingungen, die denen der Nutzer im Zielmarkt möglichst nahekommen, und untersuchen Sie die Desktop- und Mobilversion getrennt.

Führen Sie außerdem Lighthouse oder PageSpeed Insights aus und prüfen Sie die Diagnosen zum Largest Contentful Paint (LCP). Ist das LCP-Element ein Bild im sichtbaren Bereich und erscheint es erst spät, ist das ein klarer Ansatzpunkt für die Analyse. Ist das LCP-Element Text oder reagieren HTML bzw. Skripte langsam, kann die Bildoptimierung zwar weiterhin sinnvoll sein, muss aber das Problem mit der langsamen Anzeige des sichtbaren Seitenbereichs nicht lösen.

Betrachten Sie nicht nur die Gesamtdauer der Anfrage. Klicken Sie auf das verdächtige Bild, um „Timing“ aufzurufen, und beurteilen Sie die Ergebnisse zusammen mit dem Wasserfalldiagramm:

• Die Anfrage startet spät: Das Bild wird möglicherweise erst nach dem Rendern durch JavaScript erkannt oder fälschlicherweise per Lazy Loading geladen.
• Die Wartezeit bis zur Antwort ist lang: Prüfen Sie den Ursprungsserver des Bildes, den Cache-Status des CDN und die Netzwerkverbindung zur Zielregion.
• Das Herunterladen der Inhalte dauert lange: Beurteilen Sie die tatsächlich übertragene Dateigröße zusammen mit der Bandbreite und den Bildabmessungen. Prüfen Sie zuerst große Dateien.
• Das Bild wird auch nach dem Download nur langsam angezeigt: Prüfen Sie die Bilddekodierung, Aufgaben im Hauptthread sowie Stylesheets oder Skripte, die das Rendering blockieren könnten.

Die im Network-Bereich angezeigte Übertragungsgröße muss nicht der Originaldateigröße des Bildes entsprechen. Achten Sie auch auf Weiterleitungen, fehlgeschlagene Wiederholungsversuche, Cache-Treffer und darauf, ob dasselbe Bild unter verschiedenen URLs mehrfach angefordert wird. Bei internationalen Websites sollten Sie möglichst in der Region Ihrer wichtigsten Kunden oder über lokale Testknoten erneut testen. Andernfalls können lokale Ergebnisse Probleme beim regionsübergreifenden Zugriff verschleiern.

Bildabmessungen, Format und tatsächlichen Verwendungszweck prüfen

Prüfen Sie zuerst das Hauptbild im sichtbaren Bereich, große Produktbilder auf Detailseiten und Banner für Mobilgeräte. Diese Bilder können viel Datenvolumen beanspruchen und beeinflussen direkt, wie schnell Nutzer die Hauptinhalte sehen. Vergleichen Sie im Browser die tatsächliche Anzeigengröße mit den Ressourcenabmessungen. Wird ein hochauflösendes Original heruntergeladen, obwohl auf der Seite nur ein kleines Produktvorschaubild erscheint, sollten Sie eine für diesen Anzeigebereich geeignete Version erstellen, statt einfach nur stärker zu komprimieren.

Responsive Seiten können mit srcset und sizes Bilder in verschiedenen Größen bereitstellen, aus denen der Browser anhand des Layouts und der Geräteeigenschaften auswählt. Unterscheidet sich der Bildausschnitt auf Mobilgeräten deutlich von dem auf Desktopgeräten, können Sie mit picture auch unterschiedliche Bilder bereitstellen. Prüfen Sie, ob sizes zum tatsächlichen Layout passt. Andernfalls kann der Browser weiterhin eine zu große Datei auswählen.

Die Formatwahl sollte sich nach dem Bildinhalt und den Kompatibilitätsanforderungen richten. Bei Fotos und realen Produktaufnahmen können WebP oder AVIF geprüft werden. Bei Materialien mit transparentem Hintergrund sollten Sie außerdem überprüfen, ob das Zielformat und die verwendeten Tools unterstützt werden. Sorgen Sie für eine kompatible Rückfalllösung und vergleichen Sie Dateigröße, Bildqualität und Dekodierungsleistung nach der Konvertierung. Ein neueres Format ist nicht zwangsläufig bei jedem Bild kleiner. Achten Sie nach der Komprimierung insbesondere auf Textkanten, Produktstrukturen und Markenlogos.

Bei der Produktdarstellung sind auch geschäftliche Anforderungen zu berücksichtigen: Für Vorschaubilder in Listen reicht eine kleinere Größe, während Detailansichten mit Zoomfunktion, Materialstrukturen und Modellkennzeichnungen ausreichend scharf sein müssen. Sie können je nach Verwendungszweck separate Vorschaubilder, Detailbilder und Zoomansichten erstellen. So vermeiden Sie, dass an allen Stellen dasselbe Original verwendet wird, und verhindern zugleich, dass für eine geringere Datenmenge Informationen verloren gehen, die Einkäufer erkennen müssen.

Inhalte im sichtbaren Bereich priorisieren, Bilder außerhalb davon nach Bedarf laden

Das LCP-Bild im sichtbaren Bereich sollte vom Browser möglichst früh erkannt werden. Stellen Sie die Bild-URL bevorzugt direkt im initialen HTML bereit, statt sie erst nach der Ausführung eines Skripts einzufügen. Verwenden Sie für dieses Bild im sichtbaren Bereich nicht loading="lazy". Wenn bestätigt ist, dass es sich um eine wichtige Ressource handelt, können Sie den Hinweis fetchpriority="high" prüfen, um dem Browser eine höhere Priorität zu signalisieren. Weisen Sie jedoch nicht mehreren Bildern gleichzeitig eine hohe Priorität zu, damit sie nicht mit wichtigen Ressourcen wie Schriftarten und Stylesheets um Bandbreite konkurrieren.

Wird ein großes Bild im sichtbaren Bereich als CSS-Hintergrund geladen, muss der Browser oft erst die zugehörigen Stylesheets abrufen und analysieren, bevor er das Bild erkennt. Bei Bildern, die die Hauptinhalte tragen, können Sie prüfen, ob sich stattdessen ein HTML-Bildelement eignet. Auch ein Preload kann in Betracht gezogen werden, wenn die Ressourcen-URL feststeht und tatsächlich eine Verzögerung beim Erkennen vorliegt. URL und responsive Konfiguration des Preloads müssen zur letztlich verwendeten Ressource passen, andernfalls kann das Bild doppelt heruntergeladen werden.

Für Produktlisten, lange Detailbilder und Empfehlungen außerhalb des sichtbaren Bereichs kann natives Lazy Loading sinnvoll sein, um die Zahl der anfänglichen Anfragen zu verringern. Scrollen Sie beim Testen nach unten und prüfen Sie, ob die Bilder rechtzeitig erscheinen. Geben Sie den Bildern außerdem Breiten- und Höhenangaben oder ein geeignetes Seitenverhältnis, damit der Seiteninhalt beim Laden nicht verschoben wird. Prüfen Sie auch Karussells: Werden mehrere große, zunächst unsichtbare Bilder sofort geladen, kann das den Aufbau des sichtbaren Bereichs verlangsamen. Das zuerst sichtbare Bild sollte jedoch weiterhin priorisiert werden.

Wenn Bilder auch nach der Optimierung noch langsam laden, die Auslieferungskette prüfen

Wenn dasselbe Bild lokal schnell, im Zielmarkt aber langsam lädt, prüfen Sie, ob das CDN die Zielregion abdeckt und ob die Anfrage einen Cache-Treffer erzielt. Die Caching-Strategie muss zur Aktualisierung der Bilder passen: Für unveränderte Ressourcen eignet sich eine lange Cache-Dauer. Bei aktualisierten Bildern können Sie URLs mit Versionsinformationen verwenden, damit Nutzern nicht weiterhin die alte Version angezeigt wird. Signaturparameter oder häufig wechselnde Abfrageparameter können ebenfalls die Cache-Trefferquote beeinträchtigen. Prüfen Sie dies im Zusammenhang mit der Serverkonfiguration.

Werden Bilder auf einer Drittanbieter-Domain gespeichert, sollten Sie auch die Namensauflösung, den Verbindungsaufbau, Weiterleitungen und die Verfügbarkeit des Dienstes untersuchen. Eine domainübergreifende Verbindung benötigt Zeit. Ob sich Optimierungen wie Preconnect lohnen, sollte jedoch anhand der tatsächlichen Wartezeiten im Wasserfalldiagramm beurteilt werden. Prüfen Sie bei internationalen Shops außerdem Seiten in verschiedenen Sprachen und Regionen sowie Werbe-Landingpages getrennt, damit keine Seitenvorlage auf ein nicht optimiertes Originalbild verweist.

Unter gleichen Bedingungen erneut testen und prüfen, ob das Problem behoben ist

Zeichnen Sie nach den Änderungen dieselbe Seite erneut auf und verwenden Sie dabei dieselben Gerätetypen, Netzwerkbedingungen und Testregionen. Vergleichen Sie den Anfragestart, die Übertragungsgröße und die Downloadzeit der wichtigen Bilder im sichtbaren Bereich sowie den LCP. Da einzelne Tests durch Netzwerkschwankungen beeinflusst werden können, sollten Sie die Messung wiederholen und prüfen, ob die Ergebnisse stabil sind. Wenn Leistungsdaten echter Nutzer vorliegen, sollten Sie auch diese Daten aus dem Zielmarkt berücksichtigen.

Prüfen Sie abschließend, ob die Optimierung neue Probleme verursacht hat: Ist das Bild im sichtbaren Bereich weiterhin scharf? Wird auf Mobilgeräten die passende Größe ausgewählt? Erscheinen Bilder mit Lazy Loading beim Scrollen rechtzeitig? Werden aktualisierte Bilder korrekt aus dem Cache abgerufen? Weniger Bildanfragen oder kleinere Dateien sind lediglich Zwischenindikatoren. Entscheidend für weitere Anpassungen ist, ob Nutzer die Seite schneller und vollständig nutzen können.