Core Web Vitals & PageSpeed: Warum langsame Seiten Kunden & Rankings kosten

Core Web Vitals sind drei von Google definierte Kennzahlen für die Nutzererfahrung einer Webseite: Largest Contentful Paint (LCP) für die Ladeleistung, Interaction to Next Paint (INP) für die Interaktivität und Cumulative Layout Shift (CLS) für die visuelle Stabilität. Sie fließen als Page-Experience-Signal in das Google-Ranking ein. Stand 2026.

Was sind Core Web Vitals – und welche drei Metriken zählen 2026?

Die drei aktuellen Core Web Vitals sind Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS). Sie messen laut web.dev (Google) die Ladeleistung, die Interaktivität und die visuelle Stabilität einer Seite. Damit decken sie die drei Momente ab, an denen Nutzer eine Seite als schnell oder zäh erleben: das Laden, das Reagieren auf Klicks und das Stillhalten des Layouts.

Eine wichtige Änderung: INP wurde am 12. März 2024 offiziell ein Core Web Vital und ersetzte First Input Delay (FID), wie web.dev (Google) bestätigt. FID ist damit kein Core Web Vital mehr. Wer noch auf FID optimiert, misst die falsche Kennzahl.

Welche Schwellenwerte gelten als „gut", „verbesserungswürdig" und „schlecht"?

Google legt für jeden Core Web Vital feste Grenzen fest, gemessen am 75. Perzentil aller Seitenaufrufe. Das bedeutet: Erst wenn 3 von 4 Besuchen das Zielniveau erreichen, gilt eine Seite als „gut". Wichtig: Die Schwellenwerte selbst sind laut web.dev (Google, 2020) für Mobile und Desktop identisch – getrennt erhoben wird nur die 75.-Perzentil-Messung je Gerätetyp, nicht die Grenze selbst.

Metrik	Gut	Schlecht	Messpunkt
LCP (Ladeleistung)	≤ 2,5 s	> 4 s	75. Perzentil
INP (Interaktivität)	≤ 200 ms	> 500 ms	75. Perzentil
CLS (Stabilität)	≤ 0,1	> 0,25	75. Perzentil

Werte zwischen „gut" und „schlecht" gelten als „verbesserungswürdig". Diese Schwellen sind keine Willkür: Google bestätigt die 2,5-s-/4-s-Grenze für LCP und die 0,1-/0,25-Grenze für CLS in web.dev (2020) ausdrücklich als begründete Grenzen, die ein gutes Nutzererlebnis mit realer Erreichbarkeit ausbalancieren.

Was misst Largest Contentful Paint (LCP) – und warum 2,5 Sekunden?

LCP misst, wie lange es dauert, bis das größte sichtbare Element im Viewport gerendert ist – meist ein Hero-Bild oder eine große Überschrift. Laut web.dev (Google) gilt LCP bei ≤ 2,5 Sekunden als „gut" und bei > 4 Sekunden als „schlecht", jeweils am 75. Perzentil.

Die 2,5 Sekunden markieren den Punkt, an dem Nutzer eine Seite noch als zügig geladen wahrnehmen. Verzögert sich das Hauptelement darüber hinaus, wirkt die Seite träge – auch wenn der Rest längst da ist. LCP bildet damit die gefühlte Ladegeschwindigkeit ab, nicht nur den ersten Pixel.

Was bedeutet Interaction to Next Paint (INP) – und worin unterscheidet es sich von FID?

INP misst, wie schnell eine Seite sichtbar auf Eingaben reagiert. Es gilt laut web.dev (Google) bei ≤ 200 Millisekunden als „gut" und bei > 500 Millisekunden als „schlecht" (75. Perzentil). Gemessen wird die Spanne von der Eingabe bis zum nächsten gerenderten Frame.

Der Unterschied zum abgelösten FID ist entscheidend: FID maß nur die Eingabeverzögerung der allerersten Interaktion. INP beobachtet laut web.dev alle Interaktionen einer Seite – von der Eingabeverzögerung über die Event-Handler bis zum nächsten gerenderten Frame. Damit erfasst INP auch ruckelnde Reaktionen tief im Nutzungsverlauf, die FID schlicht ignoriert hat.

