Performance-Kultur im Team etablieren statt Einmal-Projekt

1. Warum Performance ohne Kultur wieder verschwindet

Ein Performance-Audit liefert am Tag der Übergabe beeindruckende Zahlen: LCP sinkt von 4,2 auf 2,1 Sekunden, das JavaScript-Bundle schrumpft um 40 Prozent, TTFB fällt unter 400 Millisekunden. Zwei bis drei Sprints später sind viele dieser Werte wieder auf dem alten Niveau, ohne dass irgendjemand bewusst etwas "verschlechtert" hätte. Der Grund ist strukturell: Feature-Arbeit hat eigene Deadlines, Performance hat keine, solange niemand danach fragt.

Jedes neue Feature bringt tendenziell mehr Code, mehr Abhängigkeiten, mehr Netzwerk-Requests mit sich. Ein zusätzliches Tracking-Snippet hier, eine neue npm-Abhängigkeit für ein Widget dort, ein synchron geladenes Drittanbieter-Skript für die nächste Marketing-Kampagne. Jede einzelne Änderung wirkt harmlos, in Summe erodieren sie das Ergebnis des Audits vollständig. Ohne wiederkehrende Prüfmechanismen bemerkt das Team die Regression erst, wenn Kunden sich beschweren oder die Konversionsrate spürbar fällt.

Der Ausweg ist keine zusätzliche einmalige Maßnahme, sondern eine Verschiebung der Verantwortung: Performance muss so selbstverständlich zum Entwicklungsalltag gehören wie Codeformatierung oder Tests. Die folgenden acht Praktiken zeigen, wie das konkret in einem Magento- und Hyvä-Team funktioniert, ohne dass eine einzelne Person zum Flaschenhals wird.

2. Performance-Budgets definieren

Ein Performance-Budget ist eine harte, messbare Obergrenze für eine Kennzahl, die bei Überschreitung den Build oder die Pull-Request-Merge blockiert. Ohne Zahl bleibt "Performance im Blick behalten" eine unverbindliche Absichtserklärung, die im Sprint-Alltag gegen konkrete Feature-Deadlines verliert. Typische Budgets für einen Hyvä-Shop: JavaScript-Bundle unter 180 KB komprimiert, LCP unter 2,5 Sekunden auf der Produktdetailseite, TTFB unter 600 Millisekunden für den Full Page Cache, Cumulative Layout Shift unter 0,1.

Wichtig ist, dass Budgets pro Seitentyp und pro Asset-Klasse definiert werden, nicht als eine globale Zahl für den gesamten Shop. Eine Kategorieseite mit hundert Produktkarten hat andere Grenzwerte als eine schlanke CMS-Landingpage. Für jedes Budget muss außerdem klar sein, wer es ändern darf: Ein Budget, das jede Entwicklerin bei Bedarf selbst lockern kann, ist kein Budget mehr, sondern eine Empfehlung. Änderungen an Budgetwerten gehören in einen eigenen Pull Request mit Review durch den aktuellen Performance Champion.

Budgets sollten sich außerdem an echten Nutzerdaten orientieren, nicht an Wunschzahlen. Wer im CrUX-Report sieht, dass 75 Prozent der mobilen Besucher auf Mittelklasse-Geräten mit 4G unterwegs sind, kalibriert Budgets entsprechend realistisch, statt sie an Werten eines High-End-Testgeräts im Büro auszurichten.

3. Performance-Checks in die Definition of Done einbetten

Ein Budget ohne Durchsetzungsmechanismus verkommt zur Dokumentation, die niemand liest. Der entscheidende Schritt ist, Performance-Prüfungen als festen Bestandteil der Definition of Done zu verankern, direkt neben Kriterien wie "Tests grün" oder "Code Review abgeschlossen". Praktisch bedeutet das: Ein GitHub-Actions-Workflow führt bei jedem Pull Request Lighthouse CI gegen eine Staging-Umgebung aus und prüft die im vorigen Abschnitt definierten Budgets automatisch.

