Core Web Vitals erklärt: LCP, INP und CLS in einfachem Deutsch

Core Web Vitals sind kein Persönlichkeitstest für Ihre Website

Core Web Vitals werden oft wie eine rätselhafte Scorecard behandelt. Eine Seite bekommt eine rote Zahl, jemand postet einen Screenshot in Slack, und das Team beginnt, über JavaScript-Frameworks zu streiten.

Das ist nicht besonders hilfreich.

Die bessere Art, über Core Web Vitals nachzudenken, ist einfacher: Es sind drei Messwerte dafür, ob sich eine Seite für eine echte Person auf einem echten Gerät nutzbar anfühlt. Sie erfassen nicht jeden Aspekt von Performance, Barrierefreiheit oder Qualität. Aber sie erkennen drei häufige Quellen von Frust:

• Der Hauptinhalt braucht zu lange, bis er erscheint.
• Die Seite reagiert langsam, wenn der Nutzer etwas tun möchte.
• Das Layout springt herum, während der Nutzer liest oder tippt.

Das sind die drei Core Web Vitals: LCP, INP und CLS.

Google verwendet sie als Teil seiner Signale für die Nutzererfahrung einer Seite, aber der SEO-Aspekt ist nicht der beste Grund, sich damit zu beschäftigen. Der bessere Grund ist, dass langsame, springende und nicht reagierende Seiten die Zeit der Nutzer verschwenden. Sie konvertieren tendenziell auch schlechter, verursachen mehr Supportaufwand und altern schlecht.

Die drei Metriken in je einem Satz

Bevor wir ins Detail gehen, hier die Version in einfachem Deutsch:

• LCP, oder Largest Contentful Paint, misst, wie lange es dauert, bis der wichtigste sichtbare Inhalt geladen ist.
• INP, oder Interaction to Next Paint, misst, wie schnell die Seite während des Besuchs auf Nutzerinteraktionen reagiert.
• CLS, oder Cumulative Layout Shift, misst, wie stark sich die Seite unerwartet bewegt.

Die üblichen Schwellenwerte sind:

| Metrik | Gut | Verbesserungsbedarf | Schlecht | |---|---:|---:|---:| | LCP | 2,5s oder schneller | 2,5s–4,0s | Über 4,0s | | INP | 200ms oder schneller | 200ms–500ms | Über 500ms | | CLS | 0,1 oder niedriger | 0,1–0,25 | Über 0,25 |

Diese Zahlen werden normalerweise am 75. Perzentil realer Nutzerbesuche ausgewertet. Das ist wichtig. Sie versuchen nicht, einen perfekten Labordurchlauf zu erzeugen. Sie versuchen, die Erfahrung für die meisten Nutzer gut zu machen, einschließlich Menschen mit langsameren Smartphones und unzuverlässigeren Netzwerken.

Wenn Sie auf einen automatisierten Bericht starren und nicht wissen, wo Sie anfangen sollen, hilft es, Diagnose von Panik zu trennen. Wir haben einen separaten Leitfaden dazu, wie man einen Lighthouse-Bericht liest, ohne in Panik zu geraten, der diesen Ablauf ausführlicher behandelt.

LCP: Wann fühlt sich die Seite geladen an?

Largest Contentful Paint misst die Renderzeit des größten sichtbaren Inhaltselements im Viewport. In der Praxis ist das oft:

• ein Hero-Bild,
• eine große Überschrift,
• ein hervorgehobenes Artikelbild,
• ein Produktbild,
• ein großer Textblock.

LCP fragt nicht, wann jedes Script, jedes Tracking-Pixel und jedes Bild unterhalb des sichtbaren Bereichs fertig geladen ist. Es fragt: Wann wurde das Wichtigste sichtbar, weswegen der Nutzer gekommen ist?

Das macht LCP zu einer menschlicheren Metrik als die altmodische „Seitenladezeit“. Eine Seite kann technisch spät fertig laden und sich trotzdem schnell anfühlen, wenn der Hauptinhalt schnell erscheint. Umgekehrt gilt dasselbe: Eine Seite kann das Load-Event auslösen, während der Hero-Bereich noch leer, unscharf oder durch eine Renderverzögerung blockiert ist.

Häufige Ursachen für schlechten LCP

