Core Web Vitals spiegati: LCP, INP e CLS

I Core Web Vitals sono tre metriche utilizzate per valutare aspetti importanti dell'esperienza utente di un sito web: velocità di caricamento, reattività e stabilità visiva.

I tre attuali Core Web Vitals sono Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS).

Tuttavia, un buon valore da solo non significa che l'intero sito web funzioni in modo rapido e senza problemi. Ciascuno dei tre parametri prende in considerazione un aspetto diverso dell'esperienza utente.

In questo articolo ti spieghiamo cosa misurano LCP, INP e CLS, quali valori sono considerati buoni e come cercare sistematicamente la causa in caso di risultati anomali.

Breve spiegazione: LCP misura, in modo semplificato, quanto velocemente diventa visibile un contenuto principale importante della pagina. L'INP valuta la velocità con cui il sito web reagisce alle interazioni degli utenti. Il CLS misura gli spostamenti inattesi del layout durante l'utilizzo.

Cosa sono i Core Web Vitals? #

I Core Web Vitals sono metriche definite da Google per valutare determinati aspetti dell'effettiva esperienza utente di una pagina web.

I tre attuali Core Web Vitals sono:

Valore misurato	Nome completo	Valutato
LCP	Largest Contentful Paint	Esperienza di ricarica
INP	Interazione fino al prossimo rendering	Reattività
CLS	Cumulative Layout Shift	Stabilità visiva

I valori si completano a vicenda, perché un sito web può essere molto buono in un'area e problematico in un'altra.

I valori limite in sintesi #

Google suddivide i valori nelle categorie „buono“, „da migliorare“ e „scarso“.

Valore misurato	Bene	Migliorabile	Male
LCP	≤ 2,5 s	da 2,5 s a 4,0 s	> 4,0 s
INP	≤ 200 ms	da 200 ms a 500 ms	> 500 ms
CLS	≤ 0,1	da 0,1 a 0,25	0,25

Importante: Ognuno di questi valori limite appartiene a una determinata metrica. Ad esempio, un limite LCP di 2,5 secondi non significa che qualsiasi altro tempo di caricamento concepibile debba anch'esso essere inferiore a 2,5 secondi.

Perché viene utilizzato il 75° percentile? #

Nel valutare i dati di utilizzo reali, non si guarda semplicemente alla visualizzazione di pagina migliore o media.

Per i Core Web Vitals viene utilizzato il 75° percentile.

Semplificando, questo significa che almeno il 75 percento delle esperienze misurate dovrebbe raggiungere il rispettivo valore limite o essere migliore.

100 esperienze misurate

75 o più
→ intervallo ottimale

se il valore al 75° percentile
rientra nel limite ottimale

In questo modo la valutazione non è determinata unicamente da dispositivi e connessioni particolarmente veloci.

Superare i Core Web Vitals: cosa significa? #

Per una buona valutazione dei Core Web Vitals, i tre indicatori chiave LCP, INP e CLS, in presenza di una base di dati sufficiente, devono rientrare nell'intervallo ottimale al 75° percentile.

Quindi un sito web può ad esempio avere un buon LCP e CLS, ma non superare la valutazione dei Core Web Vitals a causa di un INP scarso.

LCP → buono
INP → scarso
CLS → buono

Risultato:
Core Web Vitals non superati completamente

LCP – Largest Contentful Paint #

Il Largest Contentful Paint misura il tempo necessario per il rendering del più grande elemento di contenuto rilevante nell'area visibile.

In questo modo, l'LCP dovrebbe misurare approssimativamente quando una parte sostanziale del contenuto principale è diventata visibile per il visitatore.

Un buon LCP è inferiore a:

2,5 secondi o meno

Quale elemento può essere l'elemento LCP? #

Questo dipende dalla struttura della rispettiva pagina.

Spesso si tratta, ad esempio, di:

grande immagine hero
grande intestazione di testo
banner
grande immagine di contenuto
grande blocco di testo

Dovresti verificare quale elemento viene effettivamente riconosciuto come LCP con uno strumento di performance e non semplicemente intuirlo in base al design.

Esempio di LCP #

Supponendo che una pagina iniziale abbia una grande immagine hero nella parte superiore:

┌─────────────────────────────────────┐
│ Navigazione                          │
├─────────────────────────────────────┤
│                                     │
│          IMMAGINE EROE DI GRANDI DIMENSIONI          │
│                                     │
│        Web hosting per PMI           │
│                                     │
└─────────────────────────────────────┘

Se questa immagine rappresenta il più grande elemento rilevante nell'area visibile, può diventare l'elemento LCP.

Se si carica in ritardo, anche l'LCP potrebbe peggiorare.

Cosa può causare un LCP scarso? #

Un LCP elevato può avere diverse cause.

Questi possono includere, ad esempio:

• una fornitura lenta del documento HTML,
• un'immagine LCP molto grande,
• una risorsa d'immagine scoperta tardi,
• risorse che bloccano il rendering,
• Webfont,
• rendering lato client,
• una priorità di ricarica sfavorevole.

Quale sia la causa effettiva, deve essere esaminato sulla singola pagina.

In caso di LCP scarso, identificare prima l'elemento LCP #

Prima di modificare qualsiasi impostazione delle prestazioni, dovresti determinare quale elemento viene effettivamente misurato.

LCP scarso
    ↓
Identificare l'elemento LCP
    ↓
Immagine?
Testo?
Altro elemento?
    ↓
Analizzare il percorso di caricamento di questo elemento

Google PageSpeed Insights può fornire indicazioni sull'elemento LCP e sul suo comportamento di caricamento durante l'analisi.

Ti spieghiamo come utilizzare lo strumento su Usare correttamente Google PageSpeed Insights.

Se un'immagine è l'elemento LCP #

Se un'immagine hero o un'immagine di contenuto è responsabile del LCP, dovresti prima verificarne le caratteristiche tecniche.

Tra gli altri, sono interessanti:

Dimensioni in pixel
Dimensione del file
Formato dell'immagine
Compressione
varianti di immagini responsive
Momento del rilevamento
Priorità di caricamento
Lazy loading

Un'immagine nell'area immediatamente visibile non dovrebbe, ad esempio, essere trattata allo stesso modo senza verifiche rispetto a un'immagine molto più in basso nella pagina.

Spiegheremo come preparare opportunamente le immagini su Ottimizzare le immagini per il web: dimensione del file, formato e SEO.

Il lazy loading può essere problematico per l'LCP #

Il lazy loading è spesso utile per le immagini al di fuori dell'area immediatamente visibile.

Tuttavia, se un'importante immagine LCP nella parte superiore della pagina viene caricata con un ritardo non necessario, ciò può peggiorare l'LCP.

Ecco perché non vale:

Tutte le immagini = Lazy Loading

Bensì:

Implementare il Lazy Loading dove il caricamento ritardato ha senso.

Un formato di immagine moderno da solo non risolve un LCP scarso #

WebP o AVIF possono aiutare a ridurre le dimensioni del file di un'immagine. Tuttavia, il formato è solo una parte dell'intero percorso di caricamento.

Un'immagine WebP gigantesca con dimensioni in pixel non necessarie può continuare a essere problematica.

Anche un piccolo file immagine può essere caricato in ritardo se il browser lo scopre tardi.

Trattiamo la scelta del formato dell'immagine in WebP, AVIF, JPG e PNG: quale formato di immagine usare?.

La risposta del server può influenzare l'LCP #

Prima che il browser possa eseguire il rendering dei contenuti importanti della pagina, deve prima ricevere i dati necessari.

Se già la fornitura del documento HTML richiede molto tempo, si sposta anche il momento in cui le risorse successive possono essere scoperte e visualizzate.

Un LCP scarso non dovrebbe quindi essere considerato esclusivamente come un „problema di immagini“.

INP – Interaction to Next Paint #

Interaction to Next Paint misura la reattività di una pagina alle interazioni degli utenti.

Ciò include, ad esempio, le interazioni tramite:

Clic del mouse
Touchscreen
Tastiera

INP betrachtet, wie lange es dauert, bis eine Interaktion verarbeitet wird und der Browser anschließend eine visuelle Aktualisierung darstellen kann.

Ein guter INP liegt bei:

200 Millisekunden oder weniger

