Web-Performance.

Web-Performance ist ein dreidimensionales Qualitätsmaß: wie schnell eine Seite lädt, wie schnell sie reagiert und wie stabil sie beim Laden bleibt.

Die meisten Performance-Debatten werden auf eine einzige Zahl reduziert, und meist auf die falsche: den Score eines Prüfwerkzeugs. Doch Performance ist nicht eindimensional. Eine Seite kann sehr schnell öffnen und spät auf Klicks antworten; sie kann schnell und reaktiv sein und trotzdem beim Laden unter Ihnen wegrutschen. Googles Core-Web-Vitals-Metriken wurden genau definiert, um diese drei Dimensionen zu trennen.

Dieser Leitfaden leistet drei Dinge. Er trennt sauber, was die drei Metriken messen, und ihre Schwellen. Er erklärt den Unterschied zwischen Labormessung und Felddaten — die Quelle der teuersten Missverständnisse. Und er vertritt mit gemessenen Beispielen, dass Performance eine Entwurfsbeschränkung ist, keine nachträglich ergänzte Optimierung.

Drei Metriken, drei getrennte Fragen

Core Web Vitals besteht aus drei Metriken, und keine ersetzt eine andere. Damit eine Seite als „gut“ zählt, müssen alle drei ihre Schwellen schaffen — bricht eine, rettet die Perfektion der anderen beiden nichts.

1. LCP — wann wurde der größte sichtbare Inhalt der Seite gemalt? Die gute Schwelle: 2,5 Sekunden. Die Frage lautet: Wann sagt der Nutzer „die Seite ist da“?
2. INP — wie schnell antwortet die Seite visuell auf Klicks, Berührungen und Tasteneingaben? Die gute Schwelle: 200 Millisekunden. Es ersetzte FID im März 2024.
3. CLS — wie stark verschob sich der Inhalt unerwartet, während die Seite lud oder benutzt wurde? Die gute Schwelle: 0,1. Einheitslos; berechnet aus der Größe der verschobenen Fläche mal der Verschiebungsdistanz.

Dass die drei getrennt sind, ist eine Entwurfsentscheidung. LCP misst die Ladegeschwindigkeit, INP die Interaktionsreaktivität, CLS die visuelle Stabilität. Eine Seite kann in allen drei Dimensionen unabhängig gut oder schlecht sein, und jede hat ihre eigene Behandlung — die Arbeit, die LCP richtet, berührt INP meist nicht.

Dass INP FID ablöste, war besonders wichtig, denn FID maß nur die VERZÖGERUNG der ERSTEN Interaktion. Eine Seite konnte auf den ersten Klick schnell antworten und bei jedem weiteren einfrieren — und FID sah trotzdem gut aus. INP betrachtet die Interaktionen der ganzen Sitzung und misst nicht die Verzögerung, sondern den VOLLEN ZYKLUS — von der Eingabe bis zum nächsten Malen. Eine viel härtere Prüfung.

Felddaten und Labormessung

Das teuerste Missverständnis der Performance-Debatten lebt hier. Ein Prüfwerkzeug öffnet die Seite in seiner kontrollierten Umgebung und druckt einen Score; das ist die Labormessung. Die Daten, die Google im Ranking verwendet, werden aus dem gesammelt, was echte Nutzer auf echten Geräten und echten Netzen erleben; das sind die Felddaten.

Die beiden gehen routinemäßig auseinander, und die Richtung ist meist dieselbe: Labor gut, Feld schlecht. Der Grund ist einfach — die Labormessung nimmt ein festes Gerät und ein festes Netz an, während ein erheblicher Teil der echten Nutzer auf schwachen Telefonen über schwankende Verbindungen surft.

Die praktische Folge: Der Labor-Score ist ein Diagnosewerkzeug, kein Ziel. Er zeigt, was langsam ist, und weil er wiederholbar ist, taugt er, die Wirkung einer Änderung zu messen. Aber das Urteil „wir sind gut“ können nur die Felddaten fällen.

Der Labor-Score sagt, was langsam ist; ob Sie gut sind, sagen nur die Felddaten.

Auf dieser Website werden die Felddaten in eine Cache-Datei gezogen und im Streifen gezeigt — aber gibt es keine Daten, wird das Feld GAR NICHT GERENDERT. Die Prüfsuite misst das eigens: Kommen keine Daten, darf die Zeile „gemessenes LCP“ nicht erscheinen. Ein leeres Feld wird dem erfundenen Beleg vorgezogen.

Performance ist eine Entwurfsbeschränkung

Die übliche Arbeitsweise: Die Website wird entworfen, gebaut, dann läuft eine Prüfung, und die entstandene Liste wird abgearbeitet. In dieser Reihenfolge bleiben die meisten Korrekturen kosmetisch, denn die eigentlichen Kosten wurden in der Entwurfsphase festgeschrieben.

