Synthetic Monitoring mit Lighthouse CI

1. Synthetic Monitoring vs. Real User Monitoring: zwei Rollen, kein Widerspruch

Synthetic Monitoring führt kontrollierte, wiederholbare Messungen unter simulierten Bedingungen durch, etwa mit einem festen Netzwerk-Throttling und einem definierten CPU-Slowdown-Faktor. Genau diese Kontrolle macht es zum richtigen Werkzeug für die CI/CD-Pipeline: Zwei Messungen desselben Codes liefern vergleichbare Werte, weil Variablen wie Gerätetyp, Netzwerkqualität oder Tageszeit eliminiert sind. Real User Monitoring (RUM) dagegen erfasst Messwerte aus echten Sitzungen echter Besucher mit echten Geräten und Netzwerken - unverzichtbar, um zu wissen, was Nutzer tatsächlich erleben, aber ungeeignet, um einen einzelnen Pull Request zu bewerten.

Der praktische Unterschied zeigt sich am Zeitpunkt der Erkenntnis: Synthetic Monitoring in der Pipeline findet eine Regression, bevor sie deployt wird. RUM findet eine Regression erst, nachdem echte Nutzer bereits darunter gelitten haben, dafür aber mit der vollen Bandbreite realer Endgeräte und Netzwerkbedingungen. Wer nur eines von beiden einsetzt, hat eine Lücke: Reines RUM bedeutet, dass jede Regression erst im Nachhinein sichtbar wird. Reines Synthetic Monitoring bedeutet, dass die Labordaten nie an der Realität der eigenen Kundschaft validiert werden. Lighthouse CI schließt genau die erste Lücke, indem es Performance-Messung zu einem festen, automatisierten Bestandteil jedes Deployments macht.

2. Lighthouse CI in der Pipeline installieren und konfigurieren

Lighthouse CI (LHCI) ist das offizielle Google-Tooling, um Lighthouse-Audits automatisiert und wiederholbar auszuführen. Die Installation erfolgt über @lhci/cli als Dev-Dependency, die Konfiguration über eine lighthouserc.js oder lighthouserc.json im Projekt-Root. Diese Datei definiert drei zentrale Blöcke: collect für die zu testenden URLs und Messparameter, assert für die Schwellenwerte, gegen die jede Metrik geprüft wird, und upload für das Ziel, an das die Ergebnisse gesendet werden.

Entscheidend für belastbare Ergebnisse ist die Anzahl der Durchläufe pro URL: Ein einzelner Lauf unterliegt Messrauschen durch Systemlast auf dem CI-Runner, weshalb numberOfRuns: 3 als Minimum gilt und LHCI automatisch den Median bildet. Für Magento-Shops mit Server-Side Rendering empfiehlt sich außerdem ein realistisches CPU-Throttling-Profil, das die Zielgeräte der eigenen Kundschaft widerspiegelt, statt der Lighthouse-Default-Werte, die für Desktop-Runner oft zu großzügig sind.

// lighthouserc.js: Grundkonfiguration fuer Lighthouse CI
module.exports = {
  ci: {
    collect: {
      // Anzahl Durchlaeufe pro URL, LHCI bildet automatisch den Median
      numberOfRuns: 3,
      settings: {
        preset: 'desktop',
        // CPU-Throttling realistisch an Zielhardware anpassen
        throttlingMethod: 'simulate',
        throttling: {
          cpuSlowdownMultiplier: 4,
        },
      },
      // Basis-URL wird pro Umgebung ueberschrieben (Staging/Preview)
      startServerCommand: 'php -S 0.0.0.0:8080 -t pub',
      startServerReadyPattern: 'Listening',
    },
    assert: {
      preset: 'lighthouse:recommended',
    },
    upload: {
      target: 'filesystem',
      outputDir: './lhci-reports',
    },
  },
};

3. Budget-Assertions: Builds gezielt scheitern lassen