Was bedeutet INP für einen Besucher? #

Stell dir vor, du klickst auf einen Button.

Bei einer reaktionsschnellen Website erhältst du praktisch unmittelbar eine sichtbare Reaktion.

Bei einer schlechten Reaktionsfähigkeit kann dagegen eine merkliche Verzögerung entstehen:

Klick
  ↓
........ Verzögerung ........
  ↓
sichtbare Reaktion

Genau diese Art von Nutzererfahrung soll INP messbar machen.

INP misst nicht einfach nur den ersten Klick #

INP betrachtet die Interaktionen während des Besuchs einer Seite und versucht, die gesamte Reaktionsfähigkeit anhand einer repräsentativen langsamen Interaktion zu bewerten.

Es handelt sich damit nicht einfach um eine Messung der ersten Interaktion nach dem Seitenaufruf.

Was gehört zu einer Interaktionslatenz? #

Vereinfacht lässt sich die Zeit einer Interaktion in mehrere Abschnitte zerlegen:

Benutzer interagiert
        ↓
Eingabeverzögerung
        ↓
Event-Handler / Verarbeitung
        ↓
Darstellungsverzögerung
        ↓
nächster sichtbarer Frame

Probleme können in unterschiedlichen Teilen dieses Ablaufs entstehen.

Was kann einen schlechten INP verursachen? #

Eine häufige Ursache ist zu viel Arbeit auf dem Hauptthread des Browsers.

Dazu kann umfangreiches oder ineffizientes JavaScript beitragen.

Ulteriori possibili cause sono ad esempio:

• lange JavaScript-Aufgaben,
• aufwendige Event-Handler,
• komplexe DOM-Änderungen,
• umfangreiche Layout- und Rendering-Arbeit,
• viele gleichzeitig ausgeführte Scripts,
• aufwendiger Drittanbieter-Code.

Was ist der Main Thread? #

Der Hauptthread beziehungsweise Main Thread des Browsers übernimmt zahlreiche Aufgaben, die für die Darstellung und Interaktion einer Webseite erforderlich sind.

Dazu gehören unter anderem Teile der JavaScript-Ausführung, Layoutberechnungen und Rendering-Arbeiten.

Ist dieser Thread lange mit einer Aufgabe beschäftigt, kann er nicht gleichzeitig sofort auf eine neue Benutzerinteraktion reagieren.

Main Thread:

████████ lange JavaScript-Aufgabe ████████
                                      ↓
                         Benutzer klickt hier
                                      ↓
                         muss zunächst warten

Was sind Long Tasks? #

Lange Aufgaben auf dem Hauptthread können die Reaktionsfähigkeit einer Website beeinträchtigen.

Eine umfangreiche JavaScript-Aufgabe kann beispielsweise den Browser so lange beschäftigen, dass Benutzerinteraktionen verzögert verarbeitet werden.

Bei der INP-Optimierung ist deshalb häufig interessant, welche Aufgaben während einer langsamen Interaktion stattfinden.

INP ist nicht dasselbe wie TBT #

In Lighthouse begegnet dir häufig der Wert Total Blocking Time, kurz TBT.

TBT ist eine Laborkennzahl. INP basiert dagegen auf tatsächlichen Benutzerinteraktionen und ist ein Core Web Vital.

TBT kann für die technische Diagnose hilfreich sein, ist aber kein Ersatz für INP.

TBT
→ Labormessung

INP
→ reale Interaktionsdaten möglich
→ Core Web Vital

Warum kann PageSpeed keinen echten INP im Labortest erzeugen? #

INP benötigt echte Benutzerinteraktionen während eines Seitenbesuchs.

Ein synthetischer Lighthouse-Ladetest besitzt nicht dieselbe Sammlung realer Interaktionen wie Felddaten.

Deshalb solltest du bei INP besonders auf verfügbare Felddaten achten.

Was tun bei schlechtem INP? #

Versuche zunächst herauszufinden, welche Interaktionen langsam sind.

Esempi:

Menü öffnen
Filter anwenden
Produktvariante auswählen
Accordion öffnen
Formular bedienen
Warenkorb aktualisieren
Cookie-Banner bedienen

