Web-Performance-Kennzahlen (Web Vitals)

Faktoren, die die Web-Performance bestimmen

Bei der Optimierung der Web-Performance lassen sich die entscheidenden Faktoren grob in zwei Kategorien einteilen: Ladeleistung und Renderingleistung.

HTML-Ladeleistung

• Zeitspanne vom ersten Seitenaufruf über das Netzwerk bis zu dem Moment, in dem der Browser mit dem Rendern beginnt
• Bestimmt, wie schnell die Seite sichtbar zu werden beginnt
• Optimierung durch Minimierung von Redirects, Caching der HTML-Antwort, Komprimierung von Ressourcen, passenden CDN-Einsatz u. a.

Renderingleistung

• Zeit, die der Browser benötigt, um das sichtbare UI zu zeichnen und interaktiv zu machen
• Bestimmt, wie flüssig und schnell der Bildschirm aufgebaut wird
• Optimierung durch Entfernen unnötigen CSS und JS, Vermeiden verzögerten Ladens von Schriftarten und Thumbnails, Auslagern rechenintensiver Aufgaben in einen separaten Web Worker zur Entlastung des Main Threads, Optimierung von Animationen u. a.

Web-Performance-Kennzahlen (Web Vitals)

Die Beschreibung folgt den Leitlinien von web.dev und der Chrome-Entwicklerdokumentation. Ohne besonderen Grund sollte man sich nicht auf eine einzige Metrik fixieren, sondern eine ganzheitliche Verbesserung anstreben und identifizieren, wo die Engpässe der zu optimierenden Seite liegen. Liegen reale Nutzungsdaten vor, empfiehlt es sich zudem, weniger auf Durchschnitts- oder Spitzenwerte zu schauen, sondern eher auf das untere Quartil (Q1), um sicherzustellen, dass auch in diesen Fällen die Zielwerte erreicht werden.

Zentrale Web-Performance-Kennzahlen (Core Web Vitals)

Es gibt mehrere Web-Performance-Kennzahlen (Web Vitals). Unter ihnen betrachtet Google die folgenden drei, die besonders eng mit der User Experience verknüpft sind und in realen Umgebungen (nicht nur im Labor) messbar sind, als besonders wichtig – die Core Web Vitals. Da Google diese Kennzahlen auch in die Reihenfolge der Suchergebnisse seiner Suchmaschine einfließen lässt, sollten Website-Betreiber sie auch im Hinblick auf Suchmaschinenoptimierung (SEO) sorgfältig beobachten.

• Largest Contentful Paint (LCP): spiegelt die Ladeleistung wider, Zielwert ≤ 2,5 s
• Interaction to Next Paint (INP): spiegelt die Reaktionsfähigkeit wider, Zielwert ≤ 200 ms
• Cumulative Layout Shift (CLS): spiegelt die visuelle Stabilität wider, Zielwert ≤ 0,1

Core Web Vitals sind grundsätzlich für Messungen in realen Umgebungen konzipiert. Zwei davon (außer INP) lassen sich aber auch in Laborumgebungen wie den Chrome DevTools oder Lighthouse messen. INP erfordert reale Nutzereingaben und kann deshalb nicht im Labor gemessen werden; in solchen Fällen kann TBT als nahe korrelierende, ähnliche Metrik herangezogen werden – in der Regel verbessert sich INP, wenn man TBT verbessert.

Gewichtung der Leistungsbewertung in Lighthouse 10

Die Lighthouse-Leistungsbewertung ist ein gewogener Durchschnitt der Teilmetriken; die folgenden Gewichte werden verwendet.

Messwert	Gewichtung
First Contentful Paint	10%
Speed Index	10%
Largest Contentful Paint	25%
Total Blocking Time	30%
Cumulative Layout Shift	25%

FCP (First Contentful Paint)

• Misst die Zeit bis zur ersten Darstellung eines DOM-Inhalts nach dem Seitenaufruf
• Als DOM-Inhalt gelten Bilder, nicht-weiße <canvas>-Elemente, SVG usw.; Inhalte in iframes werden nicht berücksichtigt

Einer der Faktoren mit besonders großem Einfluss auf FCP ist die Schriftladezeit. Für entsprechende Optimierungen empfiehlt die Chrome-Entwicklerdokumentation den zugehörigen Beitrag als Einstieg.

Lighthouse-Bewertungskriterien

Laut der Chrome-Entwicklerdokumentation gelten folgende Schwellen:

Farbstufe	FCP mobil (s)	FCP Desktop (s)
Grün (schnell)	0–1,8	0–0,9
Orange (mittel)	1,8–3	0,9–1,6
Rot (langsam)	> 3	> 1,6

LCP (Largest Contentful Paint)

