Perf Budget Fix
Setzt Performance-Budget-Befunde im Code um – und trennt mechanische Fixes von Geschäftsentscheidungen.
Das Problem
Ein Teil der Performance-Arbeit ist mechanisch – Kompression aktivieren, defer setzen, font-display ergänzen. Ein anderer Teil ist eine Geschäftsentscheidung – welches Drittanbieter-Skript verzichtbar ist, welcher Budget-Wert richtig ist. Wer diese Grenze verwischt, löscht entweder zu vorsichtig gar nichts oder entfernt etwas, das jemand braucht.
Installation
Der Skill ist eine SKILL.md mit Referenztexten und abhängigkeitsfreien Node-Scripts – nichts davon ist an einen Anbieter gebunden. Wähle deinen Agenten:
Schritt 1
git clone https://github.com/larsdecker/agents-skillsSchritt 2
node agents-skills/install.mjs --agent cursor --skill perf-budget-fix --target .Statt cursor auch copilot, windsurf, cline, gemini oder agents (für Codex, Zed, Amp, opencode). Sinnvoll zusammen mit --skill perf-budget-check.
Getestet mit: Claude Code, Cursor, GitHub Copilot, Codex, Windsurf, Cline, Gemini CLI, Zed. Ein hier nicht genannter Agent funktioniert ebenfalls – Skill-Verzeichnis ablegen und in der Anweisungsdatei des Agenten darauf verweisen.
Was dabei herauskommt
- Änderungen im Code, framework-gerecht: Kompression, Render-Blocking, Code-Splitting, Fonts, Caching
- Gegenprobe mit Vorher-Nachher-Zahlen statt Erfolgsbehauptung
- Ein lighthouserc.json als CI-Budget-Gate, mit Schwellwerten zur Bestätigung statt geraten
Was er nicht tut
- Kein Entfernen von Drittanbieter-Skripten ohne Rückfrage
- Keine Bildattribut-Fixes (width/height, loading, alt) – das übernimmt seo-fix
- Keine eigenmächtige Änderung von Budget-Schwellwerten, um einen Befund verschwinden zu lassen
- Keine Erfolgsgarantie für echte LCP-/INP-/CLS-Werte
Die Grenze, die den Skill brauchbar macht
Kompression aktivieren, defer setzen, font-display: swap ergänzen, ein lighthouserc.json anlegen: mechanisch, risikoarm, sofort machbar.
Welches Drittanbieter-Skript verzichtbar ist. Welcher Budget-Wert für dieses Projekt richtig ist. Ob ein Consent-Skript wirklich erst nach der Interaktion laden darf. Das sind Geschäftsentscheidungen.
Den mechanischen Teil erledigt der Skill. Den geschäftlichen Teil bereitet er vor und legt ihn zur Entscheidung vor.
Wer diese Grenze verwischt, produziert einen von zwei Schäden: entweder wird aus Vorsicht gar nichts angefasst, obwohl der Großteil der Fixes risikofrei ist — oder ein Tracking-Skript verschwindet, das jemand im Marketing-Team vertraglich zugesichert hat.
Die harten Grenzen
Kein Entfernen von Drittanbieter-Skripten ohne Rückfrage. Was wie totes Tracking aussieht, kann ein zugesichertes Analytics- oder Marketing-Tool sein. Die Ladestrategie ändern (verzögern, nach Consent laden) ist fast immer sicher — das Skript löschen nicht.
Keine Änderung von Budget-Schwellwerten, um einen Fehler verschwinden zu lassen. Ein Budget in lighthouserc.json ist eine Team-Entscheidung. Passt ein Wert nicht mehr, ist das ein Gespräch, kein Ein-Zeilen-Fix am Assert.
Kein Anfassen von Bild-Attributen. width, height, loading, alt gehören SEO Fix. Zwei Skills, die dasselbe Attribut ändern wollen, sind der sicherste Weg zu einem Merge-Konflikt mit sich selbst.
Keine Änderung an produktiver Server-/CDN-Konfiguration ohne die Auswirkung zu benennen. Ein Syntaxfehler in nginx.conf legt die gesamte Site lahm — das größte Schadenspotenzial in diesem ganzen Skill.
Reihenfolge nach Wirkung, nicht nach Aufwand
- Kompression aktivieren — wirkt auf jedes Byte-Budget gleichzeitig und ist auf den meisten modernen Plattformen (Vercel, Netlify, Cloudflare) ohnehin schon aktiv. Der erste Schritt ist deshalb oft: prüfen, dass nichts zu tun ist, statt blind eine Konfigurationszeile hinzuzufügen.
- Render-Blocking entschärfen —
defer/async, kritisches CSS trennen. - JS-Bytebudget senken — Code-Splitting, Routen-Level Lazy-Loading, toten Code entfernen.
- Font-Ladestrategie —
font-display: swap, Subsetting, Preconnect. - Drittanbieter-Ladestrategie — verzögern, nicht löschen.
- Caching-Header — langlebiges Caching für gehashte Dateinamen.
- CI-Budget-Gate einrichten, wenn noch keins existiert.
Ein Fix aus Stufe 6 vor einem offenen Punkt aus Stufe 1 ist verlorene Zeit: Kompression zahlt auf jedes andere Budget gleichzeitig ein.
Framework-Muster statt zusätzlicher Abhängigkeit
references/framework-patterns.md deckt Next.js (next/script-Strategien, next/font, next/dynamic), Nuxt 3, Astro (client:visible statt client:load), SvelteKit, Vue, statische HTML-Seiten, WordPress und Edge-Umgebungen ab — jeweils mit der Warnung, wo die Plattform (Vercel, Cloudflare) das Problem bereits automatisch löst und ein Fix im Anwendungscode wirkungslos wäre.
Der häufigste vermeidbare Fehler: eine zusätzliche Bibliothek installieren, wo das Framework bereits eine eigene Lösung mitbringt. Ein Performance-Paket zusätzlich zu next/font zu installieren erzeugt einen neuen Drittanbieter-Origin, um ein Problem zu lösen, das die vorhandene Framework-API bereits löst.
Was nach dem Fix noch fehlt
- Eine Änderung im Code ist noch nicht live. CDN-Caches können eine alte Antwort noch eine Weile ausliefern, auch nach dem Deployment.
- Ein neu eingerichtetes CI-Budget-Gate greift erst ab dem nächsten Pull Request, nicht rückwirkend.
- Die Gegenprobe braucht denselben Scan wie vorher. Perf Budget Check noch einmal laufen lassen und die Zahl explizit vergleichen — „JS von 248 KB auf 190 KB" ist eine Aussage, „sollte jetzt schneller sein" ist keine.
Und keine Erfolgsprognose zur echten Nutzererfahrung. Ein gesenktes Bytegewicht ist belegbar, eine verbesserte gefühlte Ladezeit nicht ohne eine echte Lighthouse- oder RUM-Messung.
