CI: Lighthouse CI mit Performance/A11y/SEO Budgets

[raifdmueller]

Kontext

Aktuell gibt es keine automatisierten Lighthouse-Tests. Performance-, Accessibility- und SEO-Regressionen können unbemerkt durchrutschen. Für ein öffentliches SPA, das stark auf SEO und JS-Performance angewiesen ist, ist das eine Lücke.

Vorschlag

Lighthouse CI als GitHub Action, die nach dem Build gegen die statische Preview-Version läuft und bei Budget-Verletzungen den PR blockiert.

Scope

1. Lighthouse CI Setup

• @lhci/cli als devDependency installieren
• lighthouserc.json im Repo-Root mit Konfiguration:
  • Collect: 3 Runs pro URL (Median für Stabilität)
  • URLs: / (Hauptseite, beide Sprachen via ?lang=de und ?lang=en)
  • Assert-Preset: lighthouse:recommended mit eigenen Budgets
• Upload-Target: temporary-public-storage (kein eigener LHCI-Server nötig)

2. Budgets

Initiale Schwellwerte — bewusst konservativ gewählt, können später verschärft werden:

Kategorie	Minimum	Begründung
Performance	85	React SPA ohne SSR, asciidoctor.js ist groß
Accessibility	95	Öffentliches Tool, sollte hoch sein
Best Practices	95	Sollte immer hoch sein
SEO	95	War explizit Optimierungsziel, muss abgesichert bleiben

Zusätzliche Assertions (als Warning, nicht Error):

• largest-contentful-paint ≤ 2.5s
• total-blocking-time ≤ 300ms
• cumulative-layout-shift ≤ 0.1
• unused-javascript — Warning, kein Block

3. GitHub Actions Integration

Neue Datei .github/workflows/lighthouse.yml:

```yaml
name: Lighthouse CI
on: [pull_request]
jobs:
lhci:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: '22' }
- run: npm ci
- run: npm run build
- run: npx http-server dist -p 5000 &
- run: npx wait-on http://localhost:5000
- run: npx lhci autorun
```

4. Dokumentation

• README-Abschnitt "Quality Gates" mit Verweis auf Lighthouse-Report-URL
• Budget-Rationale im `lighthouserc.json` als Kommentar

Offene Fragen

1. Baseline ermitteln: Aktuelle Werte messen, bevor Budgets gesetzt werden — verhindert zu strenge Budgets beim ersten Lauf
2. Lang-Varianten testen: Nur `/` oder beide Sprachen? Beide kostet doppelt CI-Zeit, bringt aber Regression-Schutz für i18n-bedingte Änderungen
3. Dark/Light Mode: Lighthouse rendert Default (Light). Sollen wir beide Themes testen?

Aufwand

~1 Stunde: Setup + Baseline-Messung + Budget-Kalibrierung + Doku. Kein Regressionsrisiko für die App selbst — nur neue CI-Konfiguration.