Die meisten schlechten LCP-Probleme entstehen an einigen vorhersehbaren Stellen:

1. Langsame Serverantwort

Wenn das HTML-Dokument spät eintrifft, beginnt alles andere ebenfalls spät.

1. Render-blockierendes CSS oder JavaScript

Der Browser hat den Inhalt, kann ihn aber noch nicht darstellen.

1. Nicht optimierte Hero-Bilder

Das größte Element ist zu groß, im falschen Format, nicht priorisiert oder versehentlich per Lazy Loading geladen.

1. Web Fonts verzögern das Rendern von Text

Eine große Überschrift kann das LCP-Element sein, und das Laden von Fonts kann sie verzögern oder visuell verändern.

1. Verzögerungen durch clientseitiges Rendering

Wenn die Seite ein großes JavaScript-Bundle benötigt, bevor sie sinnvollen Inhalt anzeigen kann, leidet LCP.

Wie man LCP verbessert

Beginnen Sie mit dem tatsächlichen LCP-Element. Optimieren Sie keine zufälligen Assets, bevor Sie wissen, was der Browser misst.

Praktische Maßnahmen sind:

• HTML schnell ausliefern: wo sinnvoll cachen, Backend-Arbeit reduzieren, langsame Redirects vermeiden.
• Das LCP-Bild optimieren: passende Abmessungen, Kompression und Format verwenden.
• Das Hero-Bild oberhalb des sichtbaren Bereichs nicht per Lazy Loading laden.
• fetchpriority="high" vorsichtig für das Hauptbild verwenden, wenn es wirklich die Priorität ist.
• Kritisches CSS nur dann inline einbinden, wenn es die Renderverzögerung spürbar reduziert.
• JavaScript reduzieren, das vor dem ersten sinnvollen Rendern benötigt wird.
• font-display: swap oder eine andere bewusste Font-Strategie verwenden.

Bilder und Fonts sind häufige Verursacher. Bei Bildern lautet die Abwägung nicht einfach „kleine Datei gut“. Formatwahl, Encoding-Aufwand und Browserunterstützung spielen alle eine Rolle, weshalb wir einen praktischen Entscheidungsbaum dafür pflegen, wann AVIF WebP schlägt und wann nicht. Für typografielastige Seiten sind Web Fonts immer noch einer der einfachsten Performance-Gewinne, weil viele Websites mehr Font-Dateien ausliefern, als sie verwenden.

INP: Reagiert die Seite, wenn man sie berührt?

Interaction to Next Paint misst Reaktionsfähigkeit. Genauer gesagt betrachtet es die Verzögerung zwischen einer Nutzerinteraktion und der nächsten visuellen Aktualisierung, nachdem der Browser diese Interaktion verarbeitet hat.

Interaktionen sind zum Beispiel:

• auf einen Button klicken,
• ein Menü antippen,
• eine Checkbox auswählen,
• in ein Formularfeld tippen,
• ein Akkordeon öffnen.

INP hat First Input Delay im Jahr 2024 als Core Web Vital ersetzt. Das war eine gute Änderung. First Input Delay betrachtete nur die erste Interaktion. INP ist breiter angelegt: Es berücksichtigt Interaktionen während des gesamten Seitenbesuchs und meldet eine Interaktion mit hoher Latenz als Reaktionsfähigkeitswert der Seite.

In einfachem Deutsch: INP erkennt Seiten, die geladen aussehen, sich aber festgefahren anfühlen.

Sie haben wahrscheinlich schon eine solche Seite benutzt. Sie wirkt bereit. Sie tippen auf das Menü. Eine halbe Sekunde passiert nichts. Sie tippen erneut. Dann passieren zwei Dinge auf einmal. Das ist ein INP-Problem.

Häufige Ursachen für schlechten INP

INP ist meist ein Main-Thread-Problem. Der Browser möchte reagieren, aber JavaScript, Rendering-Arbeit oder Layout-Berechnung steht im Weg.

Typische Ursachen sind:

• große JavaScript-Bundles,
• aufwendige Event Handler,
• Hydration-Arbeit in clientseitig gerenderten Apps,
• Third-Party-Scripts, die um den Main Thread konkurrieren,
• lang laufende Tasks nach dem Laden der Seite,
• komplexe DOM-Aktualisierungen, die durch kleine Interaktionen ausgelöst werden,
• Layout Thrashing, bei dem Code wiederholt Layout-Werte liest und schreibt.

