Core Web Vitals optimieren: Was du 2026 wissen musst

Wenn deine Website bei Google schlechter rankt, obwohl die Inhalte stark sind, liegt es oft an den Core Web Vitals. Das sind drei technische Metriken, mit denen Google misst, wie gut sich deine Seite für echte Nutzer anfühlt. Seit März 2024 ist INP (Interaction to Next Paint) offiziell eine davon und hat FID (First Input Delay) abgelöst. Das hat viele Seiten überrascht, die vorher grün waren und plötzlich rot standen.

Die gute Nachricht: Die meisten Probleme sind mit überschaubarem Aufwand lösbar. Die schlechte Nachricht: Die häufigsten Quick-Fixes aus alten Blogartikeln sind inzwischen veraltet oder greifen zu kurz.

Was Core Web Vitals 2026 konkret sind

Google misst drei Kennzahlen und vergibt pro Metrik ein Ampel-Urteil: grün, gelb, rot. Damit eine Seite offiziell als “gut” zählt, müssen mindestens 75 Prozent der realen Seitenaufrufe in den grünen Bereich fallen. Das kommt aus echten Chrome-Nutzungsdaten, nicht aus Lighthouse-Tests im Labor.

LCP (Largest Contentful Paint). Wann ist das größte sichtbare Element, meist das Hero-Bild oder die H1, geladen? Grün unter 2,5 Sekunden, gelb bis 4 Sekunden, darüber rot.

INP (Interaction to Next Paint). Wie lange dauert es, bis die Seite nach einem Klick oder Tipp sichtbar reagiert? Grün unter 200 Millisekunden, gelb bis 500, darüber rot. INP ersetzt seit März 2024 FID und ist deutlich strenger, weil es alle Interaktionen während des Besuchs misst, nicht nur die erste.

CLS (Cumulative Layout Shift). Springen Inhalte beim Laden ungewollt herum? Grün unter 0,1, gelb bis 0,25, darüber rot. Gemessen wird die größte Verschiebungssession, nicht mehr die kumulierte Gesamtsumme wie noch 2019.

Warum INP der kritische Punkt ist

Seit dem Wechsel von FID zu INP fallen viele Seiten auf Rot, die vorher problemlos durchkamen. Der Grund liegt in der Messlogik.

FID hat nur gemessen, wie lange der Browser für die erste Interaktion des Nutzers gebraucht hat. War die Seite einmal geladen, wurde nichts mehr erfasst. INP misst dagegen alle Interaktionen während des gesamten Besuchs und nimmt praktisch den 98. Perzentilwert. Das bedeutet: Ein einzelner langsamer Klick in der Navigation kann den gesamten INP-Wert kippen.

Typische Verursacher, die wir in Projekten regelmäßig sehen:

• Zu viel JavaScript auf der Hauptseite. Jedes Tracking-Tool, jede Chat-Integration, jedes Banner aus dem Tag-Manager blockt den Main-Thread. Wer 15 Scripts eingebunden hat, bekommt INP-Probleme.
• Komplexe Event-Listener. Klicks auf Buttons, die erst einen API-Call machen und dann das DOM umbauen, dauern oft länger als 200 Millisekunden, besonders auf Mobilgeräten.
• Third-Party-Widgets. Chatbots, Video-Player, Social-Media-Embeds. Sobald Nutzer damit interagieren, laufen fremde Skripte, auf die du keinen Einfluss hast.

Die meisten Seiten haben keine LCP- oder CLS-Probleme mehr. INP ist aktuell der Punkt, an dem Rankings wackeln.

Woher du weißt, wie deine Seite wirklich steht

Hier kommt der häufigste Fehler: Leute testen in PageSpeed Insights mit Lighthouse und denken, alles sei grün. Lighthouse ist ein Labor-Test in einer standardisierten Umgebung, misst keinen INP und sagt wenig über die Realität aus.

Was du stattdessen brauchst, sind Felddaten. Es gibt zwei Quellen, die du kennen solltest.

Google Search Console → Core Web Vitals-Bericht. Zeigt dir, welche URLs deiner Domain schlecht, mittel oder gut abschneiden. Direkt aus dem Chrome User Experience Report (CrUX). Wenn hier URLs rot sind, sieht Google sie tatsächlich so.

CrUX Dashboard oder CrUX Vis. Liefert die gleichen Daten detaillierter und rückwirkend für 28 Tage. Sinnvoll, wenn du nach Optimierungen prüfen willst, ob sich etwas verändert hat.

Lighthouse ist nützlich, um im Entwicklungsprozess grobe Probleme zu finden. Aber für die Frage, wie Google deine Seite bewertet, sind die Felddaten maßgeblich.