Was ist Cumulative Layout Shift (CLS) – und warum springt mein Layout?

CLS misst, wie stark sich das Layout während des Ladens unerwartet verschiebt. Der Wert gilt laut web.dev (Google) bei ≤ 0,1 als „gut" und bei > 0,25 als „schlecht" (75. Perzentil). Anders als LCP und INP ist CLS keine Zeit, sondern eine dimensionslose Verschiebungs-Kennzahl.

Layout-Sprünge entstehen typischerweise durch Bilder ohne reservierten Platz, nachträglich eingeblendete Werbung oder spät geladene Schriften. Der praktische Schaden: Wer auf einen Button klicken will und im selben Moment springt das Layout, landet auf dem falschen Element. CLS bestraft genau diese Frustration.

Beeinflussen Core Web Vitals wirklich das Google-Ranking?

Ja, aber als Teil eines Bündels, nicht als isolierter Einzelfaktor. Google ordnet Core Web Vitals in Google Search Central den Page-Experience-Aspekten zu: „This, along with other page experience aspects, aligns with what our core ranking systems seek to reward." Es ist also ein ranking-relevantes Signal – aber kein einzeln gewichteter Hebel, der eine schwache Seite nach oben katapultiert.

Die ehrliche Einordnung: Gute Core Web Vitals ersetzen keinen guten Inhalt. Bei vergleichbarer Relevanz können sie aber den Ausschlag geben – und schlechte Werte sind ein vermeidbarer Nachteil. Eine technisch sauber gebaute Seite, wie sie professionelles Webdesign liefert, hat diese Basis von Anfang an im Griff.

Kosten langsame Seiten echte Kunden?

Ja, und das lässt sich beziffern. Nach Google/SOASTA-Daten steigt die Absprungwahrscheinlichkeit auf Mobilseiten um 32 %, wenn die Ladezeit von 1 auf 3 Sekunden zunimmt, wie Think with Google / SOASTA (2017) belegt. Bei 1 auf 5 Sekunden sind es +90 %, bei 1 auf 10 Sekunden +123 %.

Übersetzt in den Alltag: Jede Sekunde Ladezeit kostet Reichweite, bevor der Inhalt überhaupt gesehen wird. Wer Budget in Anzeigen oder Content steckt, verschenkt einen Teil davon an eine langsame Seite. Geschwindigkeit ist damit kein technisches Detail, sondern ein Conversion-Faktor.

Lab-Daten vs. Feld-Daten: Was sagt PageSpeed Insights wirklich aus?

PageSpeed Insights kombiniert zwei Datenquellen, die oft verwechselt werden. Die Feld-Daten stammen aus echten Nutzersitzungen: Laut Google for Developers zeigt das Tool Werte für FCP, INP, LCP und CLS aus dem Chrome User Experience Report (CrUX) über die letzten 28 Tage. Diese Feld-Daten sind ranking-relevant.

Die Lab-Daten dagegen kommen aus einer simulierten Lighthouse-Messung unter Standardbedingungen – reproduzierbar, aber nicht das, was reale Nutzer erleben. Der Lighthouse-Performance-Score gilt laut Google ab 90 als gut, 50–89 als verbesserungswürdig und unter 50 als schlecht. Wichtig: Der Lab-Score ist ein Diagnose-Werkzeug, die CrUX-Feld-Daten sind der Maßstab für die Bewertung.

Wie verbessere ich meine Core Web Vitals konkret?

Die wirksamsten Hebel unterscheiden sich je Metrik. web.dev (Google) nennt für jede der drei Kennzahlen konkrete Maßnahmen mit dem größten Effekt.

LCP verbessern: Ladeleistung priorisieren