Anschließend solltest du untersuchen, welche JavaScript- oder Rendering-Arbeit durch diese Interaktion ausgelöst wird.

Consiglio pratico: Bei einem schlechten INP solltest du nicht einfach wahllos JavaScript-Dateien deaktivieren. Finde zuerst heraus, welche Interaktion langsam ist und was der Browser während dieser Interaktion verarbeitet.

Drittanbieter-Scripts können INP beeinflussen #

Websites laden häufig JavaScript von externen Diensten.

Gli esempi sono:

Analytics
Tag-Manager
Chat-Systeme
Social-Media-Widgets
Werbesysteme
Tracking
Maps
Marketing-Tools

Auch solcher Code kann Rechenzeit auf dem Main Thread beanspruchen.

Das bedeutet nicht, dass jeder externe Dienst entfernt werden muss. Sein Nutzen sollte aber gegen den technischen Aufwand und mögliche Performance-Auswirkungen abgewogen werden.

CLS – Cumulative Layout Shift #

Cumulative Layout Shift misst unerwartete Verschiebungen sichtbarer Seitenelemente.

Ein guter CLS liegt bei:

0,1 oder weniger

Anders als LCP und INP wird CLS nicht in Sekunden oder Millisekunden angegeben.

Es handelt sich um einen dimensionslosen Wert, der die Auswirkungen unerwarteter Layoutverschiebungen beschreibt.

Wie fühlt sich ein schlechter CLS an? #

Ein typisches Beispiel:

Du möchtest auf einen Button klicken. Kurz vor dem Klick erscheint oberhalb ein weiteres Element. Der Button springt nach unten und du klickst versehentlich auf etwas anderes.

VORHER

[ Kaufen ]

Du willst klicken ...

      ↓

Bild wird nachgeladen

      ↓

NACHHER

[ neues Bild ]

[ Kaufen ]

Button ist plötzlich verschoben

Solche unerwarteten Bewegungen können sehr störend sein.

Nicht jede Layoutverschiebung ist schlecht #

Layoutänderungen können auch vom Benutzer erwartet und bewusst ausgelöst werden.

Wenn du beispielsweise ein Menü öffnest oder einen Akkordeon-Bereich aufklappst, darf sich die Oberfläche entsprechend verändern.

Problematisch sind vor allem unerwartete Verschiebungen, die ohne eine entsprechende Erwartung des Benutzers auftreten.

Was kann einen schlechten CLS verursachen? #

Le cause tipiche possono essere:

• Bilder ohne reservierten Platz,
• Werbe- oder Bannerflächen ohne feste Dimensionen,
• nachträglich eingefügte Inhalte,
• Cookie- oder Hinweis-Elemente, die Inhalt verschieben,
• bestimmte Webfont-Effekte,
• dynamische Widgets.

Bilder ohne Abmessungen und CLS #

Wenn der Browser vor dem Laden eines Bildes nicht weiß, wie viel Platz benötigt wird, kann sich das Layout verändern, sobald das Bild erscheint.

Bei einem HTML-Bild können beispielsweise geeignete Angaben für width e height dabei helfen, das Seitenverhältnis beziehungsweise den erforderlichen Platz bereits vorher zu berücksichtigen.

<img
  src="beispiel.webp"
  width="1200"
  height="800"
  alt="Immagine di esempio"
>

Moderne CMS übernehmen solche Angaben häufig automatisch. Bei einem auffälligen CLS lohnt sich trotzdem die Kontrolle.

Webfonts und Layoutverschiebungen #

Auch Schriftarten können die Darstellung beeinflussen.

Wenn zunächst eine Ersatzschrift dargestellt und später durch eine Webfont ersetzt wird, können sich Zeichenbreiten und Zeilenumbrüche verändern.

Dadurch kann sich auch das Layout verschieben.

Ob dies tatsächlich ein relevantes CLS-Problem verursacht, sollte gemessen und nicht nur vermutet werden.

Cookie-Banner und CLS #

Ein Cookie-Banner kann ebenfalls Layoutverschiebungen verursachen, wenn es nachträglich in den normalen Seitenfluss eingefügt wird und vorhandene Inhalte verschiebt.