Der eigentliche Wert von Lighthouse CI entsteht erst durch Budget-Assertions: feste Schwellenwerte, bei deren Überschreitung der Build mit einem Exit-Code ungleich null fehlschlägt und den Merge blockiert. Ohne Assertions ist LHCI nur ein Reporting-Tool, das Zahlen produziert, die niemand konsequent prüft. Mit Assertions wird Performance zu einer Eigenschaft, die genauso hart durchgesetzt wird wie ein fehlgeschlagener Unit-Test.

Assertions lassen sich pro Metrik auf drei Ebenen konfigurieren: off deaktiviert die Prüfung, warn gibt eine Warnung aus ohne den Build zu stoppen, und error lässt den Build fehlschlagen. Für kritische Metriken wie largest-contentful-paint oder total-blocking-time ist error mit einem numerischen maxNumericValue die richtige Wahl, während sich weniger kritische Audits wie uses-text-compression zunächst mit warn einführen lassen, um Teams nicht sofort mit vielen roten Builds zu überfordern. Ein separates budget.json im Standard-Performance-Budget-Format ergänzt die LHCI-Assertions um Ressourcen-Budgets pro Kategorie wie Skript- oder Bildgröße.

{
  "ci": {
    "assert": {
      "assertions": {
        "categories:performance": ["error", { "minScore": 0.85 }],
        "largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
        "total-blocking-time": ["error", { "maxNumericValue": 300 }],
        "cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }],
        "interactive": ["warn", { "maxNumericValue": 4000 }],
        "uses-text-compression": ["warn", {}],
        "uses-responsive-images": ["warn", {}]
      }
    }
  }
}

4. CI-Integration: GitHub Actions und GitLab CI im Detail

Die Integration in GitHub Actions läuft über einen dedizierten Job, der nach dem Build-Schritt ansetzt: Zuerst wird die Anwendung gebaut und lokal gestartet, dann führt lhci autorun die konfigurierten URLs aus und wertet die Assertions aus. Wichtig ist, den Job erst nach erfolgreichem Static-Content-Deploy zu starten, da ungebündeltes CSS oder JavaScript die Messwerte künstlich verfälscht und zu falschen Alarmen führt. Für Preview-Umgebungen empfiehlt sich, die tatsächliche Staging-URL statt eines lokalen Servers zu testen, um auch CDN- und Cache-Verhalten realistisch abzubilden.

In GitLab CI läuft dasselbe Prinzip über eine dedizierte Stage in der .gitlab-ci.yml, meist nach dem Deploy auf eine Review-App. Beide Systeme unterstützen das Hochladen der HTML-Reports als Artefakt, sodass Entwickler bei einem fehlgeschlagenen Build direkt den visuellen Lighthouse-Report öffnen können, statt nur eine rote Statuszeile zu sehen. Ein Token für den LHCI-Server oder ein Zugriffstoken für Filesystem-Storage in einem geteilten Cache-Verzeichnis sollte in beiden Fällen als CI-Secret hinterlegt werden, niemals im Repository.

# .github/workflows/lighthouse-ci.yml
name: Lighthouse CI

on:
  pull_request:
    branches: [main]

jobs:
  lighthouse:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install dependencies
        run: npm ci

      - name: Build static assets
        run: npm run build

      - name: Run Lighthouse CI against multiple page types
        run: npx lhci autorun --config=./lighthouserc.js
        env:
          LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}

      - name: Upload Lighthouse reports
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: lighthouse-reports
          path: ./lhci-reports

5. Historische Trends: LHCI-Server vs. Filesystem-Storage

Ein einzelner Build-Report beantwortet nur die Frage „Ist dieser Pull Request gut genug?“, nicht die wichtigere Frage „Verschlechtert sich unsere Performance schleichend über Wochen?“. Dafür braucht es historisches Trend-Tracking. LHCI bietet dafür zwei Storage-Optionen: Der selbst gehostete LHCI-Server speichert jeden Lauf in einer SQL-Datenbank, bietet eine Weboberfläche mit Zeitreihen-Diagrammen pro Metrik und URL, und kann automatisch Vergleiche gegen den letzten grünen Build der Zielbranch ziehen. Das ist der richtige Weg für Teams, die Performance-Trends aktiv im Blick behalten wollen.

