Lighthouse 100/100/100/100: Volle Scores für Shopware 2026

Der Median-Lighthouse-Score über 25.000 vermessene E-Commerce-Sites liegt bei 67/100 (Reboot Online). 70,5% (Reboot Online) der Shops landen im Bereich 50-89 — also in der Kategorie needs improvement. Nur einzelne Branchen wie Beauty erreichen mit 27% (Reboot Online) den grünen Bereich von 90-100. Gleichzeitig zeigen Branchendaten: Eine Ladezeit-Verbesserung um 0,1 Sekunden kann die Conversion um bis zu 8,4% und den durchschnittlichen Bestellwert um 9,2% (Google/Deloitte/WIRO) erhöhen — während eine Sekunde mehr Ladezeit erfahrungsgemäß rund 7% (Google/Deloitte) der Conversion kosten kann. Dieser Artikel zeigt, wie Shopware-Shops den Sprung von 67 auf Lighthouse 100/100/100/100 in allen vier Kategorien schaffen — und worin sich der Vollscore-Fokus von einer reinen Core-Web-Vitals-Optimierung unterscheidet.

Vier Kategorien: Performance, A11y, BP, SEO

Lighthouse bewertet eine Seite in vier gleichberechtigten Kategorien — und nur ein Vollscore in allen vieren ergibt das, was im Marketing als voller Lighthouse-Score gilt. Anders als bei reiner PageSpeed-Optimierung reicht hier kein einzelner Hebel, sondern es braucht eine Disziplin in allen vier Bereichen.

Performance 100: LCP, INP, CLS auf grün

Die Performance-Kategorie ist die anspruchsvollste — sie kombiniert Lab-Daten mit den drei Core Web Vitals als faktischer Pflichtbestandteil. Google verlangt für Good die Schwellen LCP < 2,5s, INP < 200ms, CLS < 0,1 bei mindestens 75% (web.dev) der CrUX-Visits. Aktuelle Web-Almanac-Daten zeigen: nur 43% (Web Almanac 2024) der Mobile-Sites erfüllen alle drei CWV-Schwellen. Das INP-Bild verbessert sich zwar — von 55% Pass-Rate 2022 auf 74% 2024 (Web Almanac/Mewa 2026) — aber 43% (Web Almanac) der Sites verfehlen die 200-ms-Marke noch. 47% (Mewa Studio 2026) aller Sites passen 2026 alle drei Good-Schwellen — die übrigen 53% (Mewa) verlieren laut Studie zwischen 8% und 35% Conversion oder Traffic.

Der typische Shopware-Shop erreicht laut Brandcrock und Magespark Werte von Desktop ~90, Mobile 45-60 (Brandcrock/Magespark) — das mobile Delta ist also der größte Hebel. Ein Sprung von 67 auf 100 erfordert nicht eine, sondern zwölf bis sechzehn parallele Maßnahmen:

• Vite-Build mit Tree-Shaking — Shopware 6.7 reduziert JS/CSS um 25% (Shopware Performance Report/itdelight) und verbessert den Score von 76 auf 78 allein durch den Build-Wechsel.
• LCP-Image preloaden + WebP/AVIF — bilder als <img loading="eager" fetchpriority="high">, dazu WebP/AVIF-Pipeline für 30-60% weniger Byte-Volumen.
• Critical CSS inlinen, Rest defer — über die Storefront-Theme-Build-Pipeline.
• INP über Long-Task-Budget — keine JS-Tasks > 50 ms im Main Thread, Drittskripte via requestIdleCallback.
• CLS via reservierter Container — aspect-ratio für jedes Produktbild, Banner und Ad-Slot setzen.
• HTTP/3 + Edge-Cache — siehe Edge-Caching für Shopware für globale Verteilung.
• Self-hosted Fonts mit font-display: optional — keine Fremd-Domain-Roundtrips.
• Drittskripte killen oder server-side proxen — siehe Server-Side Tracking.
• Service-Worker für Repeat-Visits — sichert konstante 100er-Werte, nicht nur den Erstbesuch.

Accessibility 100: 30-40% WCAG manuell ergänzen

• Color Contrast — 71% (Web Almanac) aller Sites scheitern hier (häufigster A11y-Fehler). Tailwind-Defaults für Grautöne reichen meist nicht; Storefront-Theme-Variablen prüfen.
• Form-Labels und ARIA — jedes Input braucht ein Label, jeder Custom-Button eine Rolle. Shopware-Storefront-Templates verwenden teils aria-hidden falsch.
• Heading-Hierarchie — keine H4 ohne H3, keine doppelten H1. Listings, Detailseiten, Checkout einzeln prüfen.
• Sprache via lang-Attribut — bei Mehrsprachigkeit dynamisch pro Storefront-Sales-Channel setzen.
• Fokus-Management — sichtbarer Outline-Style auf allen interaktiven Elementen, kein outline: none ohne Ersatz.
• Bilder mit Alt-Texten — Produktbilder erben oft das Filename. Shopware-Mediathek mit Alt-Pflichtfeldern erweitern.
• Bypass-Mechanismen — Skip to Content-Link als erstes fokussierbares Element.