• Misst die Zeit bis zur Darstellung des größten Elements (Bild, Textblock, Video usw.) innerhalb des anfänglich sichtbaren Bereichs (Viewport), wenn eine Seite erstmals geöffnet wird
• Je größer die sichtbare Fläche eines Elements ist, desto eher wird es vom Nutzer als Hauptinhalt wahrgenommen
• Ist der LCP ein Bild, lässt sich die Dauer in vier Teilabschnitte gliedern. Wichtig ist zu ermitteln, wo der Engpass liegt:
  1. Time to First Byte (TTFB): Zeit vom Ladebeginn der Seite bis zum Eintreffen des ersten Bytes der HTML-Antwort
  2. Ladeverzögerung (Load Delay): Differenz zwischen dem Start der LCP-Ressourcenanforderung durch den Browser und dem TTFB
  3. Ladezeit (Load Time): Zeit zum Laden der LCP-Ressource selbst
  4. Renderverzögerung (Render Delay): Zeit vom Abschluss des Ladens der LCP-Ressource bis zur vollständigen Darstellung des LCP-Elements

Lighthouse-Bewertungskriterien

Laut der Chrome-Entwicklerdokumentation gelten folgende Schwellen:

Farbstufe	LCP mobil (s)	LCP Desktop (s)
Grün (schnell)	0–2,5	0–1,2
Orange (mittel)	2,5–4	1,2–2,4
Rot (langsam)	> 4	> 2,4

TBT (Total Blocking Time)

• Misst die gesamte Zeit, in der eine Seite nicht auf Nutzereingaben wie Mausklicks, Touches oder Tastatureingaben reagieren kann
• Zwischen FCP und TTI (Time to Interactive)* werden alle Tasks, die ≥ 50 ms dauern, als Long Tasks betrachtet. Von der Dauer jeder langen Aufgabe wird der Anteil oberhalb von 50 ms als Blockierungsanteil (blocking portion) bezeichnet; die Summe aller Blockierungsanteile ist der TBT.

* TTI reagiert übermäßig empfindlich auf Ausreißer bei Netzwerkantworten und auf lange Aufgaben, ist daher inkonsistent und stark variabel; entsprechend wurde TTI seit Lighthouse 10 aus der Leistungsbewertung entfernt.

Häufigste Ursache langer Aufgaben sind unnötiges oder ineffizientes Laden, Parsen und Ausführen von JavaScript. Die Chrome-Entwicklerdokumentation und web.dev von Google empfehlen, durch Code-Splitting die JS-Payload so zu reduzieren, dass einzelne Blöcke in ≤ 50 ms ausführbar sind, und bei Bedarf Arbeit vom Main Thread in einen separaten Service Worker auszulagern, um sie multithreaded auszuführen.

Lighthouse-Bewertungskriterien

Laut der Chrome-Entwicklerdokumentation gelten folgende Schwellen:

Farbstufe	TBT mobil (ms)	TBT Desktop (ms)
Grün (schnell)	0–200	0–150
Orange (mittel)	200–600	150–350
Rot (langsam)	> 600	> 350

CLS (Cumulative Layout Shift)

Beispiel für eine plötzliche Layoutänderung

Videoquelle: Cumulative Layout Shift (CLS) | Articles | web.dev

In der Bewegung des Cursors spürt man tiefe Wut.

• Unerwartete Layoutverschiebungen verschlechtern die User Experience auf vielfältige Weise: Text springt und man verliert die Leseposition, Links/Buttons werden versehentlich geklickt usw.
• Die genaue Berechnung des CLS-Scores ist auf web.dev beschrieben.
• Wie in der folgenden Grafik ersichtlich, sollte der Zielwert ≤ 0,1 sein.

Bildquelle: Cumulative Layout Shift (CLS) | Articles | web.dev

SI (Speed Index)

• Misst, wie schnell während des Ladens einer Seite Inhalte sichtbar werden
• Lighthouse zeichnet den Ladevorgang als Video auf, analysiert die Fortschritte zwischen den Frames und berechnet daraus mithilfe des Speedline-Node.js-Moduls den SI-Score

Maßnahmen zur Beschleunigung des Seitenladens – einschließlich dessen, was wir bei FCP, LCP und TBT besprochen haben – wirken sich in der Regel auch positiv auf den SI aus. Der SI ist weniger Repräsentant eines einzelnen Teilschritts als vielmehr eine Metrik, die den gesamten Ladeprozess in gewissem Maß abbildet.

Lighthouse-Bewertungskriterien

Laut der Chrome-Entwicklerdokumentation gelten folgende Schwellen:

Farbstufe	SI mobil (s)	SI Desktop (s)
Grün (schnell)	0–3,4	0–1,3
Orange (mittel)	3,4–5,8	1,3–2,3
Rot (langsam)	> 5,8	> 2,3