Die leichtgewichtige Alternative ist Filesystem-Storage: Reports werden als JSON-Dateien in ein Artefakt-Verzeichnis geschrieben und über die CI-Pipeline persistiert, etwa in einem S3-Bucket oder als CI-Artefakt mit langer Aufbewahrungsfrist. Ohne Server-Betrieb lässt sich daraus mit einem einfachen Skript ein Trend über die letzten N Builds extrahieren und etwa als Kommentar im Pull Request posten. Für kleinere Teams ohne dedizierte Infrastruktur ist das oft der pragmatischere Einstieg, bevor sich der Betrieb eines LHCI-Servers lohnt.

#!/usr/bin/env bash
# Lighthouse CI gegen mehrere Seitentypen ausfuehren und Reports archivieren
set -euo pipefail

BASE_URL="https://staging.mironsoft-shop.example"
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
REPORT_DIR="./lhci-reports/${TIMESTAMP}"

mkdir -p "${REPORT_DIR}"

npx lhci collect \
  --url="${BASE_URL}/" \
  --url="${BASE_URL}/damen/kleider.html" \
  --url="${BASE_URL}/damen/sommerkleid-rot.html" \
  --url="${BASE_URL}/checkout/" \
  --numberOfRuns=3

npx lhci assert --config=./lighthouserc.js