Best Practices 100: Sicherheit als Score-Faktor

Die Best-Practices-Kategorie wirkt unscheinbar, ist aber für viele Shops der schnellste Punktegewinn — vorausgesetzt, das Hosting spielt mit. Geprüft werden Sicherheits- und Code-Qualitäts-Kriterien gemäß web.dev und Niteco. Anders als bei Performance gibt es hier kaum Grauzonen: jeder Audit ist binär bestanden oder gefailt.

SEO 100: 14 Audits ohne Schwächen

Lighthouse-SEO besteht aus 14 (DebugBear) Audits gleicher Gewichtung. Schon ein einziger Fail führt zu 92/100 — zwei Fails zu 86/100. Der Median liegt laut DebugBear bei rund 92 (DebugBear). Wer auf 100 will, muss alle 14 Punkte auf grün haben. Unsere SEO-Beratung prüft diese 14 Punkte als Pflichtbasis und ergänzt sie um inhaltliche Faktoren, die Lighthouse nicht messen kann.

• Document has a <title> — bei Shopware-Listings oft leer, wenn Meta-SEO-Plugin schweigt.
• Meta-Description — pro Kategorieseite und Produktseite individuell, keine Auto-Generation aus Beschreibung.
• HTTP-Status 2xx — keine Soft-404 für leere Filter-Listings.
• <a href> mit Text — keine Bild-only-Links ohne Alt oder Aria-Label.
• Crawlbar (robots.txt + Meta-Robots) — keine noindex auf Live-Pfaden.
• hreflang korrekt — siehe DE/EN-Synchronität, jeder Sprach-Channel selbst-referenziert.
• Canonical — pro Produkt eindeutig, keine Doppel-Canonicals durch Filter-Parameter.
• Strukturierte Daten — siehe nächster Abschnitt zu JSON-LD.
• Tap-Targets — Buttons mind. 48×48px, mind. 8px Abstand.
• Lesbare Schriftgrößen — keine font-size < 12px für Body-Text.
• Viewport-Meta — width=device-width, initial-scale=1.
• Plugins-Audit — keine Flash/Java-Embeds.
• Image-Aspect-Ratio — wie in Best Practices.
• Charset deklariert — <meta charset="utf-8"> im <head>.

Shopware-spezifische Fallstricke

• Storefront-CMS-Blöcke mit eigenem JS — Slider-Plugins blockieren oft den Main Thread > 500 ms. Custom-Plugins via defer laden oder durch eigene Programmierung ersetzen.
• Twig-Cache nicht warm — der erste Lighthouse-Run nach Deployment misst kalten Cache; CI immer mit zwei Warm-Up-Requests vorbereiten.
• Admin-Watcher im Frontend aktiv — Dev-Mode-Reste verzögern die Hydration. Vor jedem Lighthouse-Run APP_ENV=prod und bin/console cache:clear setzen.
• Cookie-Consent-Layer — viele Drittanbieter-Layer ziehen 80-200 KB JS und brechen den Performance-Score. Eigenentwicklung oder Server-Side-Variante prüfen.
• Theme-Compilation ohne Tree-Shaking — alte 6.5-Themes erzeugen 800 KB+ JS-Bundles. Ein PHP-8.5-Migrationsschritt gehört eng mit dem Theme-Rebuild zusammen.

JSON-LD Schema in 6.7.9.0

Lighthouse-SEO prüft, ob strukturierte Daten existieren — nicht, ob sie vollständig oder Rich-Result-fähig sind. Die kürzliche Erweiterung der Shopware-Schemata in 6.7.9.0 liefert Product-, Offer-, Organization- und BreadcrumbList-Schemata out-of-the-box. Details und Erweiterungs-Patterns dokumentiert der Artikel zu JSON-LD-Schemata in Shopware 6.7.9. Für den Lighthouse-100-SEO-Score genügt ein valides JSON-LD-Block — für Rich Results in Google sollten Product-Reviews, AggregateRating und Inventory-Status ergänzt werden, was wiederum den nächsten Hebel bildet, wenn das Inventory aus einem Multi-Channel-Sync gespeist wird.

CSP und Best Practices

