Lighthouse 100/100/100/100: Full Scores for Shopware 2026

Only 43% (Web Almanac 2024) of mobile sites pass all three Core Web Vitals in the green zone — desktop sits at 54% (Web Almanac 2024). In e-commerce the picture is tighter still: platforms like WooCommerce reach only a 34% (Web Almanac 2024) LCP pass rate on mobile. At the same time, industry data shows: in a mobile study a load-time improvement of 0.1 seconds lifted progression from the product detail page to the basket by 9.1% and order value by 9.2% (Google/Deloitte). This article shows how Shopware stores reach Lighthouse 100/100/100/100 across all four categories — and how a perfect-score focus differs from pure Core Web Vitals work.

Four categories: Performance, A11y, BP, SEO

Lighthouse rates a page across four equally weighted categories — and only a perfect score in all four delivers what marketing calls a full Lighthouse score. Unlike pure page-speed work, no single lever is enough; discipline is required across every area.

Performance 100: LCP, INP, CLS green

Performance is the toughest category — it combines lab data with the three Core Web Vitals as a de-facto requirement. Google's Good thresholds are LCP < 2.5s, INP < 200ms, CLS < 0.1 for at least 75% (web.dev) of CrUX visits. Web Almanac data shows: only 43% (Web Almanac 2024) of mobile sites meet all three CWV thresholds. INP is improving — 55% pass-rate in 2022 vs. 74% in 2024 (Web Almanac 2024) — but on LCP only 59% (Web Almanac 2024) of mobile pages reach the green zone, which keeps LCP the most common blocker for a perfect score. Missing all three Good thresholds is costly: pages that meet the CWV thresholds are 24% (Google/Chromium) less likely to be abandoned before any content has been painted.

The gap between mobile and desktop is the biggest lever: 59% (Web Almanac 2024) of mobile pages reach a good LCP, on desktop it is 74% (Web Almanac 2024). Moving into the green zone takes not one but twelve to sixteen parallel measures:

• Vite build with tree-shaking — Shopware 6.7 replaces Webpack with Vite; unused storefront modules drop out of the bundle and relieve the performance score directly.
• Preload the LCP image + WebP/AVIF — <img loading="eager" fetchpriority="high">, plus a WebP/AVIF pipeline for a markedly smaller byte volume.
• Inline critical CSS, defer the rest — through the storefront theme build pipeline.
• INP via long-task budget — no main-thread JS task longer than 50 ms; third-party scripts via requestIdleCallback.
• CLS via reserved containers — aspect-ratio for every product image, banner and ad slot.
• HTTP/3 + edge cache — see edge caching for Shopware for global delivery.
• Self-hosted fonts with font-display: optional — no foreign-domain round trips.
• Kill third-party scripts or proxy them server-side — see server-side tracking.
• Service worker for repeat visits — secures consistent 100s, not just first-load scores.

Accessibility 100: add manual WCAG testing

• Color contrast — only 29% (Web Almanac 2024) of sites pass this test. Tailwind grey defaults rarely suffice; check storefront theme variables.
• Form labels and ARIA — every input needs a label, every custom button a role. Shopware storefront templates sometimes misuse aria-hidden.
• Heading hierarchy — no H4 without H3, no duplicated H1. Audit listings, detail pages and checkout separately.
• Language via lang attribute — for multi-lingual setups, set dynamically per storefront sales channel.
• Focus management — visible outline on every interactive element; no outline: none without a replacement.
• Images with alt text — product images often inherit the file name. Extend the Shopware media library with a mandatory alt-text field.
• Bypass mechanism — Skip to content link as the first focusable element.

Best Practices 100: security as a score factor

Best practices looks unspectacular but is often the fastest score gain — provided the hosting plays along. Audits cover security and code-quality criteria per web.dev. Unlike performance, this category has hardly any grey zones: each audit is binary pass or fail.

SEO 100: audits without weak spots

Lighthouse SEO consists of equally weighted audits: status code, robots.txt, crawlable links, meta description, title, hreflang, canonical and legible font sizes. A single fail already costs the perfect score, because every check carries the same weight. Our SEO consulting treats those items as a baseline and then layers content factors on top that Lighthouse cannot measure.

• Document has a <title> — Shopware listing pages are often empty when the SEO plug-in is silent.
• Meta description — individual per category and product page, never auto-generated from the description.
• HTTP status 2xx — no soft 404s for empty filter listings.
• <a href> with text — no image-only links without alt or aria-label.
• Crawlable (robots.txt + meta robots) — no noindex on live paths.
• Correct hreflang — DE/EN parity, every language channel self-references.
• Canonical — unique per product, no duplicate canonicals through filter parameters.
• Structured data — see the next section on JSON-LD.
• Tap targets — buttons at least 48×48 px with 8 px spacing.
• Legible font sizes — no font-size < 12px for body copy.
• Viewport meta — width=device-width, initial-scale=1.
• Plugin audit — no Flash or Java embeds.
• Image aspect ratio — same as in best practices.
• Charset declared — <meta charset="utf-8"> in <head>.

