Core Web Vitals verbessern: was 2026 noch Rankings bewegt

Die meisten Anfragen zu diesem Thema fangen mit einem roten Balken in PageSpeed Insights an und der Frage, was der jetzt kostet. Das hängt daran, ob überhaupt Felddaten vorliegen, welche Seitentypen betroffen sind und ob Ihre Inhalte mit den Ergebnissen mithalten, die vor Ihnen stehen.

Was hier steht, ist die Reihenfolge, in der wir das abarbeiten, plus die Stellen, an denen wir bewusst aufhören. Den Erklärteil zu LCP, INP und CLS hat Google selbst geschrieben, gründlicher als eine Agentur ihn nacherzählen kann. Er ist unten verlinkt.

Was Core Web Vitals wirklich entscheiden

Google beschreibt Page Experience nicht als einzelnes Signal. In der Dokumentation von Search Central steht, dass es kein einzelnes Page-Experience-Signal gibt und die Ranking-Systeme auf eine Reihe von Signalen schauen. Core Web Vitals sind eines davon.

Im selben Dokument stehen zwei Sätze, die es selten in Agenturpräsentationen schaffen. Gute Ergebnisse im Core-Web-Vitals-Bericht der Search Console garantieren laut Google keine Spitzenposition. Und der Versuch, allein aus SEO-Gründen einen perfekten Wert zu erreichen, ist nach Googles eigener Formulierung möglicherweise keine gute Verwendung Ihrer Zeit. Auf die Frage nach der Bedeutung von Page Experience fürs Ranking antwortet die Dokumentation, dass die Suche immer die relevantesten Inhalte zeigen will, auch wenn die Page Experience unterdurchschnittlich ausfällt.

Daraus wird eine brauchbare Faustregel. Steht Ihre Seite auf Position 30, liegt das sehr wahrscheinlich nicht am LCP. Stehen Sie auf Position 4 und die drei Ergebnisse davor sind inhaltlich vergleichbar, kann Technik den Ausschlag geben. Dazu kommt der Teil, der ganz ohne Google zählt: langsame Seiten kosten Anfragen, nachrechenbar im eigenen Analytics.

Die drei Werte und was "gut" bedeutet

Seit dem 12. März 2024 ist Interaction to Next Paint (INP) ein stabiler Core Web Vital und hat First Input Delay abgelöst. Chrome hat FID danach entfernt; seit dem 9. September 2024 liefern die Chrome-Werkzeuge keine FID-Daten mehr. Wer noch ein Dashboard mit FID betreibt, misst seit über einem Jahr nichts.

Googles Schwellenwerte für "gut":

Richtwerte 2026

Bewertet wird das 75. Perzentil der Feldwerte über 28 Tage.

Wichtig ist der Zusatz, den die meisten Zusammenfassungen weglassen: gemessen wird am 75. Perzentil der Seitenaufrufe, getrennt nach Mobil und Desktop. Bestanden hat eine Seite erst, wenn sie alle drei Schwellen im 75. Perzentil hält. Ihr eigener Test auf dem MacBook im Büro-WLAN ist damit kein Messwert, sondern ein Datenpunkt aus dem angenehmen Ende der Verteilung.

Feldwerte oder Laborwerte

Felddaten kommen aus dem Chrome User Experience Report (CrUX), also von echten Chrome-Nutzern, aggregiert über 28 Tage. PageSpeed Insights, der Core-Web-Vitals-Bericht der Search Console und die CrUX-API speisen sich alle daraus. Labordaten kommen aus Lighthouse: ein Gerät, ein Netzwerkprofil, ein Durchlauf. Reproduzierbar und deshalb gut zur Fehlersuche, aber eine Simulation.

Lighthouse misst INP nicht. Ohne echte Nutzerinteraktion gibt es keinen INP-Wert. Das ist eine Eigenschaft der Metrik, keine Lücke im Werkzeug. Als Laborersatz dient Total Blocking Time. Ein grüner TBT-Wert bei schlechtem INP ist deshalb kein Widerspruch, sondern der Normalfall.

Viele Seiten haben gar keine Felddaten. CrUX nimmt eine Seite nur auf, wenn sie indexierbar ist und eine Mindestzahl an Besuchern erreicht. Die genaue Schwelle veröffentlicht Google nicht. Für einen Handwerksbetrieb mit ein paar hundert Sitzungen im Monat heißt das meistens: keine seitenbezogenen Felddaten, mit etwas Glück noch Origin-Daten für die Domain. Dann bleiben zwei Wege. Entweder Sie arbeiten auf Origin-Ebene, oder Sie messen selbst, etwa mit der web-vitals-Bibliothek von Google Chrome, und schicken die Werte in Ihr Analytics.