Konkrete Beispiele: Wie viele Schriftfamilien verwendet werden, ist eine Entwurfsentscheidung und beeinflusst direkt LCP. Ob im Hero ein Video oder ein Bild steht, ist eine Entwurfsentscheidung. Wie viele Animationsschichten gebaut werden, ist eine Entwurfsentscheidung und bestimmt INP. Das lässt sich später nicht „optimieren“ — nur zurücknehmen.

Die gesunde Methode ist, Performance als Budgetposten zu führen. Das Budget wird vorab gesetzt, der Entwurf geschieht darin, und jedes Deployment wird gemessen. Auf dieser Website ist das Budget als nicht verhandelbar definiert: LCP unter 1,8 Sekunden, CLS unter 0,05, INP unter 200 Millisekunden und das gesamte JavaScript unter 150 Kilobyte gzip.

Ob das Budget wirklich hält, wurde gemessen: Die Vendor-Bibliotheken sind nach gzip 55,7 Kilobyte, der eigene Code der Website 28 Kilobyte — zusammen 83,7 Kilobyte, deutlich unter der Decke. Die Hauptstildatei: 67,4 Kilobyte Quelle, nach gzip 12,4 Kilobyte. Die vom Live-Server gemessene Zeit bis zum ersten Byte: 0,302 Sekunden.

Ohne Messung kein „fertig“

Die heimtückischste Falle der Performance-Arbeit ist anzunehmen, eine Verbesserung sei wirklich eine. Eine Änderung kann vernünftig aussehen, eine bekannte gute Praxis sein — und auf dieser Website trotzdem nichts ändern oder sie verschlechtern.

Genau so ein Fall geschah auf dieser Website und ist dokumentiert. Das Ladeverhalten der Schrift wurde als Quelle einer Layoutverschiebung verdächtigt, und eine Korrektur war geplant. Die Messung behob keinen Fehler — sie verhinderte eine FALSCHE KORREKTUR: Die Verschiebung kam von woanders, und die geplante Änderung hätte die Lage verschlechtert.

Der zweite Fall lehrt mehr. Die beim Laden gemessene Verschiebung lag nahe null; aber beim Scrollen, beim Loslassen eines fixierten Abschnitts, entstand eine Verschiebung. Die klassische CLS-Messung schaut auf das Ladefenster und sieht diese Verschiebung nie — der Nutzer erlebt genau sie.

Die gemeinsame Lehre: Dass eine Metrik gut ausfällt, heißt, dass das Gemessene gut ist; über das Nicht-Gemessene sagt sie nichts. Deshalb wird auf dieser Website die Verschiebung beim Scrollen mit einem eigenen Test in Sitzungsfenster-Logik gemessen, gebunden an die Schwelle 0,08.

Wo anfangen

Für alle, die eine bestehende Website beschleunigen wollen: ein nach Wirkung geordneter Anfang. Die Reihenfolge zählt — die oberen Punkte betreffen mehr Nutzer und kosten weniger.

1. Schauen Sie auf die Felddaten — nicht auf den Labor-Score. Welche Metrik ist bei echten Nutzern gebrochen?
2. Zählen Sie die renderblockierenden Ressourcen — wie viele Stildateien, wie viele synchrone Skripte? Jede verzögert das Malen.
3. Finden Sie das größte sichtbare Element — welches ist das LCP-Element? Meist das Hero-Bild oder die Überschrift. Für dieses Element lässt sich alles tun.
4. Geben Sie Bildern Maße — die Angabe von Breite und Höhe schließt die häufigste CLS-Quelle in einer Zeile.
5. Senken Sie die Schriftzahl — jede Familie ist eine zusätzliche Anfrage und ein zusätzliches Tauschrisiko.
6. Wiegen Sie das JavaScript — wie viel wird wirklich gebraucht? Kein Schneiden vor dem Messen; nach dem Messen seien Sie gnadenlos.
7. Setzen Sie ein Budget und binden Sie es an einen Test — eine einmalige Verbesserung wird drei Deployments später zurückgenommen.

Der letzte Punkt wird am meisten übersprungen und kostet am meisten. Performance-Korrekturen zerfallen lautlos: Eine neue Bibliothek kommt, ein neues Bild ohne Maße, eine neue Schriftfamilie schlüpft hinein. Ist das Budget an einen Test gebunden, zeigt sich der Zerfall im Deployment; wenn nicht, wird er bei der nächsten Prüfung neu entdeckt.

Der Rest des Clusters behandelt jeden dieser Schritte einzeln — die eigenen Seiten der drei Metriken, der Unterschied der Messschichten und zwei auf dieser Website durch Messung gelernte blinde Flecken.