E-Commerce Engineering · CI/CD Automatisierung · Core Web Vitals

E-Commerce PageSpeed & Core Web Vitals CI/CD Automatisierung: MoonBloom Walls

MoonBloom Walls vertreibt Premium-Kinderzimmertapeten mit bezahlten Google Ads Kampagnen in Deutschland, Österreich und Frankreich. Große Raumbilder und blockierende Schrift-Kaskaden drückten den mobilen Lighthouse-Score anfangs auf 54. Durch den Abbau kritischer Anforderungsketten und einen automatisierten PageSpeed-API-Quality-Gate in GitHub Actions stieg der Score auf 90+, und mobile Checkout-Conversions wuchsen um +22 %.

54 → 90+ Mobile Lighthouse Score
6,8s → 2,4s Largest Contentful Paint (LCP)
0 Ketten Keine blockierenden Kaskaden
+22% Mobile Checkout-Conversion
1. Kontext & Diagnose

Das Problem: Teure Werbeklicks verpuffen an mobilen Absprüngen

MoonBloom Walls (moonbloomwalls.com) schaltet internationale Google Search und Shopping Ads. Im Einrichtungsbereich kommen über 74 % des Traffics über Smartphones via Instagram und Google Ads.

Das anfängliche Audit deckte kritische Flaschenhälse auf:

  • Mobiler Lighthouse-Score lag bei 54 / 100: Der Largest Contentful Paint (LCP) dauerte 6,8 Sekunden bei mobiler 4G-Verbindung.
  • Kritische Anforderungsketten: Externe Google Fonts Stylesheets erzeugten eine 2-Hop-Kaskade, die die initiale Textanzeige um 388ms verzögerte.
  • Unoptimierte Bild-Assets: Hochauflösende Tapetenmuster wurden als unkomprimierte JPEGs ohne responsive srcset-Attribute geladen.

Bei Klickpreisen von 1,20 € bis 3,50 € in Shopping-Kampagnen führte die Ladezeit von 6,8s dazu, dass bis zu 40 % der Nutzer absprangen, bevor Preise sichtbar wurden.

2. Technische Umsetzung

Lösungsarchitektur: Kaskaden abbauen & CSS direkt inlinen

❌ Vor der Optimierung Score: 54
Schrift-Kaskade: Google Fonts 2-Hop Download (388ms Latenz)
Bilder: 1,8MB unkomprimierte JPEG-Mockups
Render-Blocker: Synchrone CSS-Dateien & Tracking
LCP: 6,8s bei simuliertem 4G
✅ Nach der Optimierung Score: 90+
Schriften: Lokales WOFF2 Preload direkt vom Origin (0ms Latenz)
Bilder: Next-Gen WebP/AVIF mit responsiven Größen (120KB)
Render-Blocker: Inlined Above-the-fold CSS + defer JS
LCP: 2,4s bei simuliertem 4G

1. WOFF2 Schriften selbst hosten & vorladen

Wir haben externe Google-Fonts-Aufrufe entfernt und die Schriftarten lokal als WOFF2 abgelegt. Im HTML-Kopf sorgt ein direktes Preload-Tag für parallelen Download:

<link rel="preload" href="/fonts/primary-latin.woff2" as="font" type="font/woff2" crossorigin>

2. Above-the-fold CSS Inlining

Header-, Layout- und Hero-Styles wurden direkt in einen <style>-Block im HTML eingebettet. Das senkte den FCP auf 1,3 Sekunden.

3. CI/CD Automatisierung

Die Innovation: Automatisierter PageSpeed Quality Gate in GitHub Actions

Im E-Commerce erodieren Ladezeit-Optimierungen häufig: Neue Marketing-Banner werden unkomprimiert hochgeladen oder externe Tracking-Pixel hinzugefügt, wodurch Core Web Vitals unbemerkt einbrechen.

Um dies dauerhaft zu verhindern, haben wir einen CI/CD Performance Gate in GitHub Actions integriert:

# .github/workflows/pagespeed-gate.yml name: Core Web Vitals CI Gate on: [pull_request, push] jobs: audit: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Run Google PageSpeed Insights API Audit run: | python scripts/ci_pagespeed_check.py \ --url "https://preview.moonbloomwalls.com" \ --min-score 85 \ --max-lcp 2.5 env: PAGESPEED_API_KEY: ${{ secrets.PAGESPEED_API_KEY }}

Funktionsweise: Jeder Pull Request prüft das Preview-Deployment über die offizielle Google PageSpeed Insights API. Sinkt der mobile Score unter 85 oder übersteigt der LCP 2,5 Sekunden, bricht der Build automatisch ab.

Prüfen Sie Ihre Website mit derselben PageSpeed API Engine

Testen Sie Ihre mobilen Core Web Vitals, LCP und kritische Anforderungsketten sofort mit unserem kostenlosen Tool.

Kostenlosen Check starten →
4. FAQ

Häufig gestellte Fragen

Wie verhindert automatisiertes PageSpeed-Testing in CI/CD Ladezeit-Verschlechterungen?
Über einen GitHub Actions Workflow, der bei jedem Pull Request die offizielle Google PageSpeed Insights REST API abfragt. Sinkt der mobile Score unter 85 oder übersteigt der LCP 2,5 Sekunden, schlägt der Build fehl und verhindert den fehlerhaften Release.
Warum verlangsamten kritische Anforderungsketten MoonBloom Walls?
Der Shop lud Google Fonts über ein externes CSS, was eine 2-Hop Kaskade auslöste (fonts.googleapis.com gefolgt von fonts.gstatic.com). Durch lokales Self-Hosting als WOFF2 mit Preload wurden 388ms blockierende Latenz eliminiert.
Welche geschäftlichen Auswirkungen gab es auf Google Ads?
Die Senkung des mobilen LCP von 6,8s auf 2,4s reduzierte Absprünge auf bezahltem mobilen Traffic in Deutschland, Österreich und Frankreich und steigerte die mobilen Checkout-Conversions um +22 %.