Performance-Budgets und Governance im Team verankern

1. Warum Performance nicht die Aufgabe einer einzelnen Person sein darf

In vielen Magento-Teams gibt es genau eine Person, die für Performance zuständig ist: den Senior-Entwickler, der Varnish versteht, oder die eine Kollegin, die regelmässig Lighthouse-Reports liest. Jede andere Entscheidung im Team, neue Features, Drittanbieter-Integrationen, Marketing-Skripte, wird ohne Rücksicht auf Ladezeit getroffen, weil "die Performance-Person das schon prüft". Das Ergebnis ist ein Flaschenhals: Diese eine Person wird zum Nadelöhr für jede Deploy-Entscheidung, und sobald sie im Urlaub ist oder das Unternehmen verlässt, verschlechtert sich die Performance schleichend, ohne dass es jemand bemerkt, bis Kunden sich beschweren oder der Umsatz sinkt.

Das strukturelle Problem heisst Single Point of Failure für Wissen und Verantwortung. Wer Performance an eine Person delegiert, signalisiert dem Rest des Teams implizit, dass Ladezeit nicht ihre Aufgabe ist. Governance bedeutet, dieses Muster bewusst aufzubrechen: Jeder, der Code in ein Magento- oder Hyvä-Projekt merged, trägt mit Verantwortung für dessen Auswirkung auf LCP, INP und Bundle-Grösse, genauso wie jeder für Sicherheitslücken oder Testabdeckung mitverantwortlich ist.

2. Performance-Budgets definieren: Von der Kennzahl zum Team-Vertrag

Ein Performance-Budget ist eine feste, im Team vereinbarte Obergrenze für eine messbare Grösse, zum Beispiel die maximale JavaScript-Bundle-Grösse, die maximale Time-to-First-Byte oder ein LCP-Schwellenwert für die Kategorieseite. Der entscheidende Unterschied zu einer reinen Zielmetrik: Ein Budget wird technisch durchgesetzt, nicht nur gemessen. Ohne Durchsetzung bleibt ein Budget eine Absichtserklärung, die im Sprint-Stress als erstes fällt.

Budgets sollten pro Seitentyp definiert werden, weil eine Kategorieseite mit 48 Produkten andere Anforderungen hat als eine Checkout-Seite. Für Hyvä-Shops empfiehlt sich ein initiales JS-Bundle-Budget von 170 bis 200 KB (gzip), ein LCP-Budget von unter 2,0 Sekunden auf dem 75. Perzentil und ein CSS-Budget von unter 60 KB nach Tailwind-Purge. Diese Zahlen gehören nicht in eine Wiki-Seite, die niemand liest, sondern in eine maschinenlesbare Konfigurationsdatei, die von der CI-Pipeline ausgewertet wird.

{
  "path": "/catalogsearch/result/",
  "resourceSizes": [
    { "resourceType": "script", "budget": 190 },
    { "resourceType": "stylesheet", "budget": 60 },
    { "resourceType": "image", "budget": 350 },
    { "resourceType": "total", "budget": 700 }
  ],
  "timings": [
    { "metric": "interactive", "budget": 3500 },
    { "metric": "largest-contentful-paint", "budget": 2000 }
  ]
}

3. Performance-Checks im Code-Review verankern

Ein Performance-Budget entfaltet erst Wirkung, wenn es Teil des alltäglichen Code-Reviews wird, nicht ein separater Prozess, der irgendwann danach läuft. Jede Pull-Request-Vorlage sollte eine kurze Performance-Checkliste enthalten: Wurden neue Bilder mit width/height und passendem Format eingebunden? Wurde ein neues npm-Paket darauf geprüft, ob es tree-shakebar ist? Löst die Änderung zusätzliche Netzwerk-Requests im kritischen Rendering-Pfad aus?

Reviewer sollten explizit ermutigt werden, eine PR wegen Performance-Regressionen abzulehnen, genau wie sie es bei fehlenden Tests tun würden. In der Praxis funktioniert das am besten mit einem festen Kommentar-Template, das Reviewer bei Auffälligkeiten einfügen, kombiniert mit einem lokalen Skript, das Entwickler selbst vor dem Push ausführen können. So wird die Prüfung zur Gewohnheit statt zur nachträglichen Kontrolle, und niemand fühlt sich blossgestellt, weil das Tool die Zahl liefert, nicht der Kollege.

#!/usr/bin/env bash
# Pre-push hook: block the push if the JS bundle budget is violated
set -euo pipefail

BUDGET_KB=200
BUILD_DIR="pub/static/frontend/Mironsoft/default/en_US"

bin/npm --prefix app/design/frontend/Mironsoft/default/web/tailwind run build

