Seitengeschwindigkeit-Optimierung für Ecommerce

Google misst die Seitenerfahrung anhand von drei Core Web Vitals: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS). Jede Metrik erfasst einen anderen Aspekt der Nutzererfahrung in Ihrem Shop, und alle drei fließen in Googles Ranking-Algorithmus ein.

LCP misst, wie lange es dauert, bis das größte sichtbare Element gerendert wird, typischerweise ein Hero-Bild oder Produktfoto. Google erwartet LCP unter 2,5 Sekunden. Im Ecommerce ist der Hauptverursacher nicht optimierte Produktbilder. Ein einzelnes 3-MB-Hero-Bild auf einer Kategorieseite kann den LCP auf mobilen Verbindungen über 4 Sekunden treiben.

INP hat im März 2024 First Input Delay ersetzt und misst die Reaktionsfähigkeit über die gesamte Sitzung, nicht nur bei der ersten Interaktion. Jedes Tippen, Klicken und jede Tastatureingabe zählt. Ecommerce-Seiten haben hier Schwierigkeiten wegen des umfangreichen JavaScript von Analytics-Tools, Chat-Widgets und Empfehlungs-Engines. Jedes Drittanbieter-Skript konkurriert um den Haupt-Thread und verzögert Nutzerinteraktionen.

CLS verfolgt unerwartete Layout-Verschiebungen während des Seitenladens. Auf Produktseiten passiert dies häufig, wenn Bilder ohne definierte Abmessungen laden, wenn Preisbadges nach dem initialen Rendern eingefügt werden oder wenn verzögert geladene Bewertungen den Inhalt nach unten schieben. Google verlangt einen CLS unter 0,1 für eine bestandene Bewertung.

Bilder machen 50 % bis 70 % des gesamten Seitengewichts auf den meisten Ecommerce-Seiten aus. Eine Kategorieseite mit 40 Produkten und nicht optimierten Bildern kann leicht 15 MB überschreiten. Allein die richtige Bildoptimierung kann die Ladezeit halbieren.

Konvertieren Sie alle Produktbilder ins WebP- oder AVIF-Format. WebP liefert 25 % bis 35 % kleinere Dateien als JPEG bei vergleichbarer Qualität, und AVIF steigert die Einsparung auf 50 %. Alle großen Browser unterstützen jetzt WebP, und die AVIF-Unterstützung deckt über 90 % der Nutzer ab. Liefern Sie AVIF mit WebP-Fallback über das HTML-Picture-Element.

Passen Sie Bilder an ihre Anzeigegröße an. Ein Produktthumbnail, das mit 300x300 Pixeln angezeigt wird, braucht keine 2000x2000-Quelldatei. Generieren Sie mehrere Größen zur Build-Zeit oder über die Bildtransformations-API Ihres CDN. Liefern Sie 1x-Bilder an Standard-Displays und 2x an Retina-Bildschirme mit srcset-Attributen.

Implementieren Sie Lazy Loading für Bilder unterhalb des sichtbaren Bereichs. Die erste Reihe von Produkten auf einer Kategorieseite sollte sofort laden (Eager Loading), während alles darunter loading="lazy" verwenden sollte. Dies reduziert das initiale Seitengewicht dramatisch. Ein Möbelshop, den wir optimiert haben, ging von 80 Bildern beim initialen Seitenaufruf auf 12 und senkte den LCP von 4,8 auf 1,9 Sekunden.

Der durchschnittliche Ecommerce-Shop lädt 20 bis 35 Drittanbieter-Skripte: Analytics, Heatmaps, Chat-Widgets, Bewertungsplattformen, Empfehlungs-Engines, Retargeting-Pixel und Zahlungsanbieter. Jedes Skript blockiert den Haupt-Thread, verzögert die Interaktivität und bläht das Seitengewicht auf. Das Auditieren und Verwalten dieser Skripte ist eine der wirkungsvollsten Geschwindigkeitsverbesserungen.

Beginnen Sie damit, jedes Skript zu katalogisieren, das in Ihrem Shop geladen wird. Öffnen Sie die Chrome DevTools, gehen Sie zum Netzwerk-Tab, filtern Sie nach JS und laden Sie die Seite neu. Sortieren Sie nach Größe und Ladezeit. Sie werden fast sicher Skripte finden, die nicht mehr benötigt werden, duplizierte Tracker oder Tools, die für einen Test installiert und nie entfernt wurden.

Verschieben Sie unkritische Skripte mit dem defer- oder async-Attribut. Analytics- und Marketing-Pixel müssen nicht vor dem Seitenrendering geladen werden. Verschieben Sie sie unter den sichtbaren Bereich oder laden Sie sie nach dem DOMContentLoaded-Event. Für Chat-Widgets verzögern Sie die Initialisierung, bis der Nutzer scrollt oder nach einer 5-Sekunden-Verzögerung.

