Core Web Vitals 2026: Was LCP, INP und CLS wirklich beeinflusst

Die meisten Teams behandeln Core Web Vitals immer noch als Lighthouse-Zahl, der man hinterherjagt, statt als Architektur, die es zu reparieren gilt. Deshalb kann eine Website in PageSpeed Insights 95 Punkte erreichen und trotzdem bei der Core-Web-Vitals-Bewertung in der Google Search Console durchfallen. Diese beiden Zahlen messen unterschiedliche Dinge – und nur eine davon wirkt sich auf Rankings und echte Nutzer aus.

Plugin-Tipps sparen wir uns. Wenn deine Lösung für ein Performance-Problem „installiere ein Caching-Plugin“ lautet, behandelst du ein Symptom, nicht die Ursache. Hier ist, was jede Metrik tatsächlich bewegt – und warum Lab- und Field-Daten oft genug auseinanderlaufen, dass man keinem von beiden allein vertrauen kann.

LCP ist ein Critical-Path-Problem, kein Bildproblem

Largest Contentful Paint misst, wann das größte sichtbare Element – meist ein Hero-Image, eine Überschrift oder ein Banner – fertig gerendert ist. Teams greifen standardmäßig zu „Bild komprimieren“, was hilft, aber ab einem gewissen Punkt selten der Flaschenhals ist.

Der eigentliche Critical Path sieht so aus:

1. Time to First Byte. Wenn dein Server oder Origin mehrere hundert Millisekunden braucht, bevor der Browser überhaupt etwas zum Arbeiten hat, rettet dich keine noch so starke Bildkomprimierung. Edge Rendering, regionale Read-Replicas und das Verlagern TTFB-sensibler Routen auf die Compute-Layer eines CDNs (Cloudflare Workers, Vercel Edge, Lambda@Edge) können diese Zeit spürbar senken – wie stark, hängt maßgeblich von Stack, Region und Ausgangswert ab.
2. Render-blockierendes CSS und JS. Jedes Stylesheet und jedes synchrone Skript, das der Browser parsen muss, bevor er malen kann, verschiebt LCP nach hinten. Kritisches CSS für Above-the-Fold-Inhalte inline einbetten und den Rest verzögert laden.
3. Auffindbarkeit von Ressourcen. Der Preload-Scanner des Browsers muss dein LCP-Bild früh finden. Wird es per JavaScript injiziert, aus einem CSS-background-image geladen oder hinter einem clientseitigen Datenabruf versteckt, verzögerst du die Entdeckung um Hunderte Millisekunden. Nutze fetchpriority="high" direkt am <img>-Tag sowie ein <link rel="preload"> dafür.
4. Font-Loading. Ist dein LCP-Element Text und lädst du eine Webfont ohne Fallback-Strategie, fügst du einen kompletten Roundtrip ein, bevor dieser Text gemalt werden kann. font-display: swap und Preloading lösen jeweils eine andere Hälfte des Problems: swap zeichnet sofort eine Fallback-Schrift, sodass der Roundtrip LCP nicht blockiert (kann beim Einwechseln der echten Schrift aber einen sichtbaren Reflow – und damit einen CLS-Treffer – verursachen), während das Preloading der Font-Datei selbst den Abruf verkürzt, sodass der Swap früher passiert. Beides zusammen einsetzen, nicht das eine statt des anderen.

Nichts davon ist eine Plugin-Einstellung. Es geht um Routing, Markup-Reihenfolge und Resource Hints – Entscheidungen, die in deiner Build-Pipeline und in deinem HTML getroffen werden, nicht im WordPress-Dashboard.

INP zeigt, wenn deine JavaScript-Architektur nicht skaliert

Interaction to Next Paint hat First Input Delay im März 2024 als Core Web Vital abgelöst und lässt sich schwerer austricksen, weil die Metrik jede Interaktion während eines Seitenbesuchs erfasst, nicht nur die erste. Eine Website kann einen schnellen ersten Klick haben und trotzdem an INP scheitern, weil eine spätere Interaktion – nachdem genug Komponenten gemountet und genug State angesammelt wurde – so lange zum Reagieren braucht, dass sie den p75-Wert nach unten zieht, selbst wenn sich der erste Klick sofort angefühlt hat.

INP wird von Konkurrenz um den Main Thread dominiert. Der Browser kann nicht auf einen Tap oder Tastendruck reagieren, solange er mit dem Ausführen von JavaScript beschäftigt ist. Die üblichen Ursachen:

• Long Tasks. Alles über 50ms blockiert den Main Thread bei der Verarbeitung von Eingaben. Große State-Updates, unoptimierte Re-Renders und synchrone Third-Party-Skripte (Chat-Widgets, Analytics-Tags, Ad Exchanges) sind die häufigsten Übeltäter.
• Hydration-Kosten. Client-lastige Frameworks, die beim Laden die gesamte Seite hydrieren – statt progressiv oder selektiv –, blockieren den Main Thread genau dann, wenn Nutzer anfangen zu interagieren. Islands-Architektur (Astros selektive Hydration isolierter Komponenten) und Resumability (Qwiks Ansatz, der den Ausführungszustand serialisiert und fortsetzt, ohne die Komponentenlogik überhaupt erneut auszuführen) sind zwei unterschiedliche Techniken, die beide auf dieses Problem zielen – neben React Server Components. Wer für eine Marketing-Site eine vollständig clientseitig gerenderte SPA betreibt, sieht das Problem meist zuerst bei INP.
• Ungebündelte Event-Handler. Eine einzelne Eingabe, die mehrere synchrone Re-Renders, Layout-Neuberechnungen oder API-Aufrufe auslöst, summiert sich schnell. Debouncing, requestIdleCallback für nicht dringende Arbeit und das Auslagern rechenintensiver Aufgaben auf Web Workers helfen alle dabei.
• Menge an Third-Party-Skripten. Tag-Manager, die ein Dutzend nachgelagerte Skripte laden, sind einer der größten INP-Killer, weil du deren Ausführungskosten nicht kontrollierst – nur, ob und wann sie überhaupt geladen werden.

