Core Web Vitals praktisch erklärt: LCP, INP, CLS

Die scheduler.postTask-API ist ab Chrome 94 stabil und der saubere Weg, eine Operation an Yieldpoints zu binden, ohne setTimeout(0)- Hacks.

CLS: Layoutverschiebungen

Cumulative Layout Shift ist die Summe aller unerwarteten Layout-Sprünge nach dem ersten Render. Schwellwert 0,1.

In Audits dominieren drei Quellen:

1. Bilder ohne explizite Maße. <img> ohne width/height oder ohne aspect-ratio im CSS. Der Reflow nach Bildladung springt.
2. Web Fonts ohne font-display: optional. Der Swap von Fallback auf Web Font verschiebt jeden Textblock.
3. Cookie-Banner und Werbeplätze mit Lazy-Insertion. Wer das Cookie-Banner erst nach DOMContentLoaded einfügt und nicht reserviert, holt sich CLS-Werte > 0,3.

Der Fix für Punkt 1 ist trivial und hat in den letzten zehn Audits in jedem Fall den CLS unter 0,1 gedrückt: width und height schreiben, das CSS sorgt mit height: auto für die Skalierung.

Was diese Metriken nicht messen

Core Web Vitals sagen nichts über Time to Interactive auf langsamen Verbindungen, nichts über Memory-Pressure, nichts über JavaScript-Bundle-Größe. Eine Seite mit perfekten Vitals kann auf einem 3G-Verbindung trotzdem unbrauchbar sein, wenn sie 2 MB JavaScript zieht. Die Vitals sind eine Untergrenze, kein Beweis für Qualität.

Praktischer Hebel

Wenn Sie den LCP-Hebel ziehen, fallen INP und CLS oft mit. Ein hero-image mit fetchpriority="high" und expliziten Maßen verschiebt das Render-Profil so weit nach vorn, dass das parallel geladene JavaScript bis zur ersten Interaktion bereits geparst ist.

Was Ihre Domain heute liefert, sehen Sie im Seitenbefund-Kurzcheck — passive Messung, keine Installation, in Minuten.