Produktgalerie und Zoom: schnelle Produktseite trotz Bildern

Für das erste Galeriebild gilt die Grundregel des Lazy Loading in umgekehrter Richtung. Bilder, die beim Laden wahrscheinlich im sichtbaren Bereich liegen, und vor allem LCP-Bilder werden nicht lazy geladen, so steht es im Leitfaden von web.dev. Die Begründung folgt dort gleich mit: Der Browser kann ein lazy markiertes Bild erst laden, wenn er weiß, wo es auf der Seite liegt, also nach dem Layout. Einen Hinweis auf die Größenordnung gab eine Auswertung von HTTP-Archive- und CrUX-Daten: Die mittlere Seite ohne Lazy Loading kam am 75. Perzentil auf einen LCP von 2.922 Millisekunden, die mittlere Seite mit Lazy Loading auf 3.546 Millisekunden (web.dev 2021). Die Autoren betonen selbst, dass das ein Zusammenhang ist und kein Nachweis, dass Lazy Loading die Verzögerung verursacht.

Eager allein reicht nicht. Das Bild muss im HTML stehen, damit der Preload-Scanner des Browsers es findet, bevor CSS und JavaScript geladen sind. Ein <img> mit src und srcset im ausgelieferten Dokument erfüllt das. Ein Bild, das ein Galerie-Skript erst einfügt, eine Adresse in data-src oder ein CSS-Hintergrund erfüllen es nicht. Als Richtwert für eine gut optimierte Seite soll die Zeit zwischen dem ersten Byte und dem Start des LCP-Downloads, die Resource Load Delay, unter 10 Prozent des LCP liegen (web.dev). Wie Sie diese Teilzeiten messen, zeigt der Beitrag zu den vier Phasen des LCP.

Bleibt die Priorität. Chrome startet Bilder mit niedriger Priorität und hebt sichtbare Bilder erst nach dem Layout an. Seit Chrome 117 bekommen die ersten fünf großen Bilder einer Seite die Priorität Medium (web.dev). Auf einer Produktseite sind das oft genau die ersten fünf Galeriebilder, und das Hauptbild teilt sich die Leitung mit vier Ansichten, die noch niemand sieht. fetchpriority="high" am ersten Bild löst das auf. Auf 17 Prozent der mobilen Seiten mit LCP-Bild steht das Attribut inzwischen (Web Almanac 2025). Warum genau ein Element die hohe Priorität bekommt und nicht mehrere, beschreibt der Beitrag zu fetchpriority und Priority Hints.

In der Shopware-Storefront ist die Grundlage dafür vorhanden. Das Galerie-Element lädt das erste Bild ohne Lazy Loading und setzt bei allen weiteren Bildern loading="lazy" (Shopware-Quellcode). fetchpriority="high" bekommt das erste Bild aber nur, wenn im Galerie-Element des Produktseiten-Layouts der Schalter „Erstes Bild priorisiert laden“ eingeschaltet ist, und in der Grundeinstellung des Elements ist er aus (Shopware-Quellcode). Wer die Layouts in den Erlebniswelten pflegt, sollte den Schalter in jedem Produktseiten-Layout prüfen. Weitere Hebel für Shopware-Shops beschreibt unsere Seite zur Shopware-Performance.

Zoom gehört in vielen Shops zur Grundausstattung der Produktseite. Die Datei dafür ist in der Regel die größte der Galerie. Lädt sie beim Seitenaufruf mit, konkurriert sie mit dem LCP-Bild um die Leitung, und das für eine Funktion, die nur ein Teil der Besucher nutzt. Arbeitet die Galerie mobil mit verkleinerten Bildern, braucht der Zoom eine höher aufgelöste Fassung, sonst vergrößert er nur die Unschärfe.

Das Muster dafür ist einfach. Im HTML steht nur die Adresse der Zoom-Datei, etwa in einem Datenattribut oder im href eines Links um das Hauptbild. Geladen wird sie bei der ersten Interaktion: beim Klick oder Tippen, beim Überfahren mit der Maus und beim Fokus per Tastatur. Hover und Fokus sind dabei der Vorlauf, denn zwischen dem Zeigen auf das Bild und dem Klick vergeht etwas Zeit, die der Download schon nutzen kann. Damit der Klick trotzdem sofort reagiert, öffnet die Zoom-Ansicht mit dem bereits geladenen Hauptbild und tauscht die große Datei ein, sobald sie dekodiert ist.

