Core Web Vitals für Shopware: So beschleunigen Sie Ihren Onlineshop 2026

Die Core Web Vitals sind seit Jahren ein offizieller Google-Rankingfaktor – und trotzdem bestehen laut HTTPArchive-Daten aus 2025 nur 39 Prozent aller E-Commerce-Seiten alle drei Metriken gleichzeitig. Das sind drei Punkte unter dem globalen Durchschnitt von 42 Prozent. Onlineshops sind also messbar langsamer als der Rest des Webs. Als spezialisierte Shopware-Agentur sehen wir täglich, woran das liegt: Shop-Seiten sind ressourcenintensiver als reine Content-Websites, und genau hier verschenken viele Händler Sichtbarkeit und Umsatz. In diesem Artikel zeigen wir Ihnen, welche drei Werte zählen, wo die typischen Bremsen in Shopware 6 liegen – und wie Sie sie gezielt lösen.

LCP, INP, CLS: Was hinter den Core Web Vitals steckt

Die Core Web Vitals bestehen aus drei Messwerten, die Google auf Basis echter Nutzerdaten erhebt – am 75. Perzentil über ein rollierendes 28-Tage-Fenster. Entscheidend sind also nicht Laborwerte, sondern die Erfahrung Ihrer realen Besucher. Der Largest Contentful Paint (LCP) misst, wie schnell das größte sichtbare Element geladen ist, in einem Shop typischerweise das Hero-Bild auf der Kategorie- oder Produktseite. Zielwert: unter 2,5 Sekunden. Der Cumulative Layout Shift (CLS) bewertet, wie stark das Layout während des Ladens verspringt – der Zielwert liegt bei unter 0,1.

Die größte Veränderung der letzten Jahre betrifft die dritte Metrik: Der Interaction to Next Paint (INP) hat den alten First Input Delay vollständig abgelöst. Während FID nur die erste Interaktion gemessen hat, bewertet INP jede einzelne Interaktion über die gesamte Sitzung hinweg – jeden Klick auf einen Filter, jedes Öffnen des Offcanvas-Warenkorbs, jede Variantenauswahl. Der Zielwert liegt bei unter 200 Millisekunden, und 43 Prozent aller Websites verfehlen ihn. Für interaktive Shop-Funktionen ist das die anspruchsvollste der drei Hürden.

Warum Geschwindigkeit über Ihren Umsatz entscheidet

Die Diskussion um Core Web Vitals wird oft auf SEO reduziert. Das greift zu kurz. Studien aus dem Retail zeigen, dass jede Verbesserung der Ladezeit um 0,1 Sekunden die Conversion-Rate um rund 8 Prozent steigert. Geschwindigkeit ist damit kein technisches Nice-to-have, sondern ein direkter Umsatzhebel – jeder gesparte Wimpernschlag landet messbar im Warenkorb.

Hinzu kommt die mobile Realität: 60 bis 70 Prozent des Traffics in den von uns betreuten Shops kommen heute vom Smartphone. Damit verschiebt sich der Maßstab. Eine Seite, die am Desktop mit schneller Verbindung erträglich wirkt, kann auf einem Mittelklasse-Handy im Mobilfunknetz dramatisch einbrechen. Wer seine Performance nur am Bürorechner testet, optimiert für die falsche Zielgruppe. Als Shopware Agentur Köln messen wir Core Web Vitals deshalb grundsätzlich an mobilen Felddaten – nicht an geschönten Laborwerten.

Die typischen Performance-Bremsen in Shopware 6

Die schlechte Nachricht zuerst: Es gibt selten die eine Ursache. Die gute: Die Bremsen wiederholen sich von Projekt zu Projekt. In der Praxis lassen sich fast alle Performance-Einbrüche in Shopware 6 auf eine Handvoll Verdächtige zurückführen:

• Hohe TTFB (Time to First Byte). Wenn der Server zu lange braucht, bis er das erste Byte ausliefert, ist jede Frontend-Optimierung Makulatur. Ursachen sind meist fehlkonfigurierter HTTP-Cache, langsame Datenbank-Queries oder unterdimensioniertes Hosting.

• Plugin-Overhead. Jedes Plugin, das in den Storefront-Request eingreift, kostet Zeit. Wir sehen regelmäßig Shops mit 40 bis 60 aktiven Erweiterungen, von denen ein Teil schlicht ungenutzt ist – aber bei jedem Seitenaufruf mitläuft.