Der Workflow muss als Required Status Check in den Branch-Protection-Regeln hinterlegt sein, sodass ein Merge technisch unmöglich ist, solange der Check rot ist. Genau dieser Zwang macht den Unterschied zu einem freiwilligen Audit: Niemand kann eine Regression "aus Zeitgründen" durchwinken, weil die Pipeline es schlicht nicht zulässt. Ausnahmen sollten selten und immer explizit dokumentiert sein, etwa über ein befristetes Label mit Ablaufdatum, nie über ein stillschweigend übersprungenes Check.

# .github/workflows/lighthouse-ci.yml
# Gate every pull request on a performance budget before merge is allowed
name: Lighthouse CI Performance Gate

on:
  pull_request:
    branches: [main]

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

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install dependencies
        run: npm ci

      - name: Build Hyva storefront assets
        run: npm run build --workspace=app/design/frontend/Mironsoft/default

      - name: Run Lighthouse CI against staging PLP/PDP
        run: npx @lhci/cli autorun --config=./lighthouserc.json
        env:
          LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}

      # lighthouserc.json defines the budget assertions (see next example).
      # A failing assertion sets a non-zero exit code, which fails this job
      # and blocks the merge via required-status-checks branch protection.

{
  "ci": {
    "collect": {
      "url": [
        "https://staging.mironsoft.de/",
        "https://staging.mironsoft.de/catalog/product/view/id/1234"
      ],
      "numberOfRuns": 3
    },
    "assert": {
      "assertions": {
        "largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
        "total-blocking-time": ["error", { "maxNumericValue": 200 }],
        "cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }],
        "server-response-time": ["error", { "maxNumericValue": 600 }],
        "resource-summary:script:size": ["error", { "maxNumericValue": 180000 }]
      }
    },
    "upload": {
      "target": "temporary-public-storage"
    }
  }
}

4. Die rotierende Rolle des Performance Champion

Ein einzelner permanenter Performance-Verantwortlicher wird fast zwangsläufig zum Engpass: Alle Fragen landen bei einer Person, das Wissen bleibt bei ihr konzentriert, und wenn sie im Urlaub oder krank ist, bleiben Performance-Themen liegen. Zusätzlich verstärkt eine dauerhafte Einzelrolle die falsche Botschaft, Performance sei die Aufgabe einer Spezialistin und nicht die Verantwortung des gesamten Teams. Das rotierende Performance-Champion-Modell löst beide Probleme gleichzeitig.

Konkret übernimmt jedes Teammitglied für zwei bis vier Wochen die Rolle: Budget-Verletzungen in der CI prüfen, RUM-Dashboards wöchentlich sichten, bei Pull Requests mit Performance-Relevanz das Review übernehmen, und bei Bedarf im Daily kurz über auffällige Trends berichten. Die Rotation stellt sicher, dass nach zwölf Monaten jedes Teammitglied mehrfach tief mit den Tools und Denkweisen der Performance-Arbeit in Berührung gekommen ist, statt dass dieses Wissen bei einer einzigen Person verbleibt.

Damit die Übergabe funktioniert, braucht jede Rotation eine kurze, dokumentierte Übergabe: offene Regressionen, laufende Experimente, aktuelle Budgetwerte und deren Begründung. Ein einfaches Wiki-Template mit fünf Stichpunkten reicht, solange es bei jedem Wechsel tatsächlich gepflegt wird.

5. Erfolge sichtbar machen: Dashboards, Changelogs, Retros

Performance-Arbeit, die niemand sieht, wird in der nächsten Priorisierungsrunde gegen sichtbare Feature-Arbeit verlieren. Ein öffentlich im Team-Slack gepinntes RUM-Dashboard mit LCP- und INP-Trendlinien der letzten zwölf Wochen macht Fortschritt greifbar, auch für Product Owner und Stakeholder ohne technischen Hintergrund. Wichtig ist die Trendlinie, nicht der Momentanwert: Ein einzelner guter Messwert überzeugt niemanden, eine stetig fallende Kurve über mehrere Monate schon.