BUNDLE_SIZE_KB=$(du -k "$BUILD_DIR"/js/*.js 2>/dev/null | awk '{sum+=$1} END {print sum}')

if [ "$BUNDLE_SIZE_KB" -gt "$BUDGET_KB" ]; then
  echo "Performance budget exceeded: ${BUNDLE_SIZE_KB}KB > ${BUDGET_KB}KB"
  echo "Review the code review checklist before pushing: docs/performance-checklist.md"
  exit 1
fi

echo "Bundle size OK: ${BUNDLE_SIZE_KB}KB / ${BUDGET_KB}KB"

4. CI/CD als Gatekeeper: Budgets automatisiert durchsetzen

Menschliche Reviewer übersehen Regressionen, besonders wenn ein Bundle über viele kleine Commits langsam wächst. Deshalb gehört die eigentliche Durchsetzung eines Performance-Budgets in die CI-Pipeline, nicht in den guten Willen einzelner Reviewer. Ein Lighthouse-CI-Lauf gegen eine Staging-Instanz bei jedem Pull Request, kombiniert mit einem Bundle-Size-Check, macht Regressionen sichtbar, bevor sie in den Main-Branch gelangen.

Wichtig ist, dass ein Budget-Verstoss den Build tatsächlich rot färbt, nicht nur eine Warnung im PR-Kommentar hinterlässt, die niemand liest. Ein rotes Build ist unmissverständlich und verhindert das Merge-Recht technisch, ähnlich wie ein fehlgeschlagener Unit-Test. Gleichzeitig sollte es einen dokumentierten, bewussten Ausnahmeprozess geben, etwa ein Label wie "budget-override-approved", das ein Tech Lead explizit setzen muss, damit Ausnahmen nachvollziehbar bleiben statt zur stillen Norm zu werden.

name: performance-budget

on:
  pull_request:
    branches: [main]

jobs:
  lighthouse-ci:
    runs-on: ubuntu-latest
    steps:
      # Check out the pull request branch
      - uses: actions/checkout@v4

      - name: Install dependencies
        run: bin/npm ci

      - name: Build Hyva theme assets
        run: bin/npm run build

      # Fail the build if any page exceeds its Lighthouse budget
      - name: Run Lighthouse CI against staging
        uses: treosh/lighthouse-ci-action@v11
        with:
          configPath: ./lighthouserc.json
          uploadArtifacts: true
          temporaryPublicStorage: true

      - name: Post budget results as a PR comment
        if: failure()
        run: echo "Performance budget violated, see the Lighthouse CI report above"

5. Dashboards für das ganze Team sichtbar machen

Performance-Daten, die nur eine Person in einem privaten Lighthouse-Report sieht, verändern kein Teamverhalten. Ein Dashboard, das im Daily Standup, im Teamraum auf einem Bildschirm oder als Slack-Digest sichtbar ist, macht Performance zu einem geteilten Zustand statt zu geheimem Wissen. Grafana mit einer Prometheus- oder InfluxDB-Datenquelle, gespeist aus Real User Monitoring über die web-vitals-Bibliothek, eignet sich gut, weil es Trends über Wochen zeigt statt nur Momentaufnahmen.

Entscheidend ist die Granularität: Ein aggregierter Gesamtwert verschleiert, welches Team oder welche Seite verantwortlich ist. Ein Dashboard, das p75-LCP pro Seitentyp und pro letztem Deploy zeigt, macht die Kausalkette zwischen einer Änderung und einer Regression sofort sichtbar. Für Magento-Teams empfiehlt sich zusätzlich eine Ansicht, die Deploy-Marker aus der CI-Pipeline über die Performance-Zeitreihe legt, damit ein plötzlicher Ausschlag direkt einem Release zugeordnet werden kann.

{
  "title": "LCP p75 by Page Type (7d)",
  "targets": [
    {
      "expr": "histogram_quantile(0.75, sum(rate(web_vitals_lcp_seconds_bucket[7d])) by (page_type, le))",
      "legendFormat": "{{page_type}}"
    }
  ],
  "thresholds": {
    "steps": [
      { "color": "green", "value": 0 },
      { "color": "yellow", "value": 2.0 },
      { "color": "red", "value": 2.5 }
    ]
  }
}

6. Performance als Sprint-Ziel statt Nebensache

Solange Performance-Arbeit nur "wenn Zeit übrig ist" stattfindet, findet sie praktisch nie statt, weil im Sprint-Alltag nie Zeit übrig bleibt. Performance-Aufgaben gehören als eigene Tickets ins Backlog, geschätzt und priorisiert wie jedes Feature, nicht als unsichtbare Nebenarbeit, die niemandem im Sprint-Board zugerechnet wird. Ein einfacher, wirkungsvoller Ansatz: Jeder Sprint reserviert einen festen Anteil, zum Beispiel 10 bis 15 Prozent der Kapazität, explizit für Performance- und technische Schuld-Arbeit.

Damit das nicht zur Lippenbekenntnis verkommt, sollte Performance auch in der Definition of Done auftauchen: Eine Story gilt erst als fertig, wenn das Budget für die betroffene Seite eingehalten wird. Product Owner müssen verstehen, dass eine Regression in der Checkout-Performance genauso ein Bug ist wie ein fehlerhafter Rabattcode, und entsprechend im Backlog priorisiert werden muss, statt als "technisches Detail" hintenangestellt zu werden.

7. Umgang mit Widerstand bei konkurrierenden Feature-Deadlines

In der Praxis kollidiert Performance-Arbeit regelmässig mit Feature-Deadlines, besonders vor grossen Kampagnen wie einem Black-Friday-Launch. Der häufigste Fehler ist, Performance-Budgets in solchen Momenten stillschweigend zu ignorieren, weil "wir jetzt keine Zeit haben". Genau hier zeigt sich, ob Governance echt ist oder nur auf dem Papier existiert: Ein Ausnahmeprozess mit sichtbarer Genehmigung ist besser als eine stille Regel-Umgehung, weil er die Kosten der Entscheidung sichtbar macht.

Hilfreich ist, Performance-Kosten in Geschäftssprache zu übersetzen, statt in Millisekunden zu argumentieren: Eine Sekunde zusätzliche Ladezeit auf der Produktseite korreliert erfahrungsgemäss mit spürbar sinkenden Conversion-Raten, gerade auf mobilen Geräten. Wenn Stakeholder verstehen, dass ein verpasstes Performance-Budget reale Umsatzverluste bedeutet, wird die Priorisierung einfacher. Ein Eskalationspfad, der Tech Lead und Product Owner gemeinsam entscheiden lässt statt eine Seite allein, verhindert zudem, dass Performance immer die unterlegene Partei ist.

8. Rollen, Verantwortlichkeiten und eine nachhaltige Performance-Kultur

Ein Performance-Champion-Modell funktioniert besser als eine einzelne dauerhaft verantwortliche Person: Ein rotierender Champion pro Sprint oder Quartal moderiert die Performance-Reviews, pflegt die Budget-Konfiguration und ist erster Ansprechpartner bei Regressionen, ohne alleiniger Ausführender zu sein. So verteilt sich Wissen über das gesamte Team, und die Rolle wird zur Lernchance statt zur Dauerlast für eine einzelne Person.

In Magento- und Hyvä-Projekten lässt sich diese Verantwortung sauber über Codeowner-Regeln und Layout-XML-Konventionen abbilden: Kritische Templates und Blöcke, die häufig LCP oder INP beeinflussen, etwa Kategorieseiten oder der Checkout, bekommen einen Kommentarblock, der auf das zugehörige Budget verweist, sodass jeder Entwickler beim Öffnen der Datei sofort den Kontext sieht. Retrospektiven sollten Performance-Regressionen genauso besprechen wie Produktionsvorfälle, inklusive kurzer Root-Cause-Analyse, damit dieselbe Ursache nicht beim nächsten Release wiederkehrt.

<!-- Layout XML: mark a performance-critical block with its budget owner -->
<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:noNamespaceSchemaLocation="urn:magento:framework:View/Layout/etc/page_configuration.xsd">
    <body>
        <!-- Performance budget: LCP under 2.0s, owner: category page squad -->
        <!-- See performance-budgets.json for the enforced threshold -->
        <referenceBlock name="category.products.list">
            <arguments>
                <argument name="cache_lifetime" xsi:type="number">3600</argument>
            </arguments>
        </referenceBlock>

        <!-- Reviewer checklist item: does this block add render-blocking JS? -->
        <remove src="ThirdParty_Module::js/heavy-banner-rotator.js"/>
    </body>
</page>

9. Performance-Governance im Vergleich: Einzelverantwortung vs. Team-Verantwortung

Der Unterschied zwischen einem Team, das Performance einer einzelnen Person überlässt, und einem Team mit etablierter Governance zeigt sich an denselben wiederkehrenden Dimensionen. Die folgende Übersicht fasst zusammen, wo die grössten Unterschiede liegen.

In der Praxis verstärken sich diese Dimensionen gegenseitig: Ohne sichtbares Dashboard gibt es keine Grundlage für ein Sprint-Ziel, und ohne Sprint-Ziel bleibt ein Code-Review-Hinweis folgenlos. Wer alle vier Hebel gemeinsam einführt, sieht typischerweise innerhalb weniger Sprints eine spürbar stabilere Performance-Baseline statt der üblichen Sägezahn-Kurve aus Verbesserung nach einem Audit und langsamem Wiederverfall danach.

10. Zusammenfassung

Performance-Governance löst ein strukturelles Problem: Solange Ladezeit die Aufgabe einer einzelnen Person bleibt, verschlechtert sie sich zwangsläufig, sobald diese Person nicht verfügbar ist oder unter Zeitdruck steht. Ein Performance-Budget entfaltet nur Wirkung, wenn es technisch durchgesetzt wird, im Code-Review sichtbar ist, in der CI-Pipeline den Build rot färbt und über ein Dashboard für das gesamte Team einsehbar bleibt. Erst diese Kombination macht aus einer guten Absicht eine belastbare Praxis.

Der entscheidende Kulturwandel liegt darin, Performance als festen Bestandteil der Sprint-Planung zu behandeln, mit reservierter Kapazität und einem Platz in der Definition of Done, statt als Nebensache, die bei Deadline-Druck als erstes gestrichen wird. Ein rotierendes Champion-Modell verteilt Wissen im Team, und ein sichtbarer, dokumentierter Ausnahmeprozess sorgt dafür, dass Widerstand bei konkurrierenden Feature-Deadlines produktiv statt destruktiv verläuft.

11. FAQ: Performance-Governance im Team