Core Web Vitals für Entwickler: Was die Zahlen wirklich bewegt
Core Web Vitals sind drei Feldmessungen dafür, wie sich eine Seite anfühlt: wie lange es dauert, bis der Hauptinhalt erscheint, wie stark er sich beim Laden bewegt, und wie schnell er auf Eingaben reagiert. Sie sind ein Ranking-Signal und, wichtiger noch, sie hängen damit zusammen, ob Menschen bleiben.
Dieser Leitfaden behandelt, was jede Kennzahl misst, die konkreten Ursachen hinter schlechten Werten, und die Korrekturen, die Felddaten bewegen statt nur Laborwerte.
Was die drei Kennzahlen messen#
Jede hat einen Schwellenwert für „gut" und jede hat wenige übliche Ursachen. Beachten Sie: Für das Ranking zählen Felddaten echter Besucher, nicht ein Laborwert von Ihrem Laptop.
| Kennzahl | Gut | Misst | Übliche Ursache bei schlechtem Wert |
|---|---|---|---|
| LCP | Unter 2,5 s | Zeit, bis das größte sichtbare Element gerendert ist | Unoptimiertes Hero-Bild, langsamer Server, renderblockierendes CSS |
| CLS | Unter 0,1 | Wie stark sich das Layout beim Laden bewegt | Bilder ohne Maße, eingefügte Banner, spät geladene Webfonts |
| INP | Unter 200 ms | Reaktionsfähigkeit auf Nutzerinteraktion | Lange JavaScript-Aufgaben blockieren den Haupt-Thread |
Laborwerkzeuge messen einen Ladevorgang auf einer Maschine. Felddaten sind das 75. Perzentil echter Besuche, was alte Handys in schlechten Netzen einschließt — genau die Besucher, die am ehesten gehen.
LCP beheben#
LCP ist fast immer ein Bild oder eine Überschrift, die hinter etwas anderem blockiert. Arbeiten Sie die Punkte der Reihe nach ab; die ersten beiden beheben die meisten Websites.
- Identifizieren Sie das tatsächliche LCP-Element in den Felddaten. Das falsche Bild zu optimieren ist die häufigste vergeudete Mühe.
- Laden Sie das LCP-Bild nie verzögert. Geben Sie ihm stattdessen fetchpriority="high".
- Liefern Sie es in einem modernen Format in der Größe aus, in der es angezeigt wird, mit srcset für kleinere Bildschirme.
- Laden Sie die Schrift des LCP-Textes vor und nutzen Sie font-display: swap, damit Text während des Wartens nicht unsichtbar ist.
- Entfernen Sie renderblockierendes CSS und JavaScript aus dem head; inlinen Sie das kritische CSS, wenn die Seite klein genug ist.
- Senken Sie die Time to First Byte mit Caching und einem CDN — keine Frontend-Arbeit kann einen langsamen Server ausgleichen.
- Kürzen Sie Drittanbieterskripte im kritischen Pfad. Jedes ist eine DNS-Auflösung, eine Verbindung und eine unvorhersehbare Datei.
CLS beheben#
Layoutverschiebung ist fast vollständig vermeidbar und die Korrekturen sind billig. Es ist außerdem die Kennzahl, die Besucher am unmittelbarsten spüren — sie ist der Grund, warum Menschen daneben tippen.
- Setzen Sie width- und height-Attribute an jedem Bild und Video, damit der Browser Platz reserviert.
- Reservieren Sie Platz für Werbung, Einbettungen und iframes mit einem Container fester Seitenverhältnisse.
- Fügen Sie nach dem Laden nie Inhalt oberhalb bestehenden Inhalts ein — Cookie-Banner gehören nach unten oder als Overlay.
- Passen Sie die Metriken der Ersatzschrift an den Webfont an, oder nutzen Sie size-adjust, damit der Wechsel die Seite nicht umbricht.
- Vermeiden Sie es, Layout-Eigenschaften zu animieren. Animieren Sie transform und opacity, die keinen Reflow auslösen.
- Geben Sie dynamisch geladenen Bereichen eine min-height, damit sie sich nicht von null aufblähen.
INP beheben#
INP hat First Input Delay abgelöst und ist schwieriger, weil es jede Interaktion über den ganzen Besuch misst statt nur die erste. Schlechtes INP ist fast immer zu viel JavaScript auf dem Haupt-Thread.
| Ursache | Lösung |
|---|---|
| Großes Bundle beim Laden geparst | Code-Splitting; nur laden, was die Seite braucht |
| Lange Aufgaben über 50 ms | Arbeit in Stücke teilen und dem Haupt-Thread abgeben |
| Teure Event-Handler | Entprellen und schwere Arbeit vom Interaktionspfad nehmen |
| Schwere Drittanbieter-Tags | Nach der Interaktion laden oder entfernen — prüfen Sie, was jedes einbringt |
| Großes DOM (10.000+ Knoten) | Lange Listen virtualisieren; tief verschachteltes Markup vereinfachen |
| Layout-Thrashing in Handlern | Lese- und Schreibzugriffe bündeln statt zu verschränken |
Auf Inhaltsseiten ist die wertvollste INP-Maßnahme meist, JavaScript zu löschen statt es zu optimieren. Fragen Sie, was jedes Skript einbringt; Tag-Manager sammeln Skripte an, an deren Einbau sich niemand erinnert.
Häufige Fragen
Wie stark beeinflussen Core Web Vitals das Ranking?
Sie sind ein echtes, aber moderates Signal und wirken eher als Gleichstandsentscheider denn als Ersatz für Relevanz. Eine schnelle Seite zum falschen Thema überholt keine langsamere Seite, die die Anfrage beantwortet. Das stärkere Argument fürs Beheben ist Verhalten: Langsame, springende Seiten verlieren Besucher, bevor Ranking überhaupt ins Spiel kommt.
Warum ist mein Lighthouse-Wert gut, aber meine Felddaten schlecht?
Weil Lighthouse einen Ladevorgang auf Ihrer Maschine mit Ihrer Verbindung simuliert, und Felddaten das 75. Perzentil echter Besuche sind — inklusive drei Jahre alter Handys in überlasteten Mobilfunknetzen. Wenn beide sich widersprechen, zählen die Felddaten. Nutzen Sie Laborwerkzeuge zur Diagnose, nicht zur Benotung.
Muss ich alle drei Kennzahlen beheben?
Beheben Sie die, die durchfallen, in der Reihenfolge dessen, was Ihre Besucher erleben. CLS ist meist am billigsten zu beheben und für Nutzer am störendsten, also ein guter Anfang. LCP hat den größten Einfluss darauf, ob Menschen warten. INP zählt am meisten auf interaktiven Websites und am wenigsten bei statischen Artikeln.
Wie lange dauert es, bis Verbesserungen sichtbar werden?
Felddaten sind ein rollierendes 28-Tage-Fenster, also braucht spürbare Bewegung etwa vier Wochen, nachdem eine Korrektur alle Besucher erreicht hat. Beurteilen Sie eine Änderung nicht nach drei Tagen. Prüfen Sie aber sofort die Laborwerte, um zu bestätigen, dass die Korrektur tatsächlich das getan hat, was Sie erwartet haben.
core web vitalslcpclsinpseitengeschwindigkeitweb performance
