Core Web Vitals 2026: INP, LCP und CLS nachhaltig verbessern
Eine grüne PageSpeed-Anzeige ist nicht das eigentliche Ziel. Entscheidend ist eine Website, die ihren nützlichen Inhalt schnell zeigt, ohne Zögern reagiert und für echte Besucher visuell stabil bleibt – und deren Fortschritt sich anschließend mit passenden Daten belegen lässt.
Nutzen Sie CrUX und die Search Console, um zu verstehen, was berechtigte Chrome-Nutzer über einen längeren Zeitraum wirklich erlebt haben. Mit PageSpeed Insights und DevTools lässt sich ein Problem reproduzieren und diagnostizieren. Optimieren Sie anschließend die Ressource, die JavaScript-Aufgabe oder die Layout-Entscheidung, die den Engpass verursacht. Am 75. Perzentil gelten LCP bis 2,5 Sekunden, INP bis 200 Millisekunden und CLS bis 0,1 als gut. Alle drei Werte zu bestehen hilft Nutzern und der Seitenerfahrung, garantiert aber keine Spitzenposition.[1]
Core Web Vitals erfassen drei Dimensionen realer Nutzererfahrung: Ladeleistung, Reaktionsfähigkeit und visuelle Stabilität. Hinter den technischen Namen stehen geschäftlich sehr konkrete Fragen. Sehen Interessenten das wichtigste Angebot rechtzeitig? Reagiert das Menü auf eine Berührung? Bleibt die Schaltfläche für die Anfrage an ihrem Platz, wenn jemand sie anklicken möchte?
Dieser Leitfaden zielt deshalb nicht auf eine isolierte Punktzahl, sondern auf ein wiederholbares System für Unternehmen, Marketing, Design und Entwicklung. Für die gesamte organische Strategie finden Sie unsere SEO-Optimierung. Wenn die Struktur neu gedacht werden muss, lesen Sie mehr über Webdesign und Website-Erstellung. Sichtbarkeit in generativen Antworten ist ein eigenes Thema; dafür gibt es unseren Leitfaden zu KI-SEO 2026.
Viele Origins bestehen einzelne Metriken – deutlich weniger die Gesamtbewertung
Largest Contentful Paint
≤ 2,5 sMisst, wann das größte sichtbare Inhaltselement gerendert wird. Häufig ist es das Hero-Bild, ein großer Überschriftenblock oder ein markanter Banner.
Interaction to Next Paint
≤ 200 msBewertet die Zeit bis zur nächsten sichtbaren Reaktion nach Interaktionen im gesamten Besuch, nicht nur nach dem ersten Klick.
Cumulative Layout Shift
≤ 0,1Erfasst unerwartete Layout-Bewegungen während der Nutzung. Ein niedriger Wert bedeutet, dass Inhalt und Bedienelemente vorhersehbar bleiben.
Chrome UX Report: Origin-Überblick für Juli 2026
Offizielle CrUX-Daten, im Juli 2026 erhoben und am 11. August 2026 veröffentlicht. Das sind Ökosystemstatistiken auf Origin-Ebene, keine Ziele oder Prognosen für eine einzelne Website. Daraus lässt sich ableiten, dass 44,3 % der dargestellten Origins die Gesamtbewertung nicht bestanden; welche konkrete Maßnahme eine Website braucht, zeigt die Quote nicht.[11]
Google empfiehlt gute Core Web Vitals für den Erfolg in der Suche und für eine gute allgemeine Nutzererfahrung, beschreibt sie aber als einen Teil der Seitenerfahrung. Relevanz, Nützlichkeit, Crawlbarkeit und viele weitere Signale bleiben wichtig. „Alles ist grün, also müssen wir Platz eins bekommen“ ist genauso falsch wie „Geschwindigkeit hat keinen SEO-Wert“. Die sinnvolle Konsequenz lautet: vermeidbare Reibung entfernen, Wirkung sauber messen und den eigentlichen Zweck der Seite weiter verbessern.[1]
Was LCP, INP und CLS zeigen – und was nicht
LCP: Der wichtigste Inhalt erscheint zu spät
LCP ist nicht der Zeitpunkt, an dem alle Netzwerkanfragen beendet sind. Die Metrik markiert, wann das größte geeignete Element im sichtbaren Bereich gezeichnet wird. Eine langsame Serverantwort, ein spät entdecktes Hero-Bild, renderblockierendes CSS, eine schwere Webfont oder Client-Rendering können denselben Wert verzögern. Der LCP-Kandidat kann sich während des Ladens ändern; ein Screenshot reicht daher nicht für die Ursache. Zerlegen Sie die Zeit in Time to First Byte, Verzögerung vor dem Ressourcenabruf, Abrufdauer und Render-Verzögerung des Elements.[6]
INP: Nach einer Aktion wirkt die Seite eingefroren
INP beobachtet geeignete Klick-, Tipp- und Tastaturinteraktionen während des gesamten Besuchs und berichtet nach der definierten Ausreißerbehandlung eine repräsentative Interaktion mit hoher Latenz. Enthalten sind Eingabeverzögerung, Verarbeitungszeit und Darstellungsverzögerung. Ein großes JavaScript-Bundle kann beitragen, doch die eigentliche Ursache kann ein langer Callback, teure DOM-Arbeit, erzwungene Layout-Berechnung oder spätes Zeichnen sein. Beginnen Sie möglichst mit Feldkontext: Welche Seite, welches Element, welches Gerät und welche Aktion waren langsam?[7]
CLS: Die Oberfläche bewegt sich ohne Absicht des Nutzers
CLS sammelt unerwartete Layout-Verschiebungen in Sitzungsfenstern. Bilder ohne Größen, nachgeladene Banner oder Anzeigen, Consent-Tools, späte Fonts und layoutverändernde Animationen sind häufige Ursachen. Eine erwartete Bewegung kurz nach einer echten Nutzeraktion kann aus der Wertung fallen, doch dadurch wird nicht jede irritierende Oberfläche akzeptabel. Reservieren Sie Raum und gestalten Sie Zustandswechsel vorhersehbar, statt die Kennzahl auszutricksen.[8]
| Signal | Symptom für Besucher | Häufige technische Ursachen | Erster Prüfpunkt |
|---|---|---|---|
| LCP | Hauptbotschaft oder Hero erscheint spät | Serverlatenz, Bilderkennung, großes Medium, blockierendes CSS | CrUX-URL-Gruppe, LCP-Element und Teilzeiten im Trace |
| INP | Tipp oder Tastaturaktion scheint ignoriert | Lange Tasks, schwere Callbacks, großer DOM, Drittanbieter | Feldattribution und Hauptthread-Aufzeichnung |
| CLS | Text, Schaltfläche oder Karte springt | Fehlende Größe, dynamisches Embed, Fonttausch, injizierte UI | Shift-Cluster und betroffene Elemente |
Feld- und Labordaten beantworten unterschiedliche Fragen
Felddaten stammen aus realen Besuchen mit tatsächlichen Geräten, Netzen, Cache-Zuständen und Verhaltensweisen. CrUX liefert den Real-User-Teil von PageSpeed Insights und die Grundlage des Core-Web-Vitals-Berichts in der Search Console. Die Daten sind aggregiert und datenschutzgeschützt; sie setzen Eignung und ausreichende Stichprobe voraus. Da das rollierende Fenster vergangene Besuche enthält, wird es nach einer Veröffentlichung nicht sofort grün.[4][5]
Labordaten entstehen in einem kontrollierten Test. Lighthouse, PageSpeed-Diagnosen und Chrome DevTools reproduzieren eine Seite unter definierten Bedingungen und zeigen Netzwerk-, Render- und Hauptthread-Arbeit. Sie eignen sich hervorragend zur Fehlersuche und für Regressionstests, sind aber keine Zählung aller Kunden. Ein schneller Entwicklerrechner, eine mobile Simulation mit leerem Cache und ein wiederkehrender Besucher können dieselbe URL sehr unterschiedlich erleben.[2]
Mit Felddaten priorisieren
Fragen Sie, ob genügend echte Besucher betroffen sind, welche URL-Gruppe und Geräteklasse das Problem zeigen und ob der Trend anhält. Die Search Console findet Muster; CrUX-Verlauf oder eigenes Real User Monitoring ergänzt Kontext.
Mit Labordaten erklären
Reproduzieren Sie einen repräsentativen langsamen Weg. Untersuchen Sie die LCP-Ressource und ihre Kette, lange Tasks rund um die Interaktion oder Layout-Shift-Cluster. Testen Sie nach jeder zusammenhängenden Änderung erneut.
Feldpanel und Lighthouse-Lauf unterscheiden sich bei Population, Zeitraum, Gerät, Netzwerk und verfügbaren Metriken. „Keine Daten“ heißt nicht „perfekt“. Einer URL kann ausreichender berechtigter Traffic fehlen oder das Tool zeigt Origin-Daten. Lesen Sie vor jedem Vergleich die Beschriftung und den Umfang.[3]
Messen → segmentieren → reproduzieren → verbessern → validieren
Feldstatus, 75. Perzentil, Stichprobenumfang und Datum erfassen. Basis vor der Änderung sichern.
Nach Template, Gerät, Region und Traffic aufteilen. Ein langsames Template kann viele URLs belasten.
Den typischen Weg in DevTools reproduzieren. Metrik einer Ressource, Aufgabe oder Layout-Entscheidung zuordnen.
Vor Release testen, Fehler überwachen und vor dem Erfolgsurteil genügend neue Felddaten abwarten.
Beginnen Sie mit der größten Kombination aus geschäftlicher Bedeutung und Nutzerschaden, nicht mit der am leichtesten zu erhöhenden Punktzahl. Eine stockende Anfrage im Conversion-Pfad ist wichtiger als eine kleine Verschiebung im Archiv. Führen Sie ein Protokoll mit Datum, betroffenem Template, Hypothese, Laborbeleg und späterem Feldergebnis. Ohne Annotationen kann Saisonalität oder eine Browseränderung fälschlich als Entwicklungserfolg gelten.
Die Search Console gruppiert ähnliche URLs, um breite Muster zu zeigen; sie ist nicht zur Diagnose einer einzelnen Interaktion gedacht. Prüfen Sie repräsentative URLs und danach, ob Template und Ressourcen gemeinsam genutzt werden. Das Performance-Panel von DevTools erfasst Netzwerk und Hauptthread, hebt lange Tasks hervor und macht die Reihenfolge nachvollziehbar. Nutzen Sie es zum Erklären, nicht nur für einen eindrucksvollen Screenshot.[4][12]
LCP verbessern, ohne den wichtigsten Inhalt zu verstecken
Identifizieren Sie zuerst LCP-Element und Teilzeiten. Dominiert die Serverzeit, untersuchen Sie Hosting, Anwendungsarbeit, Weiterleitungen, Caching und Content Delivery. Dominiert die Verzögerung vor dem Ressourcenabruf, machen Sie das Hero-Medium im ersten HTML auffindbar, vermeiden Sie Lazy Loading für das wahrscheinliche LCP-Bild und prüfen Sie messbasiert Preload oder Fetch-Priorität. Dominiert die Übertragung, dimensionieren und komprimieren Sie passend und wählen Sie ein effizientes Format. Dominiert die Elementdarstellung, untersuchen Sie blockierende Styles, Fonts und Client-Rendering.[6]
- Erstes HTML schnell liefern und unnötige Weiterleitungsschritte entfernen.
- Wahrscheinliches LCP-Bild im Markup früh auffindbar machen.
- Kein pauschales Lazy Loading auf das Hero im sichtbaren Bereich anwenden.
- Responsive Bildkandidaten und korrekte intrinsische Abmessungen anbieten.
- Nur tatsächlich kritisches CSS priorisieren und Unkritisches kontrolliert verschieben.
- Fontfamilien, Schnitte und blockierende Abhängigkeiten begrenzen.
- Wichtige Leistungs- und Inhaltstemplates messen, nicht nur die Startseite.
Ein kleineres Hero-Bild gleicht zwei Sekunden Serververzögerung nicht aus. Schnelles Hosting kann kein Bild früh entdecken, das erst nach einem großen Client-Bundle eingefügt wird. Bearbeiten Sie den größten gemessenen Zeitanteil. Entfernen Sie aber nicht die nützliche Überschrift oder das Bild nur für einen kleineren Wert: Eine schnelle Seite, die ihr Angebot nicht mehr vermittelt, verfehlt das Geschäftsziel.
INP durch kontrollierte Hauptthread-Arbeit verbessern
Ein schlechter INP zeigt sich oft nach dem Laden, wenn Analytics, Chat, Slider, Filter und Anwendungscode um den Hauptthread konkurrieren. Finden Sie mit Feldattribution oder RUM die langsame Interaktion und zeichnen Sie denselben Weg in DevTools auf. Teilen Sie lange Tasks, reduzieren Sie Callback-Arbeit, vermeiden Sie wiederholte synchrone Layout-Lese- und Schreibvorgänge und rendern Sie nur den DOM für den aktuellen Zustand. Geben Sie dem Browser zwischen nicht kritischen Arbeitspaketen Gelegenheit zum Zeichnen.[7]
Drittanbieter-Skripte brauchen geschäftliche Verantwortung. Listen Sie Tag, Besitzer, Ladebedingung und messbaren Wert auf. „Marketing braucht es“ ist keine dauerhafte Ausnahme. Laden Sie Support-Widgets gegebenenfalls erst nach einem Absichtssignal, entfernen Sie doppelte Analysewerkzeuge und testen Sie die Consent-Lösung. Ist eine komplexe Funktion unverzichtbar, können progressives Rendering und Server-HTML die erste nützliche Interaktion schützen, während das umfangreiche Verhalten aktiviert wird.
| Phase | Bedeutung | Typische Reaktion |
|---|---|---|
| Eingabeverzögerung | Hauptthread war vor Beginn des Callbacks belegt | Unabhängige lange Tasks reduzieren oder planen; Unnötiges verschieben |
| Verarbeitungsdauer | Handler und synchrone Arbeit dauerten zu lange | Callbacks vereinfachen, Arbeit teilen, DOM und Berechnung reduzieren |
| Darstellungsverzögerung | Browser brauchte zu lange für Berechnung und nächstes Bild | Layout-Komplexität, DOM-Änderungen und teure Effekte senken |
Optimieren Sie nicht nur einen Demo-Klick. INP repräsentiert den Besuch; testen Sie Navigation, Akkordeons, Filter, Formulare, Validierung, Consent-Auswahl und zentrale Conversion-Aktionen. Auch die Tastatur zählt. Eine Seite kann schnell laden und trotzdem den Lead verlieren, weil das erste Formularfeld einfriert.
CLS durch reservierten Raum und kontrollierte Änderungen verbessern
Geben Sie Bildern und Videos width und height oder ein Seitenverhältnis, damit der Browser vor dem Download Platz reserviert. Legen Sie für Anzeigen, Karten, Bewertungen, Consent-Elemente und eingebettete Medien eine vorhersehbare Mindestgröße fest. Für einen bedingten Banner eignet sich eine reservierte Region oder ein Overlay, das nicht die ganze Seite verschiebt. Bei dekorativen Animationen ist transform häufig sicherer als Eigenschaften, die das Layout verändern.[8]
Fonts benötigen bewusst gewählte Fallbacks. Weichen ihre Metriken stark ab, bricht eine Überschrift beim Eintreffen der Webfont neu um. Reduzieren Sie Varianten, priorisieren Sie nur nötige Dateien, wählen Sie ein geeignetes Ladeverhalten und prüfen Sie unterstützte Metrikanpassungen. Sehen Sie sich danach echte Shift-Cluster an: Ein später springender Footer kann durch ein Bild ohne Abmessungen weiter oben verursacht werden und muss kein Footer-Fehler sein.
- Intrinsische Größe oder Seitenverhältnis für jedes redaktionelle und Produktbild festlegen.
- Realistischen Raum für dynamische Einbettungen und Consent-Komponenten reservieren.
- Nach dem ersten Zeichnen keine Nachricht oberhalb vorhandener Inhalte einschieben.
- Fontwechsel bei langen Überschriften in allen vier Sprachen prüfen.
- Responsive Breakpoints testen, weil Zeilenumbrüche die betroffene Fläche ändern.
- Echte Abläufe wiederholen; Verschiebungen können lange nach dem Laden auftreten.
Core Web Vitals in WordPress: das System statt einer URL verbessern
Server und Templates
Messen Sie First Byte, Full-Page-Cache, Datenbank- und PHP-Arbeit, Weiterleitungen, Theme-Ausgabe und Bilderzeugung. Ein überladenes Template vervielfacht sich über Leistungen oder Artikel. Arbeiten Sie in Staging mit Rückweg.
Plugins und Drittanbieter
Ordnen Sie Plugins und Tags nach Funktion, Besitzer und Frontend-Kosten. Entfernen Sie Überschneidungen, deaktivieren Sie Ressourcen ohne Funktion und testen Sie Updates. Ein Cache-Plugin neutralisiert nicht jeden Slider und Tracker.
Die WordPress-Dokumentation behandelt Caching, Bildoptimierung, weniger Dateianfragen und aktuelle Software als Teile einer umfassenden Performance-Praxis.[9] Übersetzen Sie das in Governance: Neue Plugins erhalten Verantwortliche und Test; Theme-Änderungen brauchen Vorher-Nachher-Belege je Template; große Uploads erzeugen automatisch Varianten; kritische Seiten werden nach Releases synthetisch überwacht.
Seien Sie vorsichtig mit „Alles optimieren“-Schaltern. Jedes JavaScript zu verzögern kann Navigation, Consent, Analytics oder Formulare beschädigen. Dateien zusammenzufassen ist mit modernen Protokollen nicht immer vorteilhaft. Aggressiver Cache kann personalisierte Inhalte veralten lassen. Ändern Sie eine zusammenhängende Ebene, prüfen Sie Funktion, Barrierefreiheit und Conversion-Messung und vergleichen Sie erst dann. Auch das schnellste kaputte Formular liefert keine Leads.
Soft-Navigation-Messung 2026: wichtig, aber noch nicht universell
Die klassische Core-Web-Vitals-Messung beginnt mit einer Top-Level-Navigation. Single-Page-Anwendungen können URL und fast den gesamten Inhalt ohne vollständiges Neuladen wechseln; dadurch war die Experience einzelner Routen schwer im selben Modell abzubilden. Der am 11. August 2026 aktualisierte SPA-Leitfaden von web.dev erklärt, Chrome 151 habe APIs eingeführt, mit denen Core Web Vitals über weiche Routenwechsel messbar werden. Genannt werden PerformanceSoftNavigation und InteractionContentfulPaint.[10]
Der Umfang ist entscheidend. Zu diesem Zeitpunkt begann die Einführung erst in der Bibliothek web-vitals, in Real-User-Monitoring-Lösungen und Werkzeugen wie DevTools. Chrome hatte keinen Zeitplan für die Aufnahme in CrUX veröffentlicht; andere Browser-Engines unterstützten die APIs noch nicht. Behaupten Sie daher im September 2026 nicht, die Search Console erfasse automatisch jede SPA-Route. Führen Sie Soft-Navigation-Daten als neue, getrennte Diagnosequelle und dokumentieren Sie Bibliothek, Version sowie Browserpopulation.[10]
Unabhängig vom Framework braucht Google zugängliches HTML, Ressourcen, Links und sinnvoll gerenderten Inhalt. Die Grundlagen für JavaScript-SEO gelten weiter: crawlbare Links, stabile URLs, passende Statuscodes und serverseitiges oder vorgeneriertes Rendering dort, wo es Zuverlässigkeit schafft.[13] Performance und Indexierbarkeit überschneiden sich, sind aber nicht dasselbe. Eine Route kann schnell und unauffindbar oder indexierbar und unerträglich langsam sein.
Behalten Sie Felddaten vollständiger Navigationen als vergleichbare Basis. Ergänzen Sie Soft-Navigation-Telemetrie als klar getrennte Messschicht 2026. Führen Sie inkompatible Populationen nie ohne Hinweis auf die geänderte Definition zu einer Trendlinie zusammen.
Ein Performance-Budget, das das gesamte Team umsetzen kann
Ein Budget macht aus „Die Seite soll schnell bleiben“ überprüfbare Release-Kriterien. Es kombiniert Ergebnisziele, Ressourcengrenzen und Prozessregeln. Core-Web-Vitals-Feldziele sind Resultate; JavaScript-Gewicht, Hero-Bildgröße und Anzahl externer Dienste sind steuerbare Eingaben. Leiten Sie Grenzen aus der aktuellen Website und ihrer Zielgruppe ab, statt universelle Zahlen zu kopieren. Jede Ausnahme braucht einen Besitzer und ein Ablaufdatum.
Experience-Budget
LCP-, INP- und CLS-Ziele am 75. Perzentil für priorisierte Templates, ergänzt um Aufgaben wie die Reaktionszeit eines Formulars.
Auslieferungsbudget
Obergrenzen für kritische Bilder, initiales JavaScript, CSS, Fonts und Drittanbieterarbeit in einem vereinbarten Mobilprofil.
Governance-Budget
Benannter Besitzer, Test vor Release, Beobachtungsfenster, Rollback-Bedingung und Ablaufdatum jeder Ausnahme.
| Element | Beispielwarnung | Beispiel-Blocker | Verantwortlich |
|---|---|---|---|
| Hero-Bildtransfer | Über 180 KB | Über 260 KB | Design/Inhalt |
| Initiales First-Party-JS | Über 170 KB komprimiert | Über 230 KB komprimiert | Entwicklung |
| Drittanbieter-Hauptthread | Über 200 ms im Testprofil | Über 350 ms | Marketing + Entwicklung |
| CLS-Laborschranke | Über 0,08 | Über 0,10 | Design + Qualität |
Die Zahlen sind bewusst illustrativ. Definieren Sie eigene Werte aus geschäftskritischen Templates, repräsentativen Geräten und gemessener Basis. Eine Laborschranke ersetzt keine Feldvalidierung.
Template-Scorecard statt isoliertem Startseiten-Screenshot
Das folgende fiktive Beispiel zeigt, wie Belege berichtet werden können, ohne jede Bewegung automatisch als kausalen Effekt zu verkaufen. Feldbeobachtung, Labordiagnose, veröffentlichte Maßnahme und spätere Validierung bleiben getrennt. Zeiten und Prozentwerte sind Beispiele.
| Phase | LCP p75 | INP p75 | CLS p75 | Interpretation |
|---|---|---|---|---|
| 28-Tage-Basis | 3,4 s | 248 ms | 0,07 | LCP und INP verbessern; CLS gut |
| Labordiagnose | Hero erst nach Slider-Skript entdeckt | Filter-Callback erzeugt langen Task | Kein wiederholbares Problem | Zwei unabhängige Ursachen |
| Deployment | Statisches Hero im ersten HTML | Callback geteilt; unnötiges Plugin entfernt | Abmessungen beibehalten | Funktion und Tracking geprüft |
| Neues Feldfenster | 2,3 s | 182 ms | 0,06 | Fortschritt passt zur Maßnahme; Monitoring läuft |
Zeigen Sie URL-Gruppe, Gerätemix, Zeitraum, Release-Datum und Stichprobengrenzen neben der Scorecard. Nutzen Sie Conversion-Qualität als Schutzmetrik. Steigt die Geschwindigkeit, während Formulare ausfallen oder qualifizierte Anfragen sinken, war der Release kein Erfolg. Technisches SEO dient Besucher und Unternehmen, nicht der Kennzahl allein.
Core-Web-Vitals-Plan für 30/60/90 Tage
Basis und Triage
Search-Console-Gruppen und CrUX-Verlauf exportieren, Templates und Drittanbieter inventarisieren, zentrale Abläufe wählen, Laborprofile festlegen, fehlende Bildgrößen und falsches Lazy Loading beheben und ein annotiertes Messwörterbuch erstellen.
Ursachen beheben
Server und LCP-Erkennung optimieren, lange Tasks an geschäftlichen Interaktionen reduzieren, dynamischen Raum reservieren, WordPress-Plugins oder JavaScript-Chunks prüfen, erstes Performance-Budget umsetzen sowie Barrierefreiheit und Analytics testen.
Validieren und steuern
Vollständig neue Feldfenster auswerten, priorisierte Templates vergleichen, Regressionen untersuchen, Conversion-Schutzmetriken berichten und Release-Prüfungen mit Besitzern einführen. Bei SPAs Soft-Navigation-Telemetrie getrennt von CrUX kennzeichnen.
Warten Sie mit einer sicheren, offensichtlichen Korrektur nicht 90 Tage; der Plan beschreibt Governance, nicht Verzögerung. Erklären Sie umgekehrt nicht am Tag eines grünen Labortests den Felderfolg. Das Berichtsfenster muss ausreichend reale Besuche nach dem Release enthalten.
Core-Web-Vitals-Checkliste
- Feld- und Laborwerte sind gekennzeichnet und nie als unerklärte Zahl vermischt.
- Priorisierte URLs werden nach gemeinsamem Template und Geschäftsablauf gruppiert.
- LCP-Element und Teilzeiten sind vor der Optimierung dokumentiert.
- Die INP-Diagnose nennt eine reale Interaktion und ihre langsame Phase.
- Die CLS-Analyse nennt betroffenes sowie auslösendes Element.
- Mobil, Desktop und Kernregionen werden bei ausreichenden Daten getrennt betrachtet.
- Consent, Formulare, Navigation, Analytics und Barrierefreiheit funktionieren nach jeder Änderung.
- Das Release-Protokoll enthält Datum, Besitzer, Hypothese und Rollback-Bedingung.
- Feldvalidierung verwendet ein neues, ausreichend repräsentatives Fenster.
- Performance-Grenzen gelten auch für künftige Inhalte und Releases.
Core Web Vitals 2026: FAQ
Sind Core Web Vitals ein Google-Rankingfaktor?
Google erklärt, gute Core Web Vitals passten als Teil der Seitenerfahrung zu dem, was die zentralen Ranking-Systeme belohnen möchten. Sie sind nicht die einzigen Signale, und Bestehen garantiert keine Position. Verbessern Sie sie für Nutzer und Suchbereitschaft, nicht als isolierten Trick.[1]
Welche guten Grenzwerte gelten 2026?
Am 75. Perzentil gelten LCP bis 2,5 Sekunden, INP bis 200 Millisekunden und CLS bis 0,1 als gut. Betrachten Sie mobile und Desktop-Populationen statt nur eines idealen Tests.[1]
Warum ist PageSpeed grün und die Search Console rot?
Lighthouse ist eine kontrollierte Laboraufnahme. Die Search Console aggregiert echte CrUX-Nutzerdaten und URL-Gruppen über Zeit. Geräte, Netze, Cache, Population und Zeitraum unterscheiden sich. Prüfen Sie, ob PageSpeed Feldwerte für URL oder Origin anzeigt.[2][4]
Wie schnell erscheint eine Korrektur in der Search Console?
Nicht sofort. Feldberichte nutzen ein rollierendes Fenster und brauchen neue berechtigte Besuche. Prüfen Sie Änderungen unmittelbar in Staging und Labor, beobachten Sie danach aber ein frisches Feldfenster.
Sollte das Hero-Bild lazy geladen werden?
Meist nicht, wenn es oberhalb der Falz das wahrscheinliche LCP-Element ist. Machen Sie es früh auffindbar, korrekt dimensioniert und angemessen priorisiert. Laden Sie Medien darunter nach einer Messung verzögert.[6]
Löst ein Cache-Plugin alle WordPress-Probleme?
Nein. Caching kann die Lieferung verbessern; späte Hero-Erkennung, große Bilder, lange JavaScript-Aufgaben, fehlende Größen und Drittanbieter-Widgets brauchen andere Maßnahmen.
Misst INP nur die erste Interaktion?
Nein. Anders als der frühere FID bewertet INP die Reaktionsfähigkeit über den Seitenbesuch und repräsentiert nach seiner Definition eine Interaktion mit hoher Latenz. Testen Sie alle wichtigen Bedienelemente.[7]
Erfasst CrUX bereits jede Soft Navigation einer SPA?
Nein. Der web.dev-Leitfaden vom August 2026 erklärt, dass Chrome-151-APIs diese Messung in Tools erst ermöglichen. Für CrUX war kein Zeitplan angekündigt, und andere Browser-Engines unterstützten sie noch nicht.[10]
Was gehört in den monatlichen Managementbericht?
Zeigen Sie Feldstatus nach priorisiertem Template, gemessenen Engpass, veröffentlichte Änderungen, neues Validierungsfenster, Budgetausnahmen und Conversion- oder Funktionsschutz. Vermeiden Sie eine Startseitenzahl ohne Kontext.
Quellen und Methodik
Grenzwerte, Produktumfang und Änderungen für 2026 stammen aus primären Dokumentationen von Google, Chrome und web.dev. CrUX-Quoten beschreiben dargestellte Origins, nicht den Benchmark eines einzelnen Unternehmens. Zahlen in Budget und Fallbeispiel sind ausdrücklich illustrativ.
- Google Search Central — Understanding Core Web Vitals and Google search results, aktualisiert am 10. Dezember 2025.
- web.dev — Why lab and field data can be different.
- Google Developers — Informationen zu PageSpeed Insights.
- Google Search Console-Hilfe — Core-Web-Vitals-Bericht.
- Chrome for Developers — Chrome UX Report-Dokumentation.
- web.dev — Largest Contentful Paint optimieren.
- web.dev — Interaction to Next Paint optimieren, aktualisiert am 2. September 2025.
- web.dev — Cumulative Layout Shift optimieren.
- WordPress Developer Resources — Optimization.
- web.dev — How SPA architectures affect Core Web Vitals, aktualisiert am 11. August 2026.
- Chrome UX Report — Versionshinweise, Datensatz Juli 2026, veröffentlicht am 11. August 2026.
- Chrome for Developers — Performance-Funktionsreferenz.
- Google Search Central — Grundlagen von JavaScript-SEO.
Performance-Daten in eine vertrauenswürdige Website übersetzen
Levent Global Media kann Ihre Core Web Vitals prüfen, Engpässe in Templates und Drittanbietern isolieren und technische SEO-Verbesserungen mit verlässlichen Nutzer- und Geschäftsergebnissen verbinden.