Ein eigener Abschnitt "Performance" im technischen Changelog neben Feature- und Bugfix-Einträgen signalisiert, dass diese Arbeit denselben Stellenwert hat wie sichtbare Änderungen. Sätze wie "LCP auf der Kategorieseite von 3,1s auf 2,3s reduziert durch Preload des Hero-Bildes" sind konkret, nachvollziehbar und lassen sich in der nächsten Sprint-Retro als Erfolg feiern. Genau diese kleinen, wiederkehrenden Erwähnungen erzeugen langfristig mehr Wirkung als ein einmaliger Blogpost über ein großes Performance-Projekt.

In der Retro selbst lohnt sich eine feste Frage: "Was hat sich bei Performance diese Sprint-Runde verändert, positiv wie negativ?" Diese Wiederholung verankert das Thema im Ritual des Teams, statt es zu einem Sonderthema zu machen, das nur bei Problemen auftaucht.

6. Blameless Post-Incident-Reviews bei Regressionen

Wenn trotz Budgets und CI-Checks eine Regression in Produktion landet, entscheidet die Reaktion des Teams darüber, ob Performance-Kultur wächst oder erstickt wird. Ein blameless Post-Incident-Review fragt konsequent "welcher Prozess hat das zugelassen", niemals "wer hat das verursacht". Diese Unterscheidung ist keine Formalität: Sobald Einzelpersonen für Fehler verantwortlich gemacht werden, hören Teams auf, Probleme offen zu melden, und Regressionen bleiben länger unentdeckt, weil niemand sie freiwillig anspricht.

Der Review dokumentiert eine Timeline vom Deploy bis zur Behebung, die messbare Auswirkung, und vor allem konkrete, umsetzbare Maßnahmen: fehlte ein Budget-Assertion für Drittanbieter-Skripte, wurde ein CI-Check versehentlich als optional markiert, gab es keinen Alert-Schwellenwert im RUM-System. Jede Maßnahme wird als Ticket mit Owner und Deadline in den nächsten Sprint aufgenommen, nicht als vage Absichtserklärung im Dokument belassen. So wird aus jedem Vorfall eine strukturelle Verbesserung statt einer wiederholten Ausrede.

# Post-Incident Review: Performance Regression
# Fill in within 48 hours of resolution. No blame, focus on systems and process.

## Summary
- What regressed: (e.g. LCP on PDP rose from 2.1s to 4.6s)
- When detected: (RUM alert / user report / weekly CWV report)
- Duration of impact: (from deploy to fix)

