Performance Budgets für Core Web Vitals

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

Baseline messen: 3–7 Tage RUM (z. B. p75 der Web Vitals) und Labor (Lighthouse, WebPageTest) mit mobilem Profil (4× CPU‑Throttling, 4G).
Kandidaten wählen: 2–3 Web Vitals + 2 Ressourcen‑Budgets (JS‑KB, Requests) reichen zum Start.
Ziele festlegen: Entweder »Industry Good« (z. B. LCP ≤ 2.5 s) oder »Baseline – 15 %«.
Routen schneiden: Budgets für Hauptpfade (Start, Artikel, Produktseite) separat festlegen.
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.

Agent Skill: Budgets prüfen und beheben, ohne Browser

Lighthouse CI in der Pipeline deckt die halbe Miete ab: Es misst LCP, CLS und Co. mit einem echten Browser, aber eben nur dort, wo es läuft – im PR, nicht beim schnellen Zwischencheck über die Kommandozeile. Für genau diese Lücke habe ich zwei Agent Skills gebaut, die mit jedem Coding-Agenten (Claude Code, Cursor, Copilot, Codex …) funktionieren:

Perf Budget Check prüft Ressourcengewicht und Lade-Strategie ohne echten Browser: JS/CSS/Bild-Bytes, Requestanzahl, Drittanbieter-Origins, Render-Blocking-Ressourcen, Kompression, Cache-Header, font-display, und ob überhaupt ein lighthouserc.json als CI-Gate existiert. Der erste Testlauf gegen die eigene, hinter Cloudflare liegende Seite zeigte sofort, warum das nicht trivial ist: Der Content-Length-Header fehlte komplett, weil Cloudflare Brotli-komprimierte Antworten streamt. Der Scan zählt die Bytes seitdem selbst, statt sich auf einen Header zu verlassen, der bei modernen CDNs oft schlicht nicht da ist – und fand danach einen echten Budget-Verstoß (JS 48 KB über dem Ziel), der vorher als „0 KB, alles im grünen Bereich" durchgerutscht wäre.
Perf Budget Fix setzt die Befunde um: Kompression aktivieren, Render-Blocking-Scripts entschärfen, Code-Splitting nach Framework-Muster (Next.js, Nuxt, Astro, SvelteKit, Vue, statisches HTML, WordPress), Font-Ladestrategie, Drittanbieter-Skripte verzögern statt löschen, Caching-Header, lighthouserc.json anlegen – mit Gegenprobe über denselben Scan.

Bewusste Abgrenzung: Bildattribute wie width/height oder loading="lazy" auf dem ersten Bild prüft nicht dieser Skill, sondern SEO Check – sonst hätte ein einzelnes <img>-Tag zwei Quellen für Befunde, die sich widersprechen könnten. Und beide Skills sagen ausdrücklich, was sie nicht können: kein LCP/INP/CLS/TBT ohne echten Browser oder Felddaten, keine vollständige Request-Waterfall, keine Erfolgsgarantie für die gefühlte Ladezeit. Genau diese Ehrlichkeit über die eigenen Grenzen ist mir bei allen Skills wichtiger als ein beeindruckender, aber unbelegter Score.

Installation und Details, auch für andere Agenten als Claude Code: github.com/larsdecker/agents-skills.

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.

Performance Budgets, die wirklich wirken