• Schwere Third-Party-Skripte. Tracking, Chat-Widgets, A/B-Testing-Tools und Cookie-Banner sind die häufigsten INP-Killer. Sie blockieren den Hauptthread und verzögern jede Nutzerinteraktion.

• Nicht optimierte LCP-Bilder. Riesige, unkomprimierte Hero-Bilder ohne modernes Format und ohne Priorisierung sind der Klassiker für einen schlechten LCP-Wert.

Caching ist dabei der wirksamste Hebel überhaupt. Statt jede Seite bei jedem Request dynamisch zu generieren, liefert der HTTP-Cache von Shopware fertige Seiten ohne PHP-Verarbeitung aus – für die meisten Shops die wichtigste Cache-Ebene. Ergänzend empfehlen wir für praktisch jeden Shopware-Shop Redis für Sessions und Object-Cache. Allein die saubere Konfiguration dieser beiden Schichten bringt in den ersten Tagen die größten Sprünge.

TTFB: der Wert, der vor allen anderen kommt

Die Time to First Byte misst die Zeitspanne zwischen der Anfrage des Browsers und dem ersten Byte, das der Server zurückschickt. Sie taucht in den Core Web Vitals nicht als eigene Metrik auf – und entscheidet trotzdem über sie alle. Solange der Server eine Sekunde braucht, bis er überhaupt antwortet, ist diese Sekunde im LCP bereits verbraucht, bevor ein einziges Bild geladen wurde. Jede Optimierung im Frontend beginnt also hinter einem Wert, den sie selbst nicht beeinflussen kann.

Vier Hebel senken die TTFB in der Praxis zuverlässig:

• Hosting und PHP-Version. Ein Server, der Lastspitzen abfangen kann, und eine aktuelle PHP-Version sind die Grundlage. Beides kostet wenig und wirkt sofort.
• Datenbankabfragen. Langsame Queries schlagen unmittelbar auf die Antwortzeit durch. Sie sind in gewachsenen Shops der häufigste Einzelbefund.
• Ein CDN. Statische Dateien – Bilder, CSS, JavaScript – kommen vom Server, der dem Besucher geografisch am nächsten liegt. Das senkt die Latenz und nimmt dem eigenen Server Last ab.
• Aktuelle Übertragungsprotokolle. HTTP/2 und HTTP/3 übertragen mehrere Anfragen über eine Verbindung und komprimieren die Kopfzeilen. HTTP/3 setzt dabei auf UDP statt TCP und spielt seine Stärke vor allem in mobilen Netzen mit schwankender Qualität aus – also genau dort, wo die Mehrheit Ihrer Besucher unterwegs ist.

Der alte Rat, CSS- und JavaScript-Dateien zu einer großen Datei zusammenzufassen, stammt noch aus der Zeit von HTTP/1.1 und hat sich überlebt: Seit HTTP/2 laufen parallele Anfragen über dieselbe Verbindung, und ein einziges großes Bündel verhindert eher, dass der Browser gezielt nachlädt, was er gerade braucht.

Die Stellschrauben in Shopware 6, der Reihe nach

Die folgenden Maßnahmen sind nach Wirkung sortiert, nicht nach Aufwand. Wer von oben nach unten arbeitet, holt das meiste zuerst:

