Performance-Budgets: So bleibt Ihre Webanwendung schnell

Kurz gefasst: Ein Performance-Budget ist eine feste Obergrenze für Kennzahlen wie Ladezeit, JavaScript-Menge oder Core Web Vitals, die eine Webanwendung nicht überschreiten darf. Es verhindert, dass eine Anwendung mit jedem neuen Feature, jedem Tracking-Skript und jeder Bibliothek ein wenig langsamer wird, bis es niemand mehr übersehen kann. Wirksam wird es erst, wenn eine automatische Prüfung in der CI-Pipeline Verstöße sichtbar macht oder blockiert.

Warum Webanwendungen langsam werden

Kaum eine Anwendung wird absichtlich langsam. Es passiert schleichend: Eine Datumsbibliothek hier, ein Chat-Widget dort, ein größeres Hero-Bild, ein zusätzliches Analyse-Skript. Jede Änderung wirkt für sich harmlos. In der Summe lädt die Seite nach einem Jahr spürbar länger, und niemand kann sagen, wann es passiert ist.

Ladezeit hat direkte Folgen. Google nutzt die Core Web Vitals als Signal für die Seitenerfahrung im Ranking, und langsame Seiten verlieren Besucher, bevor diese den ersten Inhalt sehen. Ein Performance-Budget macht Geschwindigkeit zu einer Anforderung mit klarer Grenze, wie Barrierefreiheit oder Sicherheit.

Welche Kennzahlen ins Budget gehören

Nutzerbezogene Kennzahlen

Die Core Web Vitals sind der beste Ausgangspunkt, weil sie messen, was Nutzer erleben. Google empfiehlt als Grenze für eine gute Bewertung: Largest Contentful Paint (LCP) bis 2,5 Sekunden, Interaction to Next Paint (INP) bis 200 Millisekunden und Cumulative Layout Shift (CLS) bis 0,1. INP hat im März 2024 die frühere Kennzahl First Input Delay abgelöst und bewertet die Reaktionsfähigkeit über den gesamten Besuch.

Mengenbezogene Kennzahlen

Ladezeiten schwanken je nach Gerät und Netz. Deshalb ergänzen Sie das Budget um Mengen, die sich stabil messen lassen: komprimierte JavaScript-Größe pro Seite, Gesamtgewicht der Seite, Anzahl der Anfragen, Größe von Bildern und Schriften. Wenn das JavaScript-Budget eingehalten wird, bleiben meist auch INP und Ladezeit im Rahmen.

Werte festlegen

Messen Sie den aktuellen Stand und setzen Sie das Budget knapp darüber oder an einem realistischen Ziel. Ein Budget, das von Anfang an gerissen wird, ignoriert das Team. Messen Sie außerdem mit gedrosselter Verbindung auf einem durchschnittlichen Mittelklasse-Smartphone, nicht auf dem Entwickler-Laptop im Büro-WLAN.

Das Budget in der Pipeline durchsetzen

Bundle-Größe prüfen

Werkzeuge wie size-limit prüfen bei jedem Pull Request, ob das JavaScript-Bundle eine festgelegte Größe überschreitet. Der Kommentar im Pull Request zeigt genau, welche Änderung wie viel hinzugefügt hat. So fällt die neue 70-Kilobyte-Bibliothek auf, bevor sie gemergt wird.

Lighthouse CI

Lighthouse CI führt bei jedem Build Messungen auf wichtigen Seiten durch und vergleicht sie mit Ihren Grenzwerten. Bei Überschreitung schlägt der Build fehl oder erzeugt eine Warnung. Wie solche Prüfungen in eine Pipeline passen, beschreiben wir im Beitrag zu CI/CD-Pipelines für Webanwendungen.

Echte Nutzerdaten beobachten

Labormessungen zeigen Trends, echte Nutzer zeigen die Wahrheit. Mit der Bibliothek web-vitals erfassen Sie Core Web Vitals aus echten Besuchen und werten sie aus. Google stellt außerdem im Chrome UX Report und in der Search Console Felddaten bereit. Wie diese Daten in Ihr Monitoring einfließen, steht in unserem Artikel zu Monitoring und Observability.

Was tun, wenn das Budget reißt?

Ein gerissenes Budget ist der Anlass für eine Entscheidung. Die üblichen Hebel sind bekannt: Code-Splitting, damit jede Seite nur ihren Code lädt. Schwere Bibliotheken durch leichtere ersetzen oder nur bei Bedarf nachladen. Bilder in modernen Formaten wie AVIF oder WebP mit passenden Größen ausliefern. Schriften auf die nötigen Schnitte beschränken. Drittanbieter-Skripte prüfen und verzögert laden.

Oft hilft auch die Architektur. Server-Rendering und React Server Components verlagern Arbeit vom Browser auf den Server und reduzieren das JavaScript im Client. Wann sich welcher Ansatz eignet, erklärt unser Beitrag zu Server-Side und Client-Side Rendering.

Manchmal ist ein Feature die zusätzlichen Kilobytes wert. Dann wird das Budget bewusst angepasst, mit Begründung, statt stillschweigend überschritten.

Häufige Fragen (FAQ)

Ab wann lohnt sich ein Performance-Budget?

Am besten vom Projektstart an, weil es dann am einfachsten einzuhalten ist. Bei bestehenden Anwendungen setzen Sie das Budget auf den aktuellen Stand und senken es schrittweise. Das verhindert zumindest, dass es schlechter wird.

Welche Kennzahl ist die wichtigste?

Für die meisten Webanwendungen ist die JavaScript-Menge der stärkste Hebel, weil sie Ladezeit und Reaktionsfähigkeit gleichzeitig beeinflusst. Für die Außenwirkung und die Suchmaschine zählen die Core Web Vitals aus echten Nutzerdaten.

Bremst ein Performance-Budget die Entwicklung?

Kaum, wenn es automatisiert ist. Die Prüfung läuft in der Pipeline mit und meldet sich nur bei Überschreitung. Langfristig spart sie Zeit, weil nachträgliche Performance-Projekte deutlich aufwendiger sind als laufende Disziplin.

Wer entscheidet, wenn ein Feature das Budget sprengt?

Das sollte vorher geregelt sein, meist gemeinsam von Produktverantwortung und technischer Leitung. Wichtig ist, dass die Ausnahme bewusst und dokumentiert entschieden wird.

Fazit

Ein Performance-Budget macht aus Geschwindigkeit eine überprüfbare Regel, die nicht vom Bauchgefühl einzelner Entwickler abhängt. Mit wenigen Kennzahlen, automatischer Prüfung und echten Nutzerdaten bleibt Ihre Anwendung auch nach Jahren schnell. Wenn Sie eine schnelle Webanwendung aufbauen oder eine langsame wieder flott machen möchten, sprechen Sie mit uns über Webentwicklung.