Performance Budgets, die wirklich wirken

Ein Performance Budget ist eine klare Obergrenze für Ladezeit, Interaktivität und Bytes, die dein Team nicht überschreitet. Es schafft Fokus in Planung, Design und Umsetzung – und übersetzt »Schnelligkeit« in messbare, verhandelbare Zahlen. Dieser Leitfaden zeigt, wie du sinnvolle Budgets definierst, im Prozess verankerst und mit leichtem Tooling automatisierst.

Warum Performance Budgets?

• Direkter Impact: Schnellere Seiten erhöhen Conversion, Retention und SEO‑Sichtbarkeit.
• Gemeinsame Sprache: Dev, PO, Design und QA diskutieren Zahlen statt Bauchgefühl.
• Scope-Controlling: Neues Feature? Budget zeigt Kosten in ms/KB und zwingt zu Priorisierung.
• Nachhaltigkeit: Preventive Care statt »Performance‑Sprint« nach dem Go‑Live.

Was messen wir?

• Core Web Vitals: LCP (Largest Contentful Paint), INP (Interaction to Next Paint), CLS (Cumulative Layout Shift).
• Netzwerk & CPU: TTFB, TBT (Labor), Request‑Anzahl, Gesamtgewicht (gzip/br).
• Kontextbezogen: Route‑spezifisch (Home vs. Artikel), Geräteklasse (Mobile zuerst), reale Nutzer (RUM) vs. Labor.

Gute Startziele (mobil, p75)

• LCP: ≤ 2.5 s
• INP: ≤ 200 ms
• CLS: ≤ 0.10
• TTFB: ≤ 0.8 s
• TBT (Labor): ≤ 150–200 ms
• JS gesamt (gzip): ≤ 170–200 KB (Initial Load)
• Critical Images (above the fold): ≤ 200–300 KB (modernes Format)
• Requests (initial): ≤ 50

Hinweis: Sieh diese Werte als Ausgangspunkt. Branchen, Inhalte und Geräte mischen die Karten. Kalibriere mit deinen Daten.

Budget‑Typen

• Metrik‑basiert: LCP/INP/CLS/TTFB/TBT als Obergrenzen (User‑zentriert, PO‑freundlich).
• Ressourcen‑basiert: KB‑Budgets für JS/CSS/Fonts/Images + Request‑Limits (Dev‑nah, präventiv).
• Route‑basiert: Eigene Budgets für kritische Seiten (z. B. Landing vs. Dashboard).
• Regression‑Budgets: »Nicht schlechter als Baseline + X%« (schützt inkrementell).

In 5 Schritten zu sinnvollen Budgets

1. Baseline messen: 3–7 Tage RUM (z. B. p75 der Web Vitals) und Labor (Lighthouse, WebPageTest) mit mobilem Profil (4× CPU‑Throttling, 4G).
2. Kandidaten wählen: 2–3 Web Vitals + 2 Ressourcen‑Budgets (JS‑KB, Requests) reichen zum Start.
3. Ziele festlegen: Entweder »Industry Good« (z. B. LCP ≤ 2.5 s) oder »Baseline – 15 %«.
4. Routen schneiden: Budgets für Hauptpfade (Start, Artikel, Produktseite) separat festlegen.
5. Automatisieren: In CI prüfen, PRs mit Graph/Status kommentieren, bei Verstoß eskalieren.

Leichtes Tooling

Lighthouse CI (in PRs und CI)

Konfiguration in lighthouserc.json mit assert‑Schwellen für Metriken und Ressourcen:

{
  "ci": {
    "collect": {
      "numberOfRuns": 3,
      "settings": {
        "preset": "mobile",
        "throttling": { "rttMs": 150, "throughputKbps": 1600 },
        "screenEmulation": { "width": 360, "height": 640, "mobile": true }
      },
      "url": [
        "https://example.com/",
        "https://example.com/blog"
      ]
    },
    "assert": {
      "assertions": {
        "largest-contentful-paint": ["error", {"maxNumericValue": 2500}],
        "cumulative-layout-shift": ["error", {"maxNumericValue": 0.1}],
        "interactive": ["error", {"maxNumericValue": 4000}],
        "total-byte-weight": ["error", {"maxNumericValue": 350000}],
        "resource-summary:script": ["error", {"maxNumericValue": 200000}],
        "resource-summary:stylesheet": ["error", {"maxNumericValue": 60000}],
        "uses-text-compression": ["warn", {"minScore": 0.9}]
      }
    }
  }
}

Optional: WebPageTest oder PageSpeed API für tiefere Netzprofile und Filmstrips (nach Merge).

RUM (Real User Monitoring)

Tracke p75 LCP/INP/CLS kontinuierlich; vergleiche gegen Budget und saisonale Effekte. Wichtig: Labor‑Profile an reale Geräte anpassen, wenn RUM härtere Werte zeigt.

Beispiel‑Budgets (mobil, Startseite)

• LCP p75: ≤ 2.5 s
• INP p75: ≤ 200 ms
• CLS p75: ≤ 0.10
• JS gesamt (gzip): ≤ 180 KB
• CSS gesamt (gzip): ≤ 60 KB
• Initial Requests: ≤ 45
• Critical Images (ATF): ≤ 250 KB
• 3rd‑Party: ≤ 2 kritisch, Rest lazy

Für Content/Blogseiten kannst du JS enger fassen (z. B. ≤ 120 KB) und Bilder großzügiger – solange LCP hält.

So verankerst du Budgets im Prozess

• Planung: Feature‑Ticket enthält Performance‑Annahme (»+20 KB JS«, »< +50 ms TBT«).
• Design: Komponentenbibliothek mit »Cost Labels« (z. B. »Hero‑Video ≈ +400 KB«).
• Entwicklung:
  • Code‑Splitting, Routen‑Level Lazy‑Loading.
  • Bilder: AVIF/WebP, responsive srcset, dimensionierte Platzhalter (CLS!).
  • Fonts: Subsets, font-display: swap, nur benötigte Schnitte.
  • JS‑Diät: Unused Code entfernen, leichte Alternativen, Server/Edge Work teilen.
• Review: PR‑Kommentar zeigt Delta vs. Budget; Reviewer checkt »Budget‑Diff«.
• CI/CD: Bei Budget‑Verletzung rot; Override nur mit Begründung/Issue.
• Monitoring: Wochenreport p75‑Metriken, Trends und »Budget Burn« je Route.

Typische Stolpersteine und Lösungen

• Flaky Messungen: Stabilisiere Labor‑Profile, nutze Median oder p75 statt Einzelruns.
• »Grünes CI, rotes RUM«: Reale Geräte/Netze sind härter; passe Labor‑Profile und Budgets an Mobile‑Realität an.
• 3rd‑Party Drift: Separates Budget und regelmäßige Audits; async/defer, Consent‑gesteuertes Laden.
• Bilder wachsen still: Automatisierte Compress‑/Resize‑Pipeline, max‑Dimensionen serverseitig erzwingen.
• JS schleicht hoch: Bundle‑Analyser im PR, Watchlist für große Pakete, sideEffects: false nutzen.

Mini‑Checkliste

• Ziele: 2–3 Metriken + 2 Ressourcen‑Budgets definiert.
• Profile: Mobiles Labor‑Profil + RUM p75 festgelegt.
• Routen: Budgets je Kernroute dokumentiert.
• CI: Lighthouse CI mit assert in PRs aktiv.
• Transparenz: Wöchentlicher Report, sichtbare Trends.
• Governance: Override‑Pfad mit Begründung etabliert.