Ein Overlay, das über dem bestehenden Inhalt erscheint, verhält sich technisch anders als ein Element, das nachträglich Platz innerhalb des Layouts beansprucht.

Bei auffälligen CLS-Werten solltest du deshalb auch Consent- und Hinweis-Systeme untersuchen.

Dynamische Inhalte und CLS #

Nachgeladene Inhalte können problematisch sein, wenn für sie vorher kein entsprechender Platz vorgesehen wurde.

Esempi:

Werbebanner
Empfehlungsboxen
Social-Media-Feeds
Bewertungen
externe Widgets
personalisierte Inhalte

Wenn solche Elemente Inhalte nach unten oder zur Seite verschieben, können sie zum CLS beitragen.

Wie wird CLS berechnet? #

CLS basiert nicht einfach auf der Anzahl der Bewegungen.

Für eine Layoutverschiebung werden unter anderem berücksichtigt, wie viel des sichtbaren Bereichs von instabilen Elementen betroffen ist und wie weit sich diese Elemente bewegen.

Die einzelnen relevanten Layoutverschiebungen werden innerhalb definierter Sitzungsfenster bewertet.

Für die praktische Website-Optimierung musst du die Formel normalerweise nicht selbst berechnen. Wichtiger ist, die verursachenden Elemente zu identifizieren.

LCP, INP und CLS messen unterschiedliche Probleme #

Eine Website kann beispielsweise folgende Werte besitzen:

LCP: 1,9 s
→ gut

INP: 180 ms
→ gut

CLS: 0,32
→ schlecht

Die Seite lädt in diesem Beispiel schnell und reagiert gut auf Interaktionen, besitzt aber erhebliche visuelle Verschiebungen.

Eine pauschale Aussage wie „Die Website ist schnell“ würde das eigentliche Problem nicht erfassen.

Ein weiteres Beispiel #

LCP: 4,4 s
→ schlecht

INP: 120 ms
→ gut

CLS: 0,04
→ gut

Hier reagiert die Website gut und bleibt visuell stabil. Der Hauptinhalt erscheint aber zu spät.

Die Optimierung sollte deshalb zunächst auf den LCP beziehungsweise dessen Ursache ausgerichtet werden.

Felddaten und Labordaten unterscheiden #

Für die Core Web Vitals ist die Unterscheidung zwischen realen Felddaten und synthetischen Labordaten besonders wichtig.

Felddaten zeigen die tatsächlichen Erfahrungen realer Nutzer.

Labordaten werden unter kontrollierten Testbedingungen erzeugt und eignen sich besonders für die technische Diagnose.

Spieghiamo le differenze in dettaglio su Misurare e valutare correttamente il tempo di caricamento del sito web.

Warum unterscheiden sich meine realen und getesteten Werte? #

Reale Besucher verwenden unterschiedliche Geräte, Netzwerkverbindungen und Browserbedingungen.

Ein Labortest arbeitet dagegen mit festgelegten beziehungsweise simulierten Bedingungen.

Deshalb können beispielsweise folgende Ergebnisse gleichzeitig auftreten:

Labortest:
LCP auffällig

reale Felddaten:
LCP gut

o viceversa.

Beide Ergebnisse können korrekt sein, weil sie unterschiedliche Daten betrachten.

Wo finde ich reale Core-Web-Vitals-Daten? #

Reale Nutzungsdaten können unter anderem in Google PageSpeed Insights angezeigt werden, sofern genügend Daten für die betreffende URL beziehungsweise den Ursprung vorhanden sind.

Auch Google Search Console stellt einen Bericht zu den Core Web Vitals bereit.

Die Einrichtung der Search Console behandeln wir unter Configurare Google Search Console e verificare il sito web.

Warum fehlen Core-Web-Vitals-Daten manchmal? #

Für Felddaten muss eine ausreichende Datenbasis vorhanden sein.

Neue oder wenig besuchte Websites beziehungsweise einzelne URLs können deshalb unter Umständen keine eigenen ausreichenden Felddaten besitzen.

Das ist kein Performance-Fehler.

Importante: Fehlende Felddaten bedeuten nicht, dass deine Core Web Vitals schlecht sind. Es kann schlicht nicht genügend geeignete Messdaten geben.