Shopware-specific pitfalls

• Storefront CMS blocks with own JS — slider plug-ins often block the main thread for over 500 ms. Defer-load custom plug-ins or replace them through bespoke development.
• Twig cache cold — the first Lighthouse run after a deployment measures a cold cache; CI should always warm up with two prior requests.
• Admin watcher active in front-end — dev-mode leftovers delay hydration. Before any Lighthouse run, set APP_ENV=prod and run bin/console cache:clear.
• Cookie-consent layer — many third-party layers ship 80-200 KB of JS and break the performance score. Evaluate an in-house or server-side variant.
• Theme compilation without tree-shaking — older 6.5 themes produce 800 KB+ JS bundles. A PHP 8.5 migration step belongs hand in hand with a theme rebuild.

JSON-LD schema in 6.7.9.0

Lighthouse SEO checks whether structured data exists — not whether it is complete or rich-result eligible. The recent extension of Shopware schemas in 6.7.9.0 ships product, offer, organisation and breadcrumbList schemas out of the box. Details and extension patterns are covered in our article on JSON-LD schemas in Shopware 6.7.9. For a Lighthouse SEO 100 a single valid JSON-LD block is enough — for Google rich results, product reviews, AggregateRating and inventory status should follow, which becomes the next lever once inventory comes from a multi-channel sync.

CSP and best practices

A valid Content Security Policy not only pushes the best-practices score to 100, it also reduces the attack surface for XSS and third-party scripts. The following CSP template works for a Shopware 6.7 storefront with its own tracking infrastructure — it blocks external JS except for explicitly allowlisted origins:

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: explaining the score gap

The spread between mobile and desktop is not a measurement glitch but a Lighthouse design decision: mobile assumes throttled CPU (4× slowdown), a throttled network (1.6 Mbit/s, 150 ms RTT) and a mid-tier device (Lighthouse documentation). To reach a perfect score, optimise consistently against the mobile profile — desktop 100 then drops out almost automatically. The Google/Deloitte mobile study shows how much that matters: 0.1 seconds of extra speed produced +9.1% progression from the product detail page to the basket and +9.2% in order value (Google/Deloitte). Going from the mobile midfield to mobile-100 is therefore not cosmetic but directly revenue-relevant.

Measurement setup: CrUX, Lighthouse CI, RUM

A single Lighthouse run only shows one lab value — what matters to Google is CrUX (Chrome User Experience Report), based on real users. To hold 100/100/100/100 over time, three measurement layers are needed in parallel. The layers answer different questions and complement each other:

• Lab tests via Lighthouse CI — automated per pull request, fail-on-budget thresholds for LCP, INP, CLS, bundle size.
• Field data via CrUX — the only source Google actually uses for ranking; 75th percentile over 28 days.
• RUM (real user monitoring) — captured per sales channel, ideally cookieless and server-side for privacy-friendly high-quality data.
• Performance budget — written down: max 200 KB JS, max 80 KB CSS, max 600 KB images per initial page.
• A/B Lighthouse — snapshot before each theme update, regression diff after.

Roadmap to all four full scores

1. Phase 1 — audit baseline (week 1): Lighthouse CI on mobile for home, listing, detail, checkout. Capture current scores and define a performance budget.
2. Phase 2 — harden the hosting stack (week 1-2): HTTP/3, Brotli, edge caching, CSP headers, Strict-Transport-Security. Delivers best-practices 100 immediately.
3. Phase 3 — mobile-first performance levers (week 2-4): LCP image preload, WebP/AVIF, critical CSS, long-task budgets, kill third-party scripts.
4. Phase 4 — a11y pass on the storefront theme (week 4-5): color contrast, form labels, heading hierarchy, focus outlines. Manual WCAG 2.2 review in parallel.
5. Phase 5 — close the SEO 14 audits (week 5): title, description, canonical, hreflang, robots, structured data, tap targets, font sizes.
6. Phase 6 — JSON-LD extension (week 5-6): product, offer, review and AggregateRating schemas beyond the JSON-LD extensions in 6.7.9 for rich-result eligibility.
7. Phase 7 — RUM and regression protection (ongoing): Lighthouse CI pipeline, CrUX monitoring, monthly regression report. Without phase 7, 100/100/100/100 typically slips back within 2-3 releases.