## Timeline
- HH:MM - Deploy shipped (PR #1234, feature X)
- HH:MM - RUM dashboard crossed alert threshold
- HH:MM - On-call performance champion paged
- HH:MM - Root cause identified: unbudgeted third-party script added without CI check
- HH:MM - Fix deployed, metrics confirmed recovered

## Root Cause
Describe the technical cause without naming individuals. Focus on what
allowed the regression to reach production (e.g. missing budget assertion
for third-party scripts, a Lighthouse CI job that was allowed to be skipped).

## What Went Well
- RUM alerting caught the regression within 20 minutes

## What Went Wrong
- The Lighthouse CI budget did not cover third-party script weight
- The PR was merged with a CI check marked "skipped" instead of blocking

## Action Items
- [ ] Add resource-summary:third-party:size assertion to lighthouserc.json
- [ ] Make Lighthouse CI a required status check, remove skip option
- [ ] Add this scenario to the performance champion onboarding checklist

7. Kontinuierliches Monitoring statt Einmal-Audit

Ein Lighthouse-Report, der einmal im Quartal manuell erstellt wird, ist am Tag der Erstellung bereits eine Momentaufnahme unter Laborbedingungen. Reale Nutzer greifen mit unterschiedlichsten Geräten, Netzwerken und Browserversionen zu, und Regressionen zwischen zwei Audits bleiben komplett unsichtbar. Real User Monitoring (RUM) über die web-vitals-Bibliothek erfasst dagegen jede echte Sitzung und macht Trends über Wochen und Monate sichtbar, nicht nur Stichproben.

Synthetic Monitoring ergänzt RUM um kontrollierte, wiederholbare Messungen unter konstanten Bedingungen, ideal um einzelne Deploys gegeneinander zu vergleichen, ohne Rauschen durch unterschiedliche Nutzergeräte. Die Kombination aus beiden liefert ein vollständiges Bild: RUM zeigt, was Nutzer tatsächlich erleben, Synthetic Monitoring zeigt präzise, welcher Commit eine Verschlechterung verursacht hat. Ein wöchentlicher automatisierter Trend-Report, der beide Datenquellen zusammenfasst und ins Team-Slack postet, hält das Thema präsent, ohne dass jemand aktiv ein Dashboard aufrufen muss.

Der entscheidende kulturelle Unterschied: Ein Audit beantwortet die Frage "wie steht es heute", kontinuierliches Monitoring beantwortet die Frage "wie entwickelt sich das über Zeit". Nur die zweite Frage erlaubt, Regressionen zu erkennen, bevor Kunden sie melden.

#!/usr/bin/env bash
# weekly-cwv-report.sh - post a Core Web Vitals trend summary to Slack
set -euo pipefail

CRUX_API_KEY="${CRUX_API_KEY:?Missing CRUX_API_KEY}"
SLACK_WEBHOOK="${SLACK_WEBHOOK_URL:?Missing SLACK_WEBHOOK_URL}"
ORIGIN="https://mironsoft.de"

# Pull this week's field data from the CrUX History API
response="$(curl -s -X POST \
  "https://chromeuxreport.googleapis.com/v1/records:queryHistoryRecord?key=${CRUX_API_KEY}" \
  -H 'Content-Type: application/json' \
  -d "{\"origin\": \"${ORIGIN}\", \"metrics\": [\"largest_contentful_paint\", \"interaction_to_next_paint\"]}")"

lcp_p75="$(echo "$response" | jq -r '.record.metrics.largest_contentful_paint.percentilesTimeseries.p75s[-1]')"
inp_p75="$(echo "$response" | jq -r '.record.metrics.interaction_to_next_paint.percentilesTimeseries.p75s[-1]')"

# Compare against last week's stored baseline to detect a regression trend
baseline_file="./cwv-baseline.json"
prev_lcp="$(jq -r '.lcp_p75' "$baseline_file")"

status="stable"
if (( lcp_p75 > prev_lcp + 200 )); then
  status="regression detected"
fi

curl -s -X POST "$SLACK_WEBHOOK" \
  -H 'Content-Type: application/json' \
  -d "{\"text\": \"Weekly CWV report for ${ORIGIN}: LCP p75 = ${lcp_p75}ms, INP p75 = ${inp_p75}ms. Status: ${status}\"}"

echo "{\"lcp_p75\": ${lcp_p75}, \"inp_p75\": ${inp_p75}}" > "$baseline_file"

8. Tooling für die Performance-Kultur

Kultur allein reicht nicht, wenn die passenden Werkzeuge fehlen, um sie konsequent durchzusetzen. Neben Lighthouse CI für Seitenmetriken braucht ein Team einen Bundle-Analyzer, der bei jedem Build sichtbar macht, welches Modul wie viel zum JavaScript-Gewicht beiträgt. Für Hyvä-Shops mit Vite oder Webpack liefert rollup-plugin-visualizer beziehungsweise webpack-bundle-analyzer eine Treemap-Darstellung, die sofort zeigt, wenn eine neue Abhängigkeit unverhältnismäßig viel Platz beansprucht.

Für harte Grenzwerte auf Datei- oder Bundle-Ebene eignet sich ein dediziertes Tool wie bundlesize oder size-limit, das als eigener CI-Schritt läuft und unabhängig von Lighthouse einen zweiten, granulareren Kontrollpunkt bildet. Die Kombination beider Ebenen, Seiten-Metriken via Lighthouse CI und Bundle-Grenzwerte via bundlesize, deckt sowohl die Nutzerperspektive als auch die technische Ursache in einem einzigen Pull Request ab, bevor der Code überhaupt gemerged wird.