So bleibt auch die Interaktion schnell. Interaction to Next Paint bewertet die Zeit von einer Eingabe bis zum nächsten gezeichneten Bild, als gut gelten höchstens 200 Millisekunden. Ein Klick-Handler, der erst auf eine große Datei wartet, bevor er etwas zeichnet, ist dafür der falsche Aufbau. Mehr zur Interaktionszeit steht im Beitrag INP optimieren.

Shopware folgt dem Prinzip in zwei Teilen. Die Lupe auf dem Desktop setzt die Datei aus dem Attribut data-full-image erst bei der Mausbewegung über dem Bild als Hintergrund ein (Shopware-Quellcode). In diesem Attribut steht allerdings die Adresse des Originals, also der hochgeladenen Datei, nicht die einer Vorschaustufe. Wer Produktfotos direkt aus der Kamera hochlädt, liefert der Lupe damit Dateien in voller Kameraauflösung. Das Vollbild-Zoomfenster lädt seine Bilder ebenfalls erst beim Öffnen und zeigt sich, sobald alle Bilder des Fensters geladen sind, im Code kommentiert mit „load images before modal is shown“ (Shopware-Quellcode). Bei vielen Produktbildern wartet der Klick damit auf jede Datei der Galerie. Beides lässt sich im Template ändern: die Lupe auf die größte Vorschaustufe zeigen lassen und im Zoomfenster zuerst das angeklickte Bild laden.

Für die Suche ändert sich dadurch wenig. Google findet Bilder über das src-Attribut von <img>-Elementen und indexiert keine CSS-Bilder (Google Search Central). Das Hauptbild bleibt ein normales <img> mit srcset, und die große Fassung lässt sich zusätzlich über eine Bild-Sitemap nennen.

Wählt jemand eine andere Farbe, wechselt meist auch das Bild. In der Shopware-Storefront fragt die Produktseite dafür die Adresse der gewählten Variante ab und ruft sie dann als neue Seite auf (Shopware-Quellcode). Für den Browser ist das eine vollständige Navigation: neues Dokument, neue Galerie, neuer LCP. Liegt die Seite im HTTP-Cache, geht das schnell. Liegt sie dort nicht, wartet der Besucher auf den Server, und das mitten in einer Kaufentscheidung.

Die Alternative ist ein Teilwechsel: Die Seite bleibt stehen, und nur Galerie, Preis und Verfügbarkeit tauschen ihren Inhalt. Für die Galerie heißt das:

Ein Teilwechsel hat Folgen für die Messung. Der neue Inhalt ist keine neue Seite, also misst der Browser für ihn keinen eigenen LCP. Shops, die so navigieren, sollten wissen, wie Soft Navigations gemessen werden; das behandelt der Beitrag Soft Navigations in CrUX. Ob sich der Umbau lohnt, entscheidet die Messung: Wie oft wechseln Besucher die Variante, und wie lange dauert der Wechsel heute?

Ob die Galerie richtig lädt, zeigt ein Blick in die Entwicklerwerkzeuge des Browsers. Im Performance-Bereich steht, welches Element der Browser als LCP gewertet hat und wie sich die Zeit auf die vier Teilphasen verteilt. Im Netzwerk-Wasserfall lässt sich nach Bildern filtern: Das Hauptbild sollte gleich nach dem Dokument starten, die Folgebilder danach mit niedriger Priorität, und die Zoom-Datei taucht erst nach dem ersten Klick auf das Bild auf.

Labormessungen zeigen das Verhalten, Felddaten zeigen die Wirkung. Produktseiten sind Unterseiten, und dort liegt die Interaktion auf Mobilgeräten deutlich zurück: Mobil erreichen 80 Prozent der Startseiten einen guten INP, aber nur 69 Prozent der Unterseiten (Web Almanac 2025). Galerie-Skripte, Lupen und Variantenwahl sind typische Kandidaten dafür. Werten Sie deshalb die Produktvorlage getrennt aus, wie im Beitrag Vorlage statt Startseite beschrieben, und prüfen Sie LCP, CLS und INP am 75. Perzentil.

Bei einer Analyse gehen wir genau diese Liste für Ihre Produktvorlage durch, mit Laborwerten für Desktop und Mobilgeräte und, soweit vorhanden, mit CrUX-Felddaten Ihrer Produktseiten. Das Ergebnis ist eine Reihenfolge der Änderungen nach Wirkung, kein Pauschalpaket. Wie wir dabei vorgehen, steht unter technische Analyse; die Grundlagen der Messwerte erklärt unsere Seite zu den Core Web Vitals. Für Shops mit großen Sortimenten lohnt außerdem ein Blick auf PageSpeed im E-Commerce.