URL-Daten und Origin-Daten #

Performance-Werkzeuge können je nach Verfügbarkeit Daten für eine einzelne URL oder aggregierte Daten für einen gesamten Ursprung anzeigen.

Das sollte bei der Interpretation berücksichtigt werden.

URL
→ konkrete Seite

Origin
→ zusammengefasste Daten
  derselben Website-Herkunft

Ein guter Origin-Wert garantiert deshalb nicht automatisch, dass jede einzelne Seite identisch funktioniert.

Core Web Vitals und mobile Geräte #

Mobile Nutzer können andere Performance-Erfahrungen haben als Desktop-Nutzer.

Unterschiede entstehen beispielsweise durch:

Rechenleistung
Netzwerkverbindung
Displaygröße
Seitenlayout
geladene Ressourcen
Benutzerinteraktionen

Deshalb solltest du Performance-Probleme nicht ausschließlich auf einem leistungsfähigen Desktop-Rechner beurteilen.

Core Web Vitals und SEO #

Die Core Web Vitals sind Teil der technischen Signale rund um die Nutzererfahrung einer Seite.

Sie sollten jedoch nicht als isolierter „Google-Ranking-Score“ betrachtet werden.

Ein guter LCP, INP und CLS garantiert keine bestimmte Position in den Suchergebnissen.

Umgekehrt solltest du schlechte Werte nicht ignorieren, nur weil eine Seite momentan gut rankt.

Eine schnelle, reaktionsfähige und stabile Website ist vor allem für deine Besucher sinnvoll.

Von 90 auf 100 ist nicht automatisch die wichtigste Optimierung #

Die Core Web Vitals besitzen klar definierte gute Bereiche. Das bedeutet nicht, dass du anschließend jede weitere Millisekunde um jeden Preis entfernen musst.

Wenn eine Website bereits eine gute Nutzererfahrung bietet, kann es sinnvoller sein, größere Probleme an anderer Stelle zu lösen.

Per esempio:

LCP 2,4 s → gut

aber:

Checkout funktioniert auf Mobilgeräten nicht

→ Checkout-Problem hat eindeutig höhere Priorität

Core Web Vitals nicht isoliert optimieren #

Technische Performance-Maßnahmen können Nebenwirkungen besitzen.

Wenn du beispielsweise JavaScript aggressiv verzögerst, nur um einen Messwert zu verbessern, können Navigation, Formulare oder andere Funktionen beeinträchtigt werden.

Dasselbe gilt für übermäßige Bildkompression oder unpassendes Lazy Loading.

Regola fondamentale: Eine Performance-Optimierung ist nur dann eine Verbesserung, wenn die Website danach nicht nur bessere Messwerte besitzt, sondern weiterhin korrekt und angenehm funktioniert.

Core Web Vitals systematisch optimieren #

Statt wahllos Optimierungsmaßnahmen umzusetzen, solltest du zuerst feststellen, welcher Messwert tatsächlich problematisch ist.

Core Web Vitals prüfen
        ↓
Welcher Wert ist schlecht?
        ↓
LCP?
INP?
CLS?
        ↓
konkrete Ursache identifizieren
        ↓
gezielte Änderung
        ↓
Website testen
        ↓
erneut messen

Wenn LCP schlecht ist #

Beginne mit folgenden Fragen:

Welches Element ist das LCP-Element?

Wann wird es entdeckt?

Wie groß ist die Ressource?

Ist das Bild passend dimensioniert?

Wird es unnötig lazy geladen?

Blockieren andere Ressourcen die Darstellung?

Wie schnell wird das HTML bereitgestellt?

Danach kannst du wesentlich gezielter optimieren.

Wenn INP schlecht ist #

Beginne mit:

Welche Interaktion ist langsam?

Was passiert nach dem Klick oder Tastendruck?

Welche JavaScript-Aufgaben laufen?

Ist der Main Thread lange blockiert?

Sind Drittanbieter-Scripts beteiligt?

Werden große DOM- oder Layout-Änderungen ausgelöst?

Das Ziel ist nicht einfach „weniger JavaScript“, sondern weniger unnötige beziehungsweise ungünstig geplante Arbeit während wichtiger Interaktionen.