• Die LCP-Ressource im initialen HTML auffindbar machen (echtes img src statt erst per JavaScript nachladen).
• fetchpriority="high" am LCP-Bild setzen und loading="lazy" dort entfernen.
• Ein CDN nutzen – laut web.dev werden nur 33 % der HTML-Dokumente über ein CDN ausgeliefert.

INP verbessern: Reaktionsfähigkeit erhöhen

• Lange Tasks aufbrechen und häufig „yielden", damit der Hauptthread frei bleibt.
• Unnötiges JavaScript reduzieren – über Code-Splitting und das Entfernen von Dead Code.
• Rendering-Arbeit minimieren, etwa durch Vermeiden von Forced Layouts und Einsatz von CSS-Containment.

CLS verbessern: Layout stabilisieren

• width/height bzw. CSS-Maße für Bilder setzen – laut web.dev haben 66 % der Seiten mindestens ein Bild ohne Maße.
• Den Back/Forward-Cache (bfcache) aktivieren.
• Layout-ändernde Animationen vermeiden und stattdessen CSS transform nutzen.

FAQ: Häufige Fragen zu Core Web Vitals und PageSpeed

Was sind die drei Core Web Vitals 2026?

Die drei Core Web Vitals sind LCP (Ladeleistung), INP (Interaktivität) und CLS (visuelle Stabilität), wie web.dev (Google) definiert. INP ersetzt seit dem 12. März 2024 das frühere First Input Delay (FID).

Welcher LCP-Wert ist gut?

LCP gilt bei ≤ 2,5 Sekunden als „gut" und bei > 4 Sekunden als „schlecht", gemessen am 75. Perzentil aller Seitenaufrufe (Quelle: web.dev, Google).

Ist INP dasselbe wie FID?

Nein. FID maß nur die Verzögerung der ersten Interaktion. INP beobachtet alle Interaktionen einer Seite bis zum nächsten gerenderten Frame und ist seit dem 12. März 2024 der offizielle Core Web Vital (Quelle: web.dev, Google).

Was ist der Unterschied zwischen Lab- und Feld-Daten?

Lab-Daten stammen aus einer simulierten Lighthouse-Messung, Feld-Daten aus echten Nutzersitzungen im Chrome User Experience Report über 28 Tage. Für die Bewertung zählen die Feld-Daten (Quelle: Google for Developers).

Ab welchem PageSpeed-Score ist eine Seite gut?

Der Lighthouse-Performance-Score gilt ab 90 als gut, 50–89 als verbesserungswürdig und unter 50 als schlecht (Quelle: Google for Developers). Dieser Lab-Score ist ein Diagnose-Wert, nicht der Ranking-Maßstab.

Beeinflussen Core Web Vitals das Ranking?

Ja, als Teil der Page-Experience-Signale, aber nicht als isolierter Einzelfaktor. Google bezeichnet sie als Aspekt, der mit dem übereinstimmt, was die Core-Ranking-Systeme belohnen (Quelle: Google Search Central).

Wie wirkt sich Ladezeit auf Absprünge aus?

Steigt die mobile Ladezeit von 1 auf 3 Sekunden, erhöht sich die Absprungwahrscheinlichkeit um 32 % (Quelle: Think with Google / SOASTA, 2017). Bei 1 auf 5 Sekunden sind es +90 %.

Quellen

• web.dev (Google) – Web Vitals (2024)
• web.dev (Google) – How Core Web Vitals thresholds were defined (2020)
• web.dev (Google) – INP becomes a Core Web Vital on March 12 (2024)
• Google Search Central – Understanding Core Web Vitals and Google Search (2024)
• Think with Google / SOASTA Research – Mobile Page Speed Benchmarks (2017)
• Google for Developers – About PageSpeed Insights (2024)
• web.dev (Google) – The most effective ways to improve Core Web Vitals (2024)

Hinweis: Dieser Beitrag bietet allgemeine technische Information und stellt keine verbindliche Performance- oder Ranking-Zusage dar. Schwellenwerte und Bewertungslogik geben den von Google dokumentierten Stand 2026 wieder und können sich ändern. Autor: Alexander Weipprecht. Stand: Juni 2026.