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

Nur 43% (Web Almanac 2024) der Mobile-Sites erfüllen alle drei Core Web Vitals im grünen Bereich – Desktop liegt bei 54% (Web Almanac 2024). Im E-Commerce ist das Bild noch angespannter: Plattformen wie WooCommerce kommen mobil nur auf eine 34% (Web Almanac 2024) LCP-Pass-Rate. Gleichzeitig zeigen Branchendaten: Eine Ladezeit-Verbesserung um 0,1 Sekunden steigerte in einer Mobilstudie die Progression von der Produktdetailseite in den Warenkorb um 9,1% und den Bestellwert um 9,2% (Google/Deloitte). Dieser Artikel zeigt, wie Shopware-Shops den Sprung 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,5 s, INP < 200 ms, 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 2024) – aber bei LCP schaffen mobil nur 59% (Web Almanac 2024) den grünen Bereich, weshalb LCP der häufigste Engpass für den Vollscore bleibt. Wer alle drei Good-Schwellen reißt, riskiert spürbar höhere Absprünge: Seiten, die die CWV-Schwellen erfüllen, werden 24% (Google/Chromium) seltener abgebrochen, bevor überhaupt Inhalt gezeichnet wurde.

Der Abstand zwischen Mobile und Desktop ist der größte Hebel: mobil erreichen 59% (Web Almanac 2024) der Seiten ein gutes LCP, auf dem Desktop sind es 74% (Web Almanac 2024). Ein Sprung in den grünen Bereich erfordert nicht eine, sondern zwölf bis sechzehn parallele Maßnahmen:

• Vite-Build mit Tree-Shaking – Shopware 6.7 ersetzt Webpack durch Vite; ungenutzte Storefront-Module fallen aus dem Bundle und entlasten den Performance-Score direkt.
• LCP-Image preloaden + WebP/AVIF – bilder als <img loading="eager" fetchpriority="high">, dazu WebP/AVIF-Pipeline für deutlich 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: WCAG manuell ergänzen

• Color Contrast – nur 29% (Web Almanac 2024) aller Sites bestehen diesen Test. 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. Anders als bei Performance gibt es hier kaum Grauzonen: jeder Audit ist binär bestanden oder gefailt.

SEO 100: Audits ohne Schwächen

Lighthouse-SEO besteht aus Audits gleicher Gewichtung: Statuscode, robots.txt, crawlbare Links, Meta-Description, Titel, hreflang, canonical und lesbare Schriftgrößen. Schon ein einziger Fail kostet den Vollscore, weil alle Prüfpunkte gleich schwer wiegen. Unsere SEO-Beratung prüft diese 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 × 48 px, mind. 8 px 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

Die Spreizung zwischen Mobile und Desktop ist kein Messfehler, sondern Lighthouse-Design: Mobile rechnet mit gedrosseltem CPU (4× Verlangsamung), gedrosseltem Netzwerk (1,6 Mbit/s, 150 ms RTT) und einem Mid-Tier-Gerät (Lighthouse-Dokumentation). Wer den Vollscore will, optimiert konsequent gegen das Mobile-Profil – die Desktop-100 fällt dann nahezu automatisch ab. Wie stark das wirkt, zeigt die Mobilstudie von Google und Deloitte: 0,1 Sekunden schnellere Ladezeit brachten +9,1% Progression von der Produktdetailseite in den Warenkorb und +9,2% Bestellwert (Google/Deloitte). Ein Sprung vom mobilen Mittelfeld auf Mobile-100 ist damit 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: Lighthouse-CI für Mobile auf Startseite, Listing, Detail, Checkout. Aktuelle Scores festhalten und Performance-Budget definieren.
2. Phase 2 – Hosting-Stack härten: HTTP/3, Brotli, Edge-Caching, CSP-Header, Strict-Transport-Security. Legt die Grundlage für den Best-Practices-Wert.
3. Phase 3 – Performance-Hebel mobile-first: LCP-Image-Preload, WebP/AVIF, Critical CSS, Long-Task-Budgets, Drittskripte killen.
4. Phase 4 – A11y-Pass auf Storefront-Theme: Color-Contrast, Form-Labels, Heading-Hierarchie, Fokus-Outlines. Manueller WCAG-2.2-Check parallel.
5. Phase 5 – SEO-14-Audits abschließen: Title, Description, Canonical, hreflang, Robots, Structured Data, Tap-Targets, Schriftgrößen.
6. Phase 6 – JSON-LD-Erweiterung: 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 können die Werte mit späteren Releases wieder sinken.