1. HTTP-Cache aktivieren und vorwärmen. Der Cache liefert fertige Seiten ohne PHP-Verarbeitung aus. Ein Cache-Warmup für die meistbesuchten Seiten sorgt dafür, dass nicht ausgerechnet der erste Besucher nach dem Leeren die Rechenzeit bezahlt.
2. Varnish als Reverse Proxy. Shopware unterstützt Varnish nativ. In Shops mit hohem Traffic ist das die wirksamste Ergänzung zum internen Cache.
3. Redis für Sessions und Object-Cache. Nimmt der Datenbank die kleinteilige Last ab und wirkt direkt auf die TTFB.
4. Bilder in moderne Formate bringen. WebP oder AVIF statt JPEG, Zielgröße deutlich unter 250 KB, loading="lazy" für alles unterhalb der Falz – und umgekehrt das LCP-Bild ausdrücklich priorisieren, statt es lazy zu laden. Der Fehler, das Hero-Bild mit auf „lazy" zu setzen, kostet regelmäßig den größten Einzelwert.
5. Skripte und Plugins ausmisten. Jede Erweiterung, die in den Storefront-Request eingreift, kostet Zeit; jedes Drittanbieter-Skript blockiert den Hauptthread und damit den INP. Deaktivierte Funktionen, die niemand mehr nutzt, laufen trotzdem bei jedem Seitenaufruf mit.
6. Prozesse asynchron verarbeiten. E-Mail-Versand, Bestandsaktualisierungen, Exporte: Was nicht während einer Nutzeraktion passieren muss, gehört in die Message Queue und in Cronjobs.
7. Suche auslagern. Ab einem großen Sortiment gehört die Produktsuche auf Elasticsearch oder OpenSearch statt in die Shop-Datenbank.
8. Komprimierung und Lastverteilung. Gzip oder Brotli für HTML, CSS und JavaScript, und in großen Setups ein Load Balancer, der Anfragen auf mehrere Server verteilt – das hält den Shop auch dann erreichbar, wenn eine Maschine an ihre Grenze kommt.

Danach gilt, was für jede Optimierung gilt: messen, und zwar dauerhaft. Performance ist kein Projekt mit Enddatum, sondern ein Wert, der mit jedem neuen Plugin, jedem Kampagnenskript und jedem Sortimentszuwachs wieder abrutschen kann. Ein Monitoring, das Ausreißer meldet, bevor es der Umsatz tut, ist deshalb Teil der Lösung.

Was Shopware 6.7 leistet – und was Sie trotzdem tun müssen

Shopware hat das Performance-Thema ernst genommen. Die Version 6.7 bringt laut Hersteller bis zu 108 Prozent mehr Bestellungen pro Sekunde und 85 Prozent weniger Latenz. Das ist ein beachtlicher Sprung – aber kein Selbstläufer. Diese Zahlen erreichen Sie nur, wenn Server-Konfiguration, Caching und Plugins entsprechend mitziehen. Ein Update auf 6.7 allein, aufgesetzt auf eine fehlkonfigurierte Infrastruktur und einen überladenen Plugin-Stack, hebt das Potenzial nicht.

Wo die Version messbar etwas ändert, ist vor allem die Stabilität unter Last: große Produktkataloge, Traffic-Spitzen in der Peak Season, viele gleichzeitige Zugriffe auf Kategorie- und Produktseiten. Dazu kommen ein spürbar reaktionsschnelleres Backend – relevant für alle, die täglich Preise und Bestände pflegen – und effizientere API-Zugriffe, was bei Headless-Aufbauten und Progressive Web Apps direkt durchschlägt. Benchmarks messen jedoch immer eine sauber konfigurierte Testumgebung. Im Livebetrieb entscheidet, ob Caching, Hosting und Plugin-Auswahl mitziehen.

Genau hier setzt unsere Arbeit in der Shopware-Entwicklung an: Wir analysieren zuerst die Felddaten, identifizieren die größten Bremsen pro Template – Startseite, Kategorie-Listing, Produktdetailseite, Warenkorb – und priorisieren danach. Performance-Optimierung ohne Messung ist Stochern im Nebel. Wer dagegen weiß, dass etwa der LCP auf der Produktseite das Nadelöhr ist, kann gezielt das Hero-Bild priorisieren, statt blind an zehn Stellschrauben gleichzeitig zu drehen.

Fazit: Performance ist eine Architekturentscheidung

Core Web Vitals sind kein einmaliges Projekt, das man abhakt, sondern ein dauerhafter Bestandteil einer gesunden Shop-Architektur. Wer eine E-Commerce-Plattform aufbaut, die mit Sortiment, Traffic und Funktionsumfang wächst, muss Performance von Anfang an mitdenken – im Hosting, im Caching-Konzept, in der Plugin-Auswahl und im Frontend. Nachträglich Tempo in ein gewachsenes Setup zu pressen, ist deutlich teurer als ein sauberes Fundament.

Sie wollen wissen, warum Ihr Shopware-Shop die Core Web Vitals nicht besteht und wo der größte Hebel liegt? Wir analysieren Ihr System anhand echter Felddaten und zeigen Ihnen den konkreten Fahrplan. Sprechen Sie mit den Experten von enno.dev, Ihrer spezialisierten Shopware Agentur Köln.