Was wirklich hilft, nach Priorität geordnet

Statt einer Liste mit 30 Punkten, hier die Hebel nach tatsächlichem Impact aus unserer Projekterfahrung.

1. Bilder und Hero-Sektion optimieren (LCP)

Das Hero-Bild ist in der Regel das LCP-Element. Drei Stellschrauben:

• Modernes Format (WebP oder AVIF) statt JPEG. Reduziert Dateigröße bei gleicher Qualität um 25 bis 50 Prozent.
• Korrekte Bildgrößen über srcset und sizes, damit mobile Geräte nicht das Desktop-Bild in 2400 Pixel Breite laden.
• Fetchpriority=“high” auf das Hero-Bild setzen, damit der Browser es priorisiert.

Lazy-Loading auf dem Hero-Bild ist ein häufiger Fehler. Das Element sollte so früh wie möglich geladen werden, nicht so spät wie möglich.

2. JavaScript reduzieren (INP)

Das ist der aufwändigste, aber wichtigste Punkt. Praktische Schritte:

• Tag Manager auditieren. Welche Tags sind wirklich notwendig? In 90 Prozent der Fälle laufen dort Skripte mit, die seit Monaten niemand mehr nutzt.
• Third-Party-Scripts mit async oder defer laden, nicht synchron. Für Tracking und Analytics reicht in fast allen Fällen defer.
• Große Libraries prüfen. Eine jQuery-Version, die nur wegen eines Slider-Plugins drin ist, lässt sich oft durch 30 Zeilen Vanilla-JavaScript ersetzen.

Bei React/Vue-Anwendungen hilft Code-Splitting und das Entfernen unnötiger Re-Renders deutlich.

3. Layout-Shifts verhindern (CLS)

Die klassischen Probleme:

• Bilder ohne Breiten- und Höhenangabe. Immer width und height setzen, damit der Browser Platz reserviert, bevor das Bild lädt.
• Webfonts, die beim Laden das Layout verschieben. Lösung: font-display: optional oder swap mit passend gewählten Fallback-Fonts.
• Nachgeladene Banner oder Cookie-Hinweise. Diese Elemente oberhalb einer festen Höhe platzieren oder als Overlay über dem Inhalt, nicht dazwischen.

4. Server und Caching

• CDN einsetzen. Wenn deine Kunden in Deutschland sitzen und dein Server in Irland, verlierst du 50 bis 100 Millisekunden alleine durch die Netzwerkdistanz.
• HTTP/2 oder HTTP/3 nutzen.
• HTML-Caching für statische Seiten über Edge Caching (Cloudflare, Vercel, Netlify).

Was nicht mehr hilft

Ein paar Tipps aus Blogartikeln, die regelmäßig verschenkte Arbeit verursachen.

Alle Bilder auf maximale Kompression setzen. Klingt logisch, bringt aber kaum etwas, wenn dein echtes Problem ein 400 KB großes Hero-Bild ist, das in AVIF nur 80 KB bräuchte.

Preload für alles Mögliche verwenden. Preload ist ein scharfes Werkzeug. Zu viele Preload-Hints konkurrieren miteinander und verschlechtern oft das, was sie verbessern sollten.

Lighthouse-Score als Ziel. Ein perfekter Lighthouse-Score in einer leeren Testseite sagt wenig aus. Was zählt, sind die Felddaten in der Search Console.

Ab wann sich ernsthafte Optimierung lohnt

Core Web Vitals sind ein Rankingfaktor, aber kein übermäßig starker. Google hat das mehrfach bestätigt: Inhalte schlagen Performance. Aber bei vergleichbarem Inhalt entscheiden sie oft das Rennen.

Unsere Einschätzung aus Projektarbeit: Wer bei keinem der drei Werte im roten Bereich liegt, hat das Wichtigste erledigt. Der Sprung von Gelb nach Grün bringt SEO-seitig selten den riesigen Effekt. Wer allerdings auf Rot steht und beispielsweise INP-Werte über 500 Millisekunden hat, verliert sichtbar Rankings und Conversion, weil die Seite sich für Nutzer tatsächlich träge anfühlt.

Wer das Thema sauber angehen will, braucht einen Entwickler, der Felddaten interpretieren und gezielt eingreifen kann. Wilde Blog-Tipps in die Seite einzubauen führt meistens zu neuen Problemen. Wenn du unsicher bist, wo bei deiner Seite der Hebel liegt, meld dich. Mehr Kontext zum Thema findest du auch auf unseren Seiten zu SEO & Marketing und Webdesign & Entwicklung. Eine kurze Fokus-Session reicht meistens, um die kritischen Baustellen zu identifizieren.