{
  "scripts": {
    "build": "vite build",
    "test:bundlesize": "bundlesize"
  },
  "bundlesize": [
    {
      "path": "./pub/static/frontend/Mironsoft/default/**/js/checkout.min.js",
      "maxSize": "45 kB",
      "compression": "brotli"
    },
    {
      "path": "./pub/static/frontend/Mironsoft/default/**/js/catalog.min.js",
      "maxSize": "60 kB",
      "compression": "brotli"
    },
    {
      "path": "./pub/static/frontend/Mironsoft/default/**/css/styles.css",
      "maxSize": "35 kB",
      "compression": "brotli"
    }
  ]
}

9. Rollout-Plan für ein bestehendes Team

Ein Team, das bisher ohne Performance-Kultur gearbeitet hat, sollte nicht versuchen, alle acht Praktiken gleichzeitig einzuführen. Der bewährte Einstieg ist ein einziges, hartes Budget, etwa LCP auf der Produktdetailseite, gemessen über einen einfachen Lighthouse-CI-Lauf, zunächst nur als informativer Check ohne Merge-Blockade. Zwei bis drei Sprints als Beobachtungsphase zeigen, wie oft der Grenzwert tatsächlich verletzt würde, bevor er scharf geschaltet wird.

Erst wenn dieser erste Check stabil läuft und akzeptiert ist, folgt die Rotation der Champion-Rolle, dann die Sichtbarkeit über ein Dashboard, dann die restlichen Budgets für Bundle-Größe und TTFB. Diese Reihenfolge verhindert Widerstand: Ein Team, das an einem Tag mit fünf neuen Pflichtprozessen konfrontiert wird, empfindet Performance-Kultur als Bürokratie. Ein Team, das über acht bis zwölf Wochen schrittweise Kontrolle über eine sich verbessernde Kennzahl gewinnt, empfindet sie als Werkzeug.

Ein realistischer Zeitplan: Woche 1 bis 2 Budget definieren und als informativen Check einführen, Woche 3 bis 4 Merge-Blockade aktivieren, Woche 5 bis 6 erste Champion-Rotation starten, Woche 7 bis 8 Dashboard und Changelog-Sektion aufsetzen, ab Woche 9 erste blameless Reviews bei auftretenden Regressionen durchführen und den Prozess in der Retro reflektieren.

Die Tabelle macht deutlich, dass der Unterschied nicht in der fachlichen Tiefe der Analyse liegt, ein gutes Audit kann technisch exzellent sein, sondern im Mechanismus, der Ergebnisse über die Zeit hält. Ohne Durchsetzung in der CI und ohne verteilte Verantwortung verpufft selbst die beste Analyse innerhalb weniger Monate.

10. Zusammenfassung

Eine Performance-Kultur im Team löst ein Problem, das ein einmaliges Audit strukturell nicht lösen kann: Sie hält Gewinne über die Zeit, statt sie nach dem nächsten Feature-Sprint verpuffen zu lassen. Der Kern liegt in messbaren Budgets, die als Required Status Check die Merge-Freigabe blockieren, in einer rotierenden Champion-Rolle statt einer einzelnen Verantwortlichen, in sichtbarer Kommunikation über Dashboards, Changelogs und Retros, und in blameless Post-Incident-Reviews, die aus jeder Regression eine strukturelle Verbesserung machen.

Kontinuierliches Monitoring über RUM und Synthetic Testing ersetzt den punktuellen Blick eines Quartals-Audits durch einen dauerhaften Trend, der Regressionen erkennt, bevor Kunden sie spüren. Wer diese acht Praktiken schrittweise über acht bis zwölf Wochen einführt, statt sie an einem Tag zu verordnen, baut eine Kultur auf, die auch dann trägt, wenn Feature-Druck wieder steigt.

11. FAQ: Performance-Kultur im Team