Wenn CLS schlecht ist #

Untersuche:

Welches Element verschiebt sich?

Was löst die Verschiebung aus?

Sind Bildabmessungen bekannt?

Wird Inhalt nachträglich eingefügt?

Verändert eine Webfont das Layout?

Verschiebt ein Banner bestehende Inhalte?

Sind externe Widgets beteiligt?

Behebe anschließend die konkrete Ursache der unerwarteten Verschiebung.

Mehrere Probleme können dieselbe Ursache haben #

Performance-Probleme sind nicht immer sauber voneinander getrennt.

Ein komplexes JavaScript-Widget kann beispielsweise Ressourcen nachladen, den Main Thread belasten und gleichzeitig Inhalte in das Layout einfügen.

Dadurch können mehrere Messwerte beeinflusst werden.

Eine saubere Ursachenanalyse ist deshalb wichtiger als das isolierte „Optimieren einer Zahl“.

Nach Änderungen erneut messen #

Wenn du eine konkrete Ursache behoben hast, solltest du erneut testen.

Für unmittelbare technische Veränderungen eignen sich Labortests gut.

Reale Felddaten verändern sich dagegen nicht sofort, weil sie über einen längeren Zeitraum gesammelt und ausgewertet werden.

Erwarte deshalb nicht, dass eine heute vorgenommene Optimierung unmittelbar sämtliche Felddaten verändert.

Häufige Fehler bei Core Web Vitals #

LCP mit vollständiger Ladezeit gleichsetzen

INP mit TBT gleichsetzen

CLS in Sekunden interpretieren

nur den Performance-Score betrachten

nur Desktop testen

fehlende Felddaten als schlechte Werte interpretieren

jedes Bild pauschal lazy laden

JavaScript blind deaktivieren

jede Layoutänderung als CLS-Problem betrachten

gute Core Web Vitals mit guten Rankings gleichsetzen

mehrere Optimierungen gleichzeitig durchführen

nach Änderungen sofort neue Felddaten erwarten

Praktische Diagnose-Matrix #

Problema	Erste Untersuchung
LCP schlecht	LCP-Element und dessen Ladeweg identifizieren
INP schlecht	langsame Interaktionen und Main-Thread-Arbeit untersuchen
CLS schlecht	verschobene Elemente und Auslöser identifizieren

Checkliste für Core Web Vitals #

Felddaten vorhanden?
        ↓
URL- oder Origin-Daten?
        ↓
75. Perzentil betrachten
        ↓
LCP ≤ 2,5 s?
        ↓
INP ≤ 200 ms?
        ↓
CLS ≤ 0,1?
        ↓
problematischen Messwert bestimmen
        ↓
verursachendes Element / Interaktion finden
        ↓
technische Ursache untersuchen
        ↓
gezielte Änderung durchführen
        ↓
Website funktional testen
        ↓
Labortest wiederholen
        ↓
Entwicklung der Felddaten beobachten

Riepilogo #

Die Core Web Vitals betrachten drei unterschiedliche Aspekte der Nutzererfahrung einer Website.

LCP misst das Ladeerlebnis eines wichtigen großen Inhalts und gilt bei einem Wert von höchstens 2,5 Sekunden als gut.

INP bewertet die Reaktionsfähigkeit auf Benutzerinteraktionen. Ein Wert von höchstens 200 Millisekunden gilt als gut.

CLS bewertet unerwartete Layoutverschiebungen. Ein Wert von höchstens 0,1 gilt als gut.

Für die Bewertung realer Nutzungsdaten ist das 75. Perzentil entscheidend. Dadurch werden nicht nur besonders schnelle Einzelaufrufe berücksichtigt.

Bei schlechten Werten solltest du nicht sofort allgemeine Performance-Einstellungen verändern. Identifiziere zuerst beim LCP das betroffene Element, beim INP die langsame Interaktion und beim CLS die unerwartete Layoutverschiebung.

Core Web Vitals sind am hilfreichsten, wenn du sie nicht als drei Zahlen betrachtest, die möglichst grün werden sollen, sondern als Hinweise darauf, welches konkrete Erlebnis deiner Besucher verbessert werden kann.