Core Web Vitals im Shopware-Shop: Die Hebel, die wirklich etwas bringen

Die meisten Performance-Projekte starten falsch. Jemand jagt die Startseite durch PageSpeed Insights, bekommt eine rote Zahl und fängt an, Bilder zu komprimieren. Zwei Wochen später ist der Wert immer noch rot, weil das Problem nie bei den Bildern lag.

Core Web Vitals im Shopware-Shop sind kein Rätsel. Es gibt eine Handvoll Stellschrauben, die den Großteil ausmachen, und die sitzen fast alle an Stellen, die man im Frontend nicht sieht.

Die drei Werte und was sie im Shop bedeuten

Google misst im 75. Perzentil deiner echten Seitenaufrufe. Nicht im Labor, sondern bei deinen Kunden, auf deren Geräten und Leitungen. Das ist der Grund, warum ein grüner Lighthouse-Wert auf deinem MacBook nichts über deinen Shop aussagt.

Largest Contentful Paint soll unter 2,5 Sekunden liegen. Das ist der Moment, in dem das größte sichtbare Element steht, im Shop meistens das Produktbild oder das Hero-Element der Kategorieseite.

Interaction to Next Paint soll unter 200 Millisekunden bleiben. Der Wert misst, wie schnell die Seite auf Klicks reagiert. Er hat First Input Delay abgelöst, und er ist deutlich strenger, weil er nicht nur die erste Interaktion misst, sondern alle.

Cumulative Layout Shift soll unter 0,1 bleiben. Alles, was während des Ladens springt, zählt hier ein. Der Klassiker im Shop ist das Cookie-Banner, das nach einer Sekunde einblendet und den Inhalt nach unten schiebt.

Der größte Hebel sitzt vor PHP

Wenn dein Time to First Byte schlecht ist, kannst du im Frontend optimieren, so viel du willst. Der Browser wartet erstmal.

Der erste Griff geht deshalb an den HTTP-Cache. Shopware liefert ihn mit, aktiviert wird er über SHOPWARE_HTTP_CACHE_ENABLED=1. Klingt banal, und trotzdem finden wir ihn regelmäßig deaktiviert vor, meistens weil vor Jahren jemand ein Caching-Problem hatte und den Schalter umgelegt statt die Ursache gesucht hat.

Bei mehreren Servern oder hohem Traffic empfiehlt Shopware zusätzlich einen Reverse Proxy wie Varnish. Der liefert fertige Seiten aus, ohne dass PHP überhaupt anspringt. Das ist der Unterschied zwischen „schnell” und „egal wie viele Besucher kommen”.

Wichtig ist die zweite Hälfte, über die seltener geredet wird: die Invalidierung. Ein Cache, der bei jeder Preisänderung komplett geleert wird, ist fast so schlecht wie kein Cache, weil danach jede Seite wieder neu gebaut werden muss. Wer viele Bestandsänderungen hat, sollte die verzögerte Cache-Invalidierung über Redis laufen lassen statt über die Datenbank. Sonst wird ausgerechnet der Aufräummechanismus zum Flaschenhals.

Die Konfiguration, die kaum jemand vollständig setzt

Ein paar Werte aus der offiziellen Shopware-Doku, die in Produktivsystemen erstaunlich oft fehlen:

• Opcache richtig konfigurieren. opcache.validate_timestamps=0 sorgt dafür, dass PHP nicht bei jedem Request prüft, ob sich Dateien geändert haben. Dazu opcache.interned_strings_buffer=20 und opcache.enable_file_override=1. Wichtig: Bei validate_timestamps=0 musst du nach jedem Deployment den Opcache leeren, sonst läuft alter Code weiter.
• .env.local.php statt .env. Die kompilierte Variante spart das Parsen der Konfigurationsdatei bei jedem einzelnen Aufruf.
• MySQL sauber einstellen. group_concat_max_len auf mindestens 320000, und ONLY_FULL_GROUP_BY gehört nicht in den sql_mode.
• Redis für Session und Object Cache. Shopware empfiehlt das für praktisch jeden ernsthaften Shop.
• Elasticsearch oder OpenSearch bei großen Katalogen. Dazu SHOPWARE_ES_THROW_EXCEPTION=1 setzen, sonst fällt das System bei einem Suchfehler still auf MySQL zurück und legt im Zweifel die Datenbank lahm, während du im Log nichts siehst.

