Core Web Vitals: was sie wirklich messen und wie du sie sinnvoll verbesserst
Core Web Vitals sind im Kern ein Versuch, „Nutzergefühl“ messbar zu machen. Nicht perfekt, nicht komplett, aber nützlich, wenn man sie als Orientierung nutzt. Das Problem ist weniger die Metrik selbst, sondern die typische Reaktion: Zahlen sehen schlecht aus, also wird hektisch an Kleinigkeiten geschraubt, bis die Seite zwar im Tool besser aussieht, aber im Alltag nicht ruhiger wird.
Wenn du es pragmatisch angehst, sind Core Web Vitals eigentlich simpel. Es geht um drei Fragen: Wann sieht man sinnvollen Inhalt, wie schnell reagiert die Seite, und bleibt das Layout stabil. Löst du diese drei Punkte sauber, bist du meistens auf der guten Seite, auch ohne Perfektion.
Die drei Kennzahlen in normaler Sprache
LCP: wann ist der erste echte Inhalt da
LCP (Largest Contentful Paint) ist grob gesagt der Moment, in dem der größte sichtbare Inhaltsblock im Viewport gerendert ist. Auf vielen Seiten ist das ein Hero-Bild, eine große Überschrift oder ein prominenter Content-Block. LCP wird schlecht, wenn du den Start künstlich blockierst: zu große Bilder, zu viel CSS/JS am Anfang, Fonts, die Text verzögern, oder ein Server, der trödelt.
INP: wie schnell reagiert die Seite auf echte Eingaben
INP (Interaction to Next Paint) beschreibt, wie schnell eine Seite nach einer Nutzeraktion sichtbar reagiert. Das ist der Teil, der sich als „hakelig“ anfühlt: du klickst, aber die Seite wirkt kurz eingefroren. Ursache ist oft JavaScript, das zu viel Arbeit am Main Thread macht. Häufig sind das Third-Party-Skripte, zu große Bundles, unnötige Framework-Overheads oder einfach zu viel gleichzeitig.
CLS: bleibt alles stabil oder springt es beim Laden
CLS (Cumulative Layout Shift) misst, ob sich Layout-Elemente verschieben, während die Seite lädt. Das ist dieser Moment, in dem du gerade klicken willst und der Button rutscht weg, weil oben ein Banner nachlädt oder weil ein Bild ohne feste Maße plötzlich Platz beansprucht. CLS ist oft der schnellste „Feel“-Fix, weil Layout-Ruhe sofort Vertrauen schafft.
Field vs Lab: warum Tools dich manchmal nervös machen
Viele schauen nur in Lab-Daten (Lighthouse, PageSpeed-Simulation). Das ist okay, um grobe Probleme zu finden, aber es ist nicht die Realität. Field-Daten spiegeln echte Nutzer wider: unterschiedliche Geräte, unterschiedliche Netze, echte Interaktionen. Eine Seite kann im Labor solide aussehen und trotzdem im Alltag hängen, weil ein bestimmtes Script auf schwachen Geräten alles blockiert. Umgekehrt kann ein Lab-Test mäkeln, obwohl Nutzer die Seite als schnell empfinden.
Wenn du priorisieren willst, hilft ein einfacher Gedanke: Was beeinflusst das erste Gefühl. Menschen entscheiden schnell, ob eine Seite „fertig“ wirkt. Das ist oft LCP plus visuelle Ruhe (CLS). Danach kommt Interaktion (INP). Wenn du an drei Stellen ansetzt, hast du meistens schon die halbe Miete: Above-the-fold sauber, Bilder/Fonts sinnvoll, JavaScript entrümpeln.
Hebel, die fast immer wirken
1) Above-the-fold priorisieren
Was oben sichtbar ist, muss schnell kommen. Alles andere darf später passieren. Das klingt banal, aber viele Seiten laden erst riesige Bundles, Tracking, Slider und Styles, bevor der erste sinnvolle Inhalt steht. Wenn du den Start entlastest, verbessert sich LCP oft automatisch. Auch bei statischen Seiten ist das relevant, weil Fonts und große Hintergrundbilder den Eindruck stark beeinflussen.
2) Bilder richtig dimensionieren
Zu große Bilder sind ein Dauerbrenner. Gerade Hero-Bilder werden gern in absurd hohen Auflösungen ausgeliefert, obwohl die Darstellung kleiner ist. Das kostet Ladezeit, blockiert Rendering und verschiebt oft das Layout. Wenn du hier aufräumst, bekommst du meist bessere LCP-Werte und weniger Stress im Mobilnetz.
3) Layout-Platz reservieren
CLS ist oft ein Reservierungsproblem. Bilder ohne feste Maße, eingeblendete Elemente ohne Platz, dynamische Fonts ohne saubere Fallbacks. Definiere Maße, nutze stabile Container und lass den Browser früh wissen, wie groß etwas ungefähr wird. Damit verhinderst du den nervigen „Wackelstart“.
4) JavaScript entschärfen
INP leidet, wenn der Main Thread voll ist. Weniger Script, kleinere Bundles, weniger Third-Party, weniger Arbeit pro Klick. Oft hilft schon, die größten Brocken zu identifizieren: Consent-Manager, Tracking, Widgets, Slider. Viele dieser Dinge sind nicht „böse“, aber sie müssen nicht unbedingt im kritischen Pfad hängen. Wenn du sie nach hinten schiebst oder reduzierst, fühlt sich die Seite sofort flüssiger an.
Wenn du das Thema noch kompakter lesen willst, schau in den Artikel Core Web Vitals. Diese Unterseite hier ist eher als Arbeitsgrundlage gedacht, damit du eine klare Reihenfolge hast.