Core Web Vitals: eine Website wirklich schnell machen
Geschwindigkeit ist kein Luxus: Sie ist ein Google-Rankingfaktor und ein Conversion-Treiber. Eine Aufschlüsselung der Core Web Vitals — LCP, INP, CLS — und der konkreten Hebel, mit denen ich sie im Grünen halte.
„Bei mir läuft es gut" reicht nicht
Die klassische Falle: Der Entwickler testet mit Glasfaser, einem aktuellen MacBook, mit warmem Cache. Der reale Nutzer hingegen kommt über ein Mittelklasse-Handy, bei launischem 4G, mit leerem Cache. Zwischen beiden hat die Erfahrung nichts gemein.
Die Core Web Vitals existieren, um zu messen, was der Nutzer tatsächlich erlebt. Google hat sie zu einem Rankingfaktor gemacht — und vor allem sagen sie die Conversion voraus: Jede zusätzliche Ladesekunde vertreibt Besucher.
Die drei Metriken, die zählen
- LCP (Largest Contentful Paint) — die Zeit, bis das Hauptelement (oft das Hero-Bild oder die Überschrift) erscheint. Ziel: unter 2,5 s.
- INP (Interaction to Next Paint) — die Reaktionsfähigkeit: die Verzögerung zwischen Klick und sichtbarer Reaktion. Ziel: unter 200 ms. Der Knackpunkt bei JavaScript-lastigen Seiten.
- CLS (Cumulative Layout Shift) — die Stabilität: jene Layout-Sprünge, die zum Klick an der falschen Stelle führen, wenn ein Bild oder eine Anzeige lädt. Ziel: unter 0,1.
Eine schöne, langsame Website ist eine gescheiterte Website. Performance ist nicht der Feind des Designs — sie ist eine Beschränkung, die zu klaren Entscheidungen zwingt.
Die Hebel, die ich nutze
Eine Website schnell zu machen ist nichts Magisches, sondern eine Summe von Entscheidungen:
- Bilder — modernes Format (AVIF/WebP), korrekte Maße,
lazy loadingunterhalb des Falzes und reservierter Platz, um Sprünge zu vermeiden (CLS). - Schriften —
font-display: swap, Vorladen der wirklich genutzten Schnitte und vor allem: nur diese laden. - JavaScript — so wenig wie möglich ausliefern. Der schnellste Code ist der, den man nicht an den Browser schickt. Server-Komponenten, verzögertes Laden des Unkritischen.
- Rendering — statisch bevorzugen (beim Build vorgeneriert), wenn der Inhalt es zulässt: Nichts schlägt eine bereits fertige Datei.
- Kontinuierliche Messung — ein Performance-Budget und Monitoring (Lighthouse, Speed Insights), damit eine Regression vor der Produktion sichtbar wird, nicht danach.
Im Feld messen, nicht im Labor
Es gibt zwei Arten zu messen: Labor-Daten (Lighthouse, kontrollierte Umgebung) und Feld-Daten (echte Nutzer, über den Chrome UX Report). Beide sind nützlich, aber nur die zweiten spiegeln die Realität. Eine Website kann im Labor 100 erreichen und im Feld enttäuschen — wegen einer langsamen Verbindung oder eines bescheidenen Geräts.
Meine Disziplin: im Labor optimieren, um schnell zu sein, aber im Feld validieren, bevor man Sieg meldet.
Warum es für einen Kunden zählt
Eine schnelle Website ist nicht nur technische Koketterie. Sie bedeutet mehr Besucher, die bleiben, bessere Google-Rankings und mehr Conversions. Geschwindigkeit ist eine der seltenen Verbesserungen, die dem Nutzer, dem Ranking und dem Umsatz zugleich dient. Deshalb behandle ich sie als Anforderung, nicht als Bonus.