Diese Liste ist keine Geheimwissenschaft, sie steht so in der Shopware-Dokumentation. Sie wird nur selten komplett abgearbeitet, weil sie über Hosting, Serverkonfiguration und Shop-Einstellungen verteilt ist und sich deshalb niemand zuständig fühlt.

INP ist der Wert, an dem Shopware-Shops am häufigsten scheitern

LCP bekommt man mit Cache und ordentlichen Bildern meistens in den Griff. INP ist der undankbare Wert, weil die Ursache fast nie im Shop selbst liegt.

Jedes Tracking-Skript, jedes Consent-Tool, jeder Chat-Widget und jede A/B-Testing-Lösung belegt den Haupt-Thread des Browsers. Wenn ein Kunde auf „In den Warenkorb” klickt, während drei Skripte im Hintergrund rechnen, wartet er. Genau das misst INP.

Der ehrlichste Hebel ist deshalb kein technischer, sondern eine Entscheidung: Welche Drittanbieter-Skripte brauchst du wirklich? Wir haben Shops gesehen, in denen vier verschiedene Tracking-Lösungen parallel liefen, weil über die Jahre nie etwas abgeschaltet wurde. Jedes einzelne war irgendwann mal aus einem guten Grund eingebaut worden.

Zweiter Hebel: Server-Side Tracking. Wenn Messung ohnehin sein muss, gehört sie nach Möglichkeit auf den Server statt in den Browser des Kunden.

Die Reihenfolge, in der du vorgehst

1. Erst messen, und zwar Felddaten. Search Console und CrUX zeigen dir, was deine echten Nutzer erleben. Lighthouse ist ein Diagnosewerkzeug, kein Zielwert.
2. TTFB prüfen. Ist der schlecht, sind Cache und Hosting dran, sonst nichts.
3. HTTP-Cache und Invalidierung sauber aufsetzen.
4. Serverseitige Konfiguration abarbeiten. Opcache, Redis, MySQL, gegebenenfalls Elasticsearch.
5. LCP-Element optimieren. Das eine Bild, das oben steht, in moderner Kompression, richtig dimensioniert, ohne Lazy Loading.
6. Drittanbieter-Skripte ausmisten. Der Punkt für INP.
7. CLS-Ursachen suchen. Feste Höhen für Banner, Bilder mit Dimensionsangaben.

Wer das in dieser Reihenfolge macht, sieht nach Schritt drei oder vier meistens den größten Sprung. Wer bei Schritt fünf anfängt, optimiert an einem System herum, dessen Grundproblem woanders liegt.

Was Performance-Optimierung nicht kann

Zwei ehrliche Einschränkungen.

Erstens: Core Web Vitals sind ein Rankingfaktor, aber ein schwacher. Ein technisch perfekter Shop mit dünnem Content rankt nicht besser als ein mittelschneller mit guten Inhalten. Wer Performance als SEO-Wunderwaffe verkauft, verkauft dir etwas. Der echte Wert liegt in der Conversion, weil schnelle Seiten schlicht mehr Käufe erzeugen.

Zweitens: Optimierung ist kein Projekt, das man abschließt. Nach dem nächsten Plugin, dem nächsten Marketing-Skript und dem nächsten Theme-Update sieht die Lage anders aus. Deshalb gehört Performance-Monitoring in die laufende Betreuung und nicht in eine einmalige Aktion. Bei uns steckt es ab dem Professional-Paket drin, inklusive der Core-Web-Vitals-Werte.

Wenn du wissen willst, wo dein Shop gerade steht, ist der Shop-Health-Check der schnellste Einstieg. Wenn du schon weißt, dass es klemmt, und jemanden brauchst, der die Liste oben systematisch abarbeitet, schau dir an, wie wir Shopware-Performance angehen. Und falls dein Verdacht Richtung Plugin-Ballast geht: Die Plugin-Inventur macht in wenigen Tagen sichtbar, was du davon wirklich brauchst.