Eine valide Content Security Policy bringt nicht nur den Best-Practices-Score auf 100, sondern reduziert auch das Angriffspotenzial bei XSS und Drittskripten. Die folgende CSP-Vorlage funktioniert für eine Shopware-6.7-Storefront mit eigener Tracking-Infrastruktur — sie blockiert externes JS bis auf konkret freigegebene Ursprünge:

add_header Content-Security-Policy "\
  default-src 'self'; \
  script-src 'self' 'nonce-$REQUEST_ID' https://static.example.com; \
  style-src 'self' 'unsafe-inline'; \
  img-src 'self' data: https://cdn.example.com; \
  font-src 'self' data:; \
  connect-src 'self' https://analytics.example.com; \
  frame-ancestors 'none'; \
  base-uri 'self'; \
  form-action 'self'; \
  upgrade-insecure-requests;\
" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Mobile vs Desktop: Score-Diskrepanz erklärt

Ein typischer Shopware-Shop liegt laut Brandcrock und Magespark bei Desktop ~90 und Mobile 45-60 (Brandcrock/Magespark). Diese Spreizung ist kein Messfehler, sondern Lighthouse-Design: Mobile rechnet mit gedrosseltem CPU (4× Slowdown), gedrosseltem Netzwerk (1,6 Mbit/s) und einem Mid-Tier-Gerät. Wer den Vollscore will, optimiert konsequent gegen das Mobile-Profil — die Desktop-100 fällt dann nahezu automatisch ab. Eine 0,1 Sekunden Verbesserung kann hier laut Studienlage +8,4% Conversion und +9,2% AOV (Google/Deloitte/WIRO) bedeuten — die Mobile-Bounce-Wahrscheinlichkeit steigt um +90% (Google think with Google) bei einem LCP-Anstieg von 1 auf 5 Sekunden. Ein Sprung von Mobile-50 auf Mobile-100 ist nicht kosmetisch, sondern direkt umsatzwirksam.

Mess-Setup: CrUX, Lighthouse-CI, RUM

Ein einzelner Lighthouse-Run zeigt nur einen Lab-Wert — relevant für Google ist aber CrUX (Chrome User Experience Report) auf Basis echter Nutzer. Wer 100/100/100/100 dauerhaft halten will, braucht drei Mess-Ebenen parallel. Diese Ebenen liefern unterschiedliche Antworten und ergänzen sich:

• Lab-Tests via Lighthouse-CI — pro Pull Request automatisch, fail-on-budget-Schwellen für LCP, INP, CLS, Bundle-Size.
• Field-Daten via CrUX — der einzige Datentopf, den Google für Rankings tatsächlich nutzt; 75-Perzentil über 28 Tage.
• RUM (Real User Monitoring) — eigene Erfassung pro Sales-Channel, idealerweise cookieless und server-seitig für DSGVO-konforme Hochwert-Daten.
• Performance-Budget — schriftlich fixiert: max. 200 KB JS, max. 80 KB CSS, max. 600 KB Bilder pro Initial-Page.
• A/B-Lighthouse — vor jedem Theme-Update Snapshot, danach Regressions-Diff.

Roadmap zu allen vier 100ern

1. Phase 1 — Audit-Baseline (Woche 1): Lighthouse-CI für Mobile auf Startseite, Listing, Detail, Checkout. Aktuelle Scores festhalten und Performance-Budget definieren.
2. Phase 2 — Hosting-Stack härten (Woche 1-2): HTTP/3, Brotli, Edge-Caching, CSP-Header, Strict-Transport-Security. Liefert sofort Best-Practices-100.
3. Phase 3 — Performance-Hebel mobile-first (Woche 2-4): LCP-Image-Preload, WebP/AVIF, Critical CSS, Long-Task-Budgets, Drittskripte killen.
4. Phase 4 — A11y-Pass auf Storefront-Theme (Woche 4-5): Color-Contrast, Form-Labels, Heading-Hierarchie, Fokus-Outlines. Manueller WCAG-2.2-Check parallel.
5. Phase 5 — SEO-14-Audits abschließen (Woche 5): Title, Description, Canonical, hreflang, Robots, Structured Data, Tap-Targets, Schriftgrößen.
6. Phase 6 — JSON-LD-Erweiterung (Woche 5-6): Product-, Offer-, Review-, AggregateRating-Schemata über die JSON-LD-Erweiterungen aus 6.7.9 hinaus für Rich-Result-Fähigkeit.
7. Phase 7 — RUM und Regression-Schutz (laufend): Lighthouse-CI-Pipeline, CrUX-Monitoring, monatlicher Regression-Bericht. Ohne Phase 7 fällt 100/100/100/100 erfahrungsgemäß innerhalb von 2-3 Releases zurück.