# Reports fuer historischen Vergleich archivieren
cp -r .lighthouseci/*.json "${REPORT_DIR}/"
echo "Reports gespeichert unter ${REPORT_DIR}"

6. Mehrere Seitentypen statt nur der Startseite testen

Die Startseite eines Magento-Shops ist fast immer die am stärksten optimierte Seite: Sie hat wenige, sorgfältig ausgewählte Bilder, keine komplexen Formulare und oft einen aggressiv konfigurierten Full Page Cache. Kategorieseiten mit Layered Navigation, Produktlisten und Paginierung, Produktseiten mit Galerien, Varianten-Selektoren und Cross-Selling-Widgets, und der Checkout mit seinen vielen interaktiven Formularfeldern haben ein völlig anderes Performance-Profil. Ein Lighthouse-CI-Setup, das nur die Startseite testet, misst also systematisch die unrepräsentativste Seite des gesamten Shops.

Die url-Liste im collect-Block sollte deshalb mindestens vier Seitentypen abdecken: Startseite, eine Kategorieseite mit realistischer Produktanzahl, eine Produktseite mit Galerie und Bewertungen, sowie den ersten Checkout-Schritt. Bei Sonderfällen wie einem Facettenfilter mit vielen aktiven Filtern oder einer Suchergebnisseite mit null Treffern lohnt sich ein zusätzlicher Eintrag, da diese Zustände oft zusätzliche JavaScript-Logik und DOM-Elemente laden. Wichtig: Für eingeloggte oder personalisierte Zustände wie den warenkorbgefüllten Checkout braucht LHCI ein puppeteerScript, das vor der Messung Cookies setzt oder ein Login-Formular ausfüllt, da Lighthouse standardmäßig als anonymer Besucher misst.

7. Typische Magento-Fallstricke bei synthetischen Tests

Ein häufiger Fehler bei Magento-Shops ist, Lighthouse CI gegen eine lokale Docker-Umgebung mit deaktiviertem Full Page Cache laufen zu lassen, weil Entwickler den Cache beim lokalen Debugging typischerweise ausschalten. Die gemessenen Werte sind dann um ein Vielfaches schlechter als in Produktion und Assertions greifen entweder viel zu früh oder werden so großzügig gesetzt, dass sie in Produktion nutzlos sind. Die Zielumgebung für Lighthouse CI sollte deshalb immer eine Staging- oder Review-App mit produktionsnaher Konfiguration sein, inklusive aktiviertem Varnish oder integriertem Full Page Cache und deployten Static-Content-Assets.

Ein zweiter Fallstrick betrifft dynamische Inhalte: Produktbestände, Preise und Aktions-Banner ändern sich zwischen zwei Messläufen, was zu scheinbar zufälligem Messrauschen führt, das eigentlich Inhaltsänderung ist. Feste Test-Fixtures mit stabilen Produkt-SKUs und deaktivierten zeitgesteuerten Kampagnen für die Staging-Umgebung eliminieren diese Fehlerquelle. Ebenso wichtig: Drittanbieter-Skripte wie Chat-Widgets oder A/B-Testing-Tools sollten in der Staging-Umgebung entweder identisch zur Produktion geladen oder bewusst geblockt werden, aber niemals unkontrolliert unterschiedlich zwischen Produktion und Staging - sonst misst Lighthouse CI etwas anderes als das, was Kunden tatsächlich erleben.

8. RUM als Ergänzung: web-vitals im echten Traffic

Lighthouse CI allein deckt nicht ab, was bei echten Nutzern mit langsamen Mobilfunknetzen, älteren Geräten oder aktivierten Browser-Erweiterungen tatsächlich passiert. Genau hier ergänzt Real User Monitoring mit der web-vitals-JavaScript-Bibliothek die synthetischen Pipeline-Checks: Jede echte Sitzung sendet ihre LCP-, INP- und CLS-Werte an ein Analytics-Backend, wodurch sich die tatsächliche Verteilung über das gesamte Kundenspektrum abbilden lässt, nicht nur ein einzelner simulierter Lauf.

In der Praxis ergänzen sich beide Systeme in einem klaren Ablauf: Lighthouse CI verhindert, dass ein Pull Request mit offensichtlicher Regression überhaupt gemerged wird. RUM überwacht kontinuierlich, ob die Summe aller unauffälligen Änderungen über Wochen zu einer schleichenden Verschlechterung führt, die kein einzelner Build-Check je gefunden hätte. Wer nach einem RUM-Alarm die Ursache sucht, kann anschließend gezielt einen Lighthouse-CI-Lauf gegen die betroffene Seite und den vermuteten Commit-Bereich ausführen, um die Regression synthetisch zu reproduzieren und zu verifizieren, bevor der Fix gemerged wird.

10. Zusammenfassung

Synthetic Monitoring mit Lighthouse CI löst ein Kernproblem: Performance-Regressionen werden gefunden, bevor sie deployt werden, nicht erst, nachdem Kunden bereits darunter gelitten haben. Eine belastbare lighthouserc.js mit mehreren Durchläufen pro URL, klar definierten Budget-Assertions über error- und warn-Schwellenwerte sowie einer Integration in GitHub Actions oder GitLab CI macht Performance zu einer Eigenschaft, die genauso hart durchgesetzt wird wie ein fehlgeschlagener Test. Historisches Trend-Tracking über einen LHCI-Server oder einfache Filesystem-Storage macht schleichende Verschlechterungen sichtbar, die ein einzelner Build-Check nie erkennen würde.

Der entscheidende Hebel für Magento-Shops liegt im Testumfang: Wer nur die Startseite prüft, misst die unrepräsentativste Seite im gesamten Shop und übersieht Regressionen auf Kategorie-, Produkt- und Checkout-Seiten systematisch. Kombiniert mit Real User Monitoring über die web-vitals-Bibliothek entsteht ein vollständiges Bild: Synthetic Monitoring als vorbeugende Kontrolle in der Pipeline, RUM als kontinuierliche Beobachtung der tatsächlichen Nutzererfahrung im Feld.

11. FAQ: Synthetic Monitoring mit Lighthouse CI