Eine Website, die schnell bleiben muss.
Fast jede Website ist am Tag des Launchs schnell. Langsam wird sie danach: mit jedem neuen Skript, jedem Bild und jedem Feature ein wenig mehr, bis es jemandem auffällt. Diese Website hat deshalb feste Grenzwerte, die vor jedem Release gemessen werden. Liegt eine Seite darüber, geht die Version nicht live. Diese Case-Study zeigt, wie das aufgebaut ist und was Sie für Ihr eigenes Produkt daraus mitnehmen können.
Ausgangslage
Performance geht selten durch eine einzelne Entscheidung verloren. Jede Änderung kostet ein paar Millisekunden und ein paar Kilobyte, und keine davon fällt für sich genommen auf. Ohne feste Grenze gibt es keinen Moment, in dem jemand Stopp sagt.
Lösung
Drei Grenzwerte für Ladezeit, Layout und Seitengewicht stehen in einer Datei. Die Pipeline lädt vor jedem Release jede Seitenart im echten Browser und misst sie daran.
Ergebnis
Die Grenzwerte sind deutlich strenger als das, was Google als gut wertet, und jede Seitenart hält sie ein. Wird eine Seite zu langsam, fällt das vor dem Release auf und nicht erst den Besuchern.
Performance-Budgets kurz erklärt
Ein Performance-Budget ist eine Obergrenze, die eine Seite beim Laden nicht überschreiten darf, so wie ein Kostenbudget in einem Projekt. Der Unterschied zu einem guten Vorsatz: Die Grenze ist eine Zahl, und sie wird automatisch geprüft. Niemand muss daran denken, und niemand muss darüber diskutieren.
Gemessen wird, was Besucher spüren. Google fasst das in den Core Web Vitals zusammen. Zwei davon lassen sich beim Laden einer Seite direkt messen: Der Largest Contentful Paint (LCP) sagt, wann der größte sichtbare Inhalt steht, der Cumulative Layout Shift (CLS), wie stark das Layout dabei noch springt.
Dazu kommt die Transfergröße, also die Datenmenge, die eine Seite beim Laden überträgt. Sie ist keine Kennzahl von Google, aber die früheste Warnung: Eine Seite wird fast immer erst schwerer und dann langsamer. Im Mobilfunknetz zählt außerdem jedes Kilobyte.
Drei Grenzwerte, eine Datei
LCP ≤ 1,2 s
Ladezeit
So lange darf es höchstens dauern, bis der größte sichtbare Inhalt einer Seite steht. Google wertet bis zu 2,5 Sekunden als gut, hier gilt eine deutlich engere Grenze.
CLS ≤ 0,02
Ruhiges Layout
So wenig darf sich das Layout beim Laden verschieben. Nichts soll wegspringen, während jemand liest oder gerade klicken will. Google wertet bis zu 0,1 als gut.
Transfer ≤ 200 kB
Seitengewicht
So viel darf eine Seite beim Laden höchstens übertragen, mit HTML, CSS, JavaScript, Schriften und Bildern. Diese Grenze schlägt als erste an, wenn eine neue Abhängigkeit dazukommt.
So bleibt die Seite leicht
Fertiges HTML vom Server
Der Server liefert jede Seite als fertiges HTML aus, geschrieben in Go mit templ. Der Browser muss keine Anwendung starten, bevor Inhalt erscheint. Das ist der wichtigste Grund für die kurze Ladezeit.
Eine Datei CSS, eine Datei JavaScript
Alle Styles stecken in einer minifizierten Datei, alles JavaScript in einer zweiten. Für Interaktionen genügt htmx statt eines Frontend-Frameworks. Skripte von Drittanbietern gibt es bis auf die Statistik nicht, und die lädt, ohne die Seite aufzuhalten.
Grafiken, die gezeichnet werden
Die animierten Grafiken der Lösungsseiten und Case-Studies sind keine Bilder oder Videos. Dasselbe Skript zeichnet sie im Browser auf eine Zeichenfläche. Eine neue Grafik kostet deshalb ein paar Zeilen Code statt einer weiteren Bilddatei. Ihr Platz ist von Anfang an reserviert, es verschiebt sich also nichts.
Schrift und Cache
Die Schrift liegt auf dem eigenen Server, als eine variable Datei für alle Schriftschnitte, und wird vorgeladen. Alle Dateien werden komprimiert ausgeliefert und tragen die Version des Builds in ihrer Adresse. Der Browser darf sie deshalb lange behalten und holt sie nach einem Release trotzdem neu.
So wird das Budget durchgesetzt
Ein Budget, das niemand prüft, ist eine Absichtserklärung. Deshalb misst hier nicht ein Mensch bei Gelegenheit, sondern die Pipeline bei jedem Release, mit Playwright und den Messpunkten des Browsers.
Eine Quelle für die Grenzwerte
Die drei Zahlen stehen an genau einer Stelle. Die Tests lesen sie von dort, die Karten auf dieser Seite und auf der Lösungsseite auch. Was hier steht, ist also das, woran wirklich gemessen wird.
Gemessen im echten Browser
Die Pipeline lädt jede Seitenart in Chromium: Startseite, Übersicht, Lösungsseite, Case-Study und die übrigen. Gemessen wird, sobald die Schriften geladen sind und keine Anfrage mehr offen ist.
Sperre vor dem Release
Jede Version läuft zuerst auf einer Staging-Umgebung. Erst wenn dort alle Tests bestehen, geht genau diese Version live. Reißt eine Seite ein Budget, bleibt die alte Version online.
Faire und sichtbare Messung
Weil viele Tests gleichzeitig laufen, zählt bei der Ladezeit der beste von drei Versuchen: Auslastung kann eine Messung verzögern, aber nie beschleunigen. Die Messwerte jeder Seite stehen in der Zusammenfassung des Laufs. So zeigt sich ein Trend, bevor er zum Problem wird.
Warum ein Budget mit KI noch wichtiger wird
Mit KI-Agenten entsteht Code schneller als je zuvor, und damit auch alles, was eine Seite schwer macht. Ein Agent liefert, was funktioniert, und bringt dabei gern eine Bibliothek, ein Bild oder ein Skript mehr mit. Was das an Ladezeit kostet, prüft er von sich aus nicht. Und bei vielen Änderungen am Tag liest niemand mehr jede Zeile so genau, dass es auffiele.
Ein Budget in der Pipeline fängt genau das ab: Es misst jede Änderung, egal wer sie geschrieben hat. So kann ein Team mit KI schnell weiterentwickeln, ohne dass die Anwendung dabei unbemerkt langsamer wird. So arbeite ich auch selbst: KI setzt um, das Budget prüft, ich entscheide. Denn die Grenzen legt kein Agent fest: Welche Kennzahlen zählen für dieses Produkt, wie streng darf die Grenze sein, und was fliegt raus, wenn sie reißt? Das ist eine Abwägung zwischen Nutzern, Produkt und Aufwand, und dafür bringe ich die Erfahrung mit. Mehr dazu auf der Seite Webanwendung beschleunigen.
Was Sie für Ihr Produkt mitnehmen können
Erst messen, dann die Grenze setzen
Messen Sie den heutigen Stand und legen Sie das Budget knapp darüber. So wird es vom ersten Tag an eingehalten und verhindert, dass es schlechter wird. Strenger machen können Sie es mit jeder Optimierung.
Wenige Zahlen, die jeder versteht
Drei Grenzwerte reichen. Eine lange Liste von Kennzahlen pflegt niemand, und im Zweifel weiß keiner, welche davon wichtig ist.
Das Budget muss einen Release aufhalten dürfen
Eine Warnung im Bericht wird übersehen. Erst wenn eine Überschreitung den Release stoppt, wird über Performance gesprochen, bevor die Nutzer sie spüren.
Dokumentation zum Weiterlesen
Core Web Vitals
Der Überblick, Largest Contentful Paint, Cumulative Layout Shift und die Schwellenwerte von Google.
Performance-Budgets
Die Einführung auf web.dev und wie man Budgets in den Build einbaut.
Messen im Browser
Playwright für Tests im echten Browser und der PerformanceObserver, der die Messwerte liefert.
Häufige Fragen
Brauchen wir ein Budget, wenn die Anwendung heute schnell ist?
Gerade dann. Ein Budget macht nichts schneller, es hält den Stand. Es einzuführen kostet am wenigsten, solange die Werte gut sind.
Was passiert, wenn ein wichtiges Feature das Budget reißt?
Dann gibt es eine bewusste Entscheidung statt eines Zufalls: das Feature schlanker bauen, an anderer Stelle einsparen oder das Budget anheben. Alle drei Wege sind in Ordnung, solange jemand die Entscheidung trifft.
Funktioniert das auch mit React, Angular oder Vue?
Ja. Das Budget misst im Browser, was beim Nutzer ankommt, unabhängig von der Technik dahinter. Die Grenzwerte liegen bei einer großen Anwendung anders als bei dieser Website, das Prinzip ist dasselbe.
Wie finde ich heraus, wo unsere Anwendung steht?
Im Festpreis-Audit zur Performance messe ich Ihre Anwendung unter realistischen Bedingungen. Sie erfahren, welche Ursachen den größten Anteil haben und welche Grenzwerte für Sie sinnvoll sind.
Lassen Sie uns über Ihre Situation sprechen
In einem kostenlosen Erstgespräch schauen wir gemeinsam auf Ihr Problem. Sie erhalten eine ehrliche Einschätzung, ob und wie ich Ihnen helfen kann.
Die Lösung dazu
Problem
Ihre Anwendung lässt Nutzer warten
Lange Ladezeiten, ruckelnde Oberflächen und schwache Core Web Vitals. Ich finde die Ursachen und mache Ihre Anwendung messbar schneller.