Erwägen Sie die Verwendung eines Tag-Managers wie Google Tag Manager mit Trigger-basiertem Laden. Anstatt jedes Skript beim Seitenaufruf auszuführen, konfigurieren Sie Trigger, sodass Retargeting-Pixel nur auf Produktseiten feuern, Chat-Widgets nach 10 Sekunden Inaktivität laden und Bewertungs-Widgets erst laden, wenn der Bewertungsbereich in den sichtbaren Bereich scrollt. Dieser Ansatz reduzierte die Haupt-Thread-Blockierungszeit in einem Einrichtungsshop, den wir optimiert haben, um 40 %.

Time to First Byte (TTFB) misst, wie lange Ihr Server braucht, um mit dem ersten Byte HTML zu antworten. Google empfiehlt TTFB unter 800 Millisekunden, aber die besten Ecommerce-Seiten erreichen unter 200 Millisekunden. Langsames TTFB verzögert alles, was folgt: Rendering, Ressourcenladen und Interaktivität.

Shared-Hosting-Pläne können kein konsistentes TTFB für Shops mit mehr als einigen Hundert Produkten liefern. Die Datenbankabfragen zum Aufbau von Kategorieseiten mit Filterung, Sortierung und Bestandsprüfungen erfordern dedizierte Ressourcen. Wechseln Sie zu einem VPS, dedizierten Server oder einer verwalteten Ecommerce-Plattform, die die Infrastruktur-Skalierung übernimmt.

Implementieren Sie Ganzseiten-Caching für Kategorie- und Produktseiten. Die meisten Produktseiten ändern sich selten, und das Ausliefern einer gecachten HTML-Antwort eliminiert Datenbankabfragen vollständig. Varnish, Redis oder die integrierte Cache-Schicht Ihrer Plattform können TTFB von 1,5 Sekunden auf unter 100 Millisekunden für gecachte Seiten reduzieren.

Nutzen Sie ein CDN mit Edge-Caching, um statische Assets und gecachte Seiten von Standorten nahe Ihrer Kunden auszuliefern. Ein CDN reduziert die Latenz um 50 % bis 80 % für geografisch entfernte Besucher. Für internationale Shops ist dies essentiell. Ein britischer Kunde, der auf einen in den USA gehosteten Shop ohne CDN zugreift, fügt bei jeder Anfrage 150 bis 250 Millisekunden Latenz hinzu.

Der kritische Rendering-Pfad ist die Abfolge von Schritten, die der Browser unternimmt, um HTML, CSS und JavaScript in gerenderte Pixel umzuwandeln. Die Optimierung dieses Pfads bedeutet sicherzustellen, dass der Browser so schnell wie möglich sinnvollen Inhalt anzeigen kann, auch während zusätzliche Ressourcen noch geladen werden.

Fügen Sie Ihr kritisches CSS direkt in den HTML-Head ein. Kritisches CSS ist der minimale Satz an Stilen, der zum Rendern des sichtbaren Inhalts benötigt wird. Tools wie Critical oder Penthouse können dies automatisch extrahieren. Durch das Einbetten von 10 bis 15 KB kritischem CSS kann der Browser die initiale Ansicht rendern, ohne auf externe Stylesheet-Downloads zu warten.

Preloaden Sie wichtige Ressourcen, die der Browser erst spät im Parsing-Prozess entdeckt. Web-Fonts, Hero-Bilder und kritische JavaScript-Bundles sollten rel="preload"-Link-Tags im HTML-Head verwenden. Ohne Preloading entdeckt der Browser diese Ressourcen erst nach dem Parsen von CSS- oder JavaScript-Dateien, was Hunderte von Millisekunden Verzögerung hinzufügt.

Eliminieren Sie render-blockierende Ressourcen, indem Sie unkritisches CSS und JavaScript verschieben. Laden Sie Ihr vollständiges Stylesheet asynchron mit dem media="print"-Trick mit einem onload-Handler, der es zu media="all" wechselt. So kann der Browser die Seite mit eingebettetem kritischem CSS rendern, während das vollständige Stylesheet im Hintergrund heruntergeladen wird.

Bei Shopify-Shops injizieren die Liquid-Templates und App-Blöcke des Themes oft render-blockierende Skripte und Stile. Überprüfen Sie Ihre theme.liquid-Datei und verschieben Sie nicht-essentielle App-Skripte auf verzögertes Laden. Jede render-blockierende Ressource fügt 100 bis 300 Millisekunden zum initialen Rendering hinzu.