Code Splitting und routenbasiertes Lazy Loading reduzieren die insgesamt ausgelieferte JS-Menge, aber INP honoriert speziell einen freien Main Thread während der Interaktionsfenster – das ist ebenso sehr ein Scheduling-Problem wie ein Problem der Bundle-Größe.

CLS bleibt vor allem eine Disziplinfrage

Cumulative Layout Shift ist von den dreien am leichtesten zu beheben und hat als einzige Metrik nichts mit der Server-Infrastruktur zu tun. Verursacht wird sie durch:

• Bilder und Embeds ohne explizite width/height-Angaben oder ohne per CSS reservierte aspect-ratio.
• Webfonts, die eine metrisch abweichende Fallback-Schrift einwechseln und dadurch den Textfluss verschieben – abmildern lässt sich das mit size-adjust in einem @font-face-Block, abgestimmt auf deine Fallback-Schrift.
• Ads, Cookie-Banner und dynamisch nachgeladene Inhalte, die bestehenden Content nach unten schieben, nachdem das initiale Layout bereits gemalt wurde.
• Inhalte, die oberhalb bestehenden Contents eingefügt werden (ein häufiger CMS-/Personalisierungsfehler – ein Banner, das nach dem Laden der Seite oben eingeschoben wird).

Ein CLS-Wert unter 0.1 ist auf praktisch jedem Stack erreichbar, sobald jedes dynamische Element reservierten Platz hat. Für ein fehlendes width-Attribut gibt es keine Infrastruktur-Lösung.

Warum Lab-Werte und Field-Daten auseinanderlaufen

Das ist der Teil, den die meisten Reports auslassen. Die „Lab“-Daten von Lighthouse und PageSpeed Insights basieren auf einem einzigen Seitenaufruf auf einem simulierten Mittelklasse-Gerät über eine gedrosselte Verbindung, mit leerem Cache und ohne die Streuung echter Nutzer. Das macht sie reproduzierbar und damit nützlich für Regressionstests – aber es bleibt eine synthetische Momentaufnahme.

Field-Daten – das, was im Core-Web-Vitals-Bericht der Search Console und im Chrome UX Report (CrUX) auftaucht – sind ein rollierender 28-Tage-Durchschnitt am 75. Perzentil, erhoben von echten Chrome-Nutzern auf echten Geräten, echten Netzwerken und mit echtem Cache-Zustand. Das ist es, was Google tatsächlich als Ranking-Signal nutzt.

Die Lücke zeigt sich auf vorhersehbare Weise:

• Geräte-Mix. Dein Lab-Test läuft auf einem fest simulierten Gerät. Deine Field-Daten enthalten reale Low-End-Android-Geräte über 4G, die immer schlechtere INP-Werte zeigen als ein synthetisches Mittelklasse-Profil.
• Variabilität durch Drittanbieter. A/B-Tests, Consent-Management-Plattformen und Ad-Tags feuern bei einem Lab-Crawl (der möglicherweise keine Cookies akzeptiert, keine Geolokalisierung auslöst oder keine regionalen Ad-Netzwerke lädt) oft anders als bei echtem Traffic.
• Cache-Zustand. Lab-Tests laufen häufig mit kaltem Cache. Echte Nutzer treffen bei wiederholten Besuchen auf deinen CDN-Cache, bereits geladene Schriften und zuvor geladene Ressourcen, weshalb Field-Tools mitunter bessere Werte zeigen als Lab-Tests – das Gegenteil des üblichen Musters.
• Stichprobengröße und Perzentil. Ein Lab-Durchlauf ist ein einzelner Datenpunkt. Field-Daten am p75 bedeuten, dass ein Viertel deiner echten Besuche schlechter abschneidet als der angezeigte Wert – genau der Tail, den plugin-basierte „Schnelllösungen“ nie erreichen.

Behandle Lab-Daten als Regressions-Gate in der CI, nicht als Stellvertreter für deinen tatsächlichen Score. Behandle Field-Daten als die Wahrheit, für die du geradestehst, und diagnostiziere sie mit Real-User-Monitoring, nicht mit wiederholten Lighthouse-Läufen.

Was wirklich Priorität hat

Bei der Priorisierung gilt: zuerst CLS beheben (am günstigsten, höchste Erfolgssicherheit), dann LCP (Infrastruktur- und Markup-Änderungen mit klaren Vorher-Nachher-Zahlen), und INP als dauerhaftes Architekturthema behandeln statt als einmalige Reparatur – der Wert verschlechtert sich erneut, sobald ein neues Third-Party-Skript oder ein schwererer Component-Tree ausgeliefert wird.

Das ist auch der Grund, warum Core-Web-Vitals-Arbeit zu den Leuten gehört, die deinen Code schreiben und ausliefern – nicht auf eine Marketing-Checkliste. Unser Team für technisches SEO behandelt Performance als Engineering-Problem mit einem Ranking-Nebeneffekt, nicht umgekehrt – denn genau in dieser Reihenfolge funktioniert es tatsächlich.

Fazit: Lab-Werte zeigen dir, ob du seit gestern etwas kaputtgemacht hast. Field-Daten zeigen dir, was deine Nutzer und Google tatsächlich erlebt haben. Wenn diese beiden Zahlen auseinandergehen, glaube den Field-Daten – und repariere die Architektur, nicht die Plugin-Einstellungen.