CrUX sieht nicht alles. Chrome auf iOS, Android-WebViews und andere Chromium-Browser wie Edge liefern keine Daten. Query-Parameter und Fragmente werden aus der URL entfernt, alle Varianten laufen also in einen Wert zusammen. Bei Shops mit Filter-URLs überrascht das.

Widersprechen sich Labor und Feld, gilt das Feld. So steht es in der Chrome-Dokumentation.

Die Reihenfolge, die wir abarbeiten

Niemand bezahlt dafür, dass 40 Lighthouse-Hinweise der Reihe nach abgehakt werden. Unser Ablauf für technische OnPage-Arbeit:

1. Felddaten vor der ersten Änderung. Sind keine da, RUM einbauen und zwei Wochen sammeln. Ohne Ausgangswert ist nicht belegbar, was die Arbeit gebracht hat.
2. Auf Seitentypen aggregieren, nicht auf einzelne URLs. Startseite, Leistungsseite, Kategorie, Produkt, Artikel. Ein Fix am Template wirkt auf tausend URLs, ein Fix an einer URL auf eine. Google bewertet zwar im Regelfall seitenbezogen, aber repariert wird das Template.
3. Nach Geschäftswert priorisieren, nicht nach Punktzahl. Der Seitentyp, der Anfragen bringt, kommt zuerst, auch wenn ein anderer schlechter dasteht.
4. LCP zuerst, und dort in dieser Abfolge: LCP-Element identifizieren, prüfen ob seine URL im HTML-Quelltext auffindbar ist, dann Priorität setzen (fetchpriority="high", loading="lazy" vom LCP-Bild entfernen), dann TTFB und CDN, erst danach die Dateigröße. Nach Chromes Auswertung echter Nutzerdaten entfällt bei den meisten Seiten mit schlechtem LCP weniger als ein Zehntel der Zeit auf den eigentlichen Download des Bildes. Verloren geht sie davor.
5. CLS danach, weil es meist billig ist: width und height oder aspect-ratio auf alles, was nachlädt. Ein sinnvolles min-height statt der Standardhöhe von 0 Pixeln bei Containern, deren Inhalt später kommt. Keine Animationen auf Eigenschaften, die Layout auslösen, stattdessen transform. Dazu die bfcache-Tauglichkeit prüfen, was gleichzeitig dem LCP hilft.
6. INP zuletzt und nur mit Felddiagnose. Lange Aufgaben aufbrechen (alles über 50 Millisekunden), unnötiges JavaScript entfernen, große Rendering-Updates vermeiden. Der Tag-Manager-Container gehört hier auf den Tisch, weil dort die Skripte liegen, für die sich intern niemand zuständig fühlt.
7. 28 Tage warten. Das CrUX-Fenster ist gleitend, eine Korrektur zeigt sich zunächst als flache Verbesserung und ist erst nach vier Wochen vollständig sichtbar.

Schritt 7 ist der, an dem Projekte scheitern, weil nach zehn Tagen jemand fragt, warum sich nichts getan hat.

Was wir bewusst nicht tun

Wir jagen keinen Lighthouse-Score von 100. Der Score ist ein gewichteter Laborwert und kein Rankingsignal.

Wir fangen nicht mit Bildkomprimierung an, solange das LCP-Bild erst nach dem JavaScript entdeckt wird. Ein kleineres Bild, das zu spät startet, ist immer noch zu spät.

Und wir optimieren keine Seitentypen, für die es weder Felddaten noch Geschäft gibt. Beim Relaunch liegt der Fall anders: dort gehören die Werte in die Abnahmekriterien, sonst verschiebt sich das Problem nur, wie es bei einer SEO-Migration regelmäßig passiert.

Wann Core Web Vitals nicht Ihr Problem sind

Taucht Ihre Seite für Ihre wichtigsten Suchanfragen überhaupt nicht in den Top 20 auf, ändert ein LCP von 2,1 statt 3,4 Sekunden daran nichts. Dann fehlt Inhalt, Relevanz oder Autorität, und die Technikstunden sind woanders besser angelegt, etwa dabei, Ihre Seiten für Suchmaschinen und KI-Systeme eindeutig zu machen: Strukturierte Daten, die echte Rich Results bringen.

Sind Ihre Werte grün und die Rankings kommen trotzdem nicht, haben Sie eine Ursache sauber ausgeschlossen. Auch das ist ein Ergebnis.

Ob Technik bei Ihnen der Engpass ist, sagt Ihnen die kostenlose Analyse.