Marketing-Tags, Analytics, Chat-Widgets und Consent-Banner können alle dazu beitragen. Das bedeutet nicht „alles entfernen“. Es bedeutet, dass jedes Script auf der Seite Kosten hat, und Interaktionslatenz ist oft der Ort, an dem diese Kosten sichtbar werden.

Wie man INP verbessert

INP zu verbessern hat weniger mit einem magischen Attribut zu tun, sondern mehr damit, Konkurrenz auf dem Main Thread zu reduzieren.

Nützliche Ansätze sind:

• Lange JavaScript-Tasks in kleinere Teile aufbrechen.
• Nicht essenzielle Arbeit verschieben, bis die Seite nutzbar ist.
• Unbenutztes JavaScript entfernen, statt es nur zu minifizieren.
• Event Handler klein und vorhersehbar halten.
• Vermeiden, große Teile der Oberfläche für winzige Zustandsänderungen neu zu rendern.
• CSS für einfache visuelle Zustände verwenden, wo möglich.
• Third-Party-Scripts prüfen und nur dort laden, wo sie benötigt werden.

Betrachten Sie auch das Interaktionsdesign. Ein Button, der sofort visuelles Feedback gibt, kann sich reaktionsschneller anfühlen, selbst wenn Folgearbeit länger dauert. Das ist kein Ersatz für Performance, aber Teil guter Interface-Entwicklung. Unsere Checkliste für barrierefreie Web-Buttons überschneidet sich damit: klare Zustände, korrekte Semantik und vorhersehbares Verhalten helfen sowohl Nutzern als auch Browsern.

CLS: Bleibt die Seite dort, wo der Nutzer sie erwartet?

Cumulative Layout Shift misst unerwartete Bewegungen sichtbarer Elemente. Wenn ein Nutzer beginnt, einen Absatz zu lesen, und eine Anzeige, ein Bild oder ein Banner darüber lädt und den Text nach unten schiebt, trägt das zu CLS bei.

CLS wird nicht in Sekunden gemessen. Es ist ein Score, der darauf basiert, wie viel Inhalt sich bewegt hat und wie weit er sich bewegt hat. Niedriger ist besser.

Das Schlüsselwort ist unerwartet. Layoutänderungen, die durch eine Nutzeraktion verursacht werden, werden normalerweise nicht auf dieselbe Weise gezählt. Wenn jemand auf „mehr anzeigen“ tippt und Inhalt aufklappt, ist das erwartet. Wenn nach drei Sekunden oben ein Newsletter-Banner erscheint und alles nach unten schiebt, ist das nicht erwartet.

Häufige Ursachen für schlechten CLS

CLS-Fehler sind oft banal:

• Bilder ohne width- und height-Attribute,
• Anzeigen oder Embeds ohne reservierten Platz,
• Cookie-Banner, die oberhalb des Inhalts eingefügt werden,
• Web Fonts, die mit anderen Metriken eingetauscht werden,
• spät ladende Werbeleisten,
• dynamisch eingefügte Inhalte nahe am oberen Seitenbereich.

Die Lösung besteht meist darin, Platz zu reservieren, bevor der Inhalt eintrifft. Der Browser sollte die Form der Seite so früh wie möglich kennen.

Wie man CLS verbessert

Beginnen Sie mit den sichtbaren Verschiebungen. Sehen Sie sich eine Aufzeichnung an oder verwenden Sie Browser-Tools, um zu erkennen, welche Elemente sich bewegen.

Dann wenden Sie die langweiligen Maßnahmen an:

• Explizite width- und height-Attribute zu Bildern hinzufügen.
• CSS aspect-ratio für responsive Mediencontainer verwenden.
• Feste oder Mindestflächen für Anzeigen, Embeds und iframes reservieren.
• Vermeiden, Banner nach dem Laden oberhalb bestehender Inhalte einzufügen.
• Font-Fallbacks mit ähnlichen Metriken wie der endgültige Font wählen.
• Animationen vermeiden, die Layout-Eigenschaften wie top, left, width oder height verändern; Transforms bevorzugen.

CLS ist eine der wenigen Performance-Metriken, bei denen Disziplin Cleverness schlägt. Wenn die Seite stabile Boxen hat, schneidet sie tendenziell gut ab.

Feld- und Labordaten sind beide nützlich, beantworten aber unterschiedliche Fragen

Eine häufige Ursache für Verwirrung ist, dass verschiedene Tools unterschiedliche Zahlen anzeigen. Das ist normal.

Felddaten stammen von echten Nutzern. Sie spiegeln tatsächliche Geräte, Netzwerke, Standorte und Browserbedingungen wider. Googles Chrome User Experience Report ist ein Beispiel für Felddaten.

Labordaten stammen aus einer kontrollierten Testumgebung. Lighthouse ist das bekannte Beispiel. Es ist wiederholbar und nützlich für das Debugging, aber es ist nicht dasselbe wie die gelebte Erfahrung Ihrer Nutzer.

Nutzen Sie Felddaten, um zu entscheiden, ob Nutzer ein echtes Problem haben. Nutzen Sie Labordaten, um dieses Problem zu reproduzieren und zu debuggen.

Denken Sie auch daran, dass Core Web Vitals normalerweise pro URL oder URL-Gruppe bewertet werden, nicht als eine einzige abstrakte Eigenschaft Ihrer Marke. Ihre Startseite, Ihr Blogartikel, Ihre Preisseite und Ihr Checkout können sehr unterschiedliche Engpässe haben.

Eine sinnvolle Reihenfolge der Arbeit

Wenn alle drei Metriken schlecht sind, ist die Versuchung groß, überall zu beginnen. Widerstehen Sie dem.

Eine praktische Reihenfolge ist:

1. Offensichtliche CLS-Probleme zuerst beheben

Fehlende Bildabmessungen und instabile Banner sind oft schnelle Erfolge.

1. LCP für wichtige Templates verbessern

Konzentrieren Sie sich auf Seiten, die zählen: Produktseiten, Landingpages, Artikel, Registrierungsstrecken.

1. INP mit echten Interaktionen untersuchen

Klicken Sie die Dinge, die Nutzer tatsächlich anklicken. Menüs, Filter, Formulare und Checkout-Steuerelemente zeigen oft mehr als der anfängliche Lade-Trace.

1. Third-Party-Scripts auditieren

Behalten Sie diejenigen, die ihre Kosten rechtfertigen. Entfernen oder verzögern Sie diejenigen, die das nicht tun.

1. Ein Performance-Budget festlegen

Ohne Budget verfallen Performance-Verbesserungen. Neue Scripts, Bilder und Designkomponenten machen die Arbeit leise wieder zunichte.

Der wichtige Punkt: Optimieren Sie nicht für ein Badge. Optimieren Sie für die User Journey. Eine marginale Score-Verbesserung auf einer Seite mit wenig Traffic kann weniger wichtig sein als eine leicht unvollkommene, aber viel schnellere Checkout-Interaktion.

<!-- tool-cta:start -->

💡 Probier das aus: Da LCP normalerweise ein Bildproblem ist, verkleinere dein Hero-Asset mit Image Compressor als ersten, einfachen Gewinn.

<!-- tool-cta:end -->

Was Core Web Vitals Ihnen nicht sagen

Core Web Vitals sind nützlich, aber unvollständig.

Sie sagen Ihnen nicht, ob Ihr Inhalt gut ist. Sie sagen Ihnen nicht, ob Ihre Navigation sinnvoll ist. Sie garantieren keine Barrierefreiheit. Sie messen weder Datenschutz, Sicherheit, Vertrauen und Lesbarkeit noch ob die Seite die Frage des Nutzers beantwortet.

Sie ersetzen auch kein Urteilsvermögen. Eine Seite kann Core Web Vitals bestehen und trotzdem unangenehm sein. Eine komplexe Anwendung kann einen Schwellenwert verfehlen und dennoch verantwortungsvoll für ihre Rahmenbedingungen entwickelt sein.

Behandeln Sie LCP, INP und CLS wie Rauchmelder. Wenn sie anschlagen, untersuchen Sie die Ursache. Wenn sie ruhig sind, halten Sie das Gebäude weiter instand.