Core Web Vitals

TL;DR — Core Web Vitals sind drei Werte, mit denen Google misst, wie sich eine Seite für echte Nutzer anfühlt: wie schnell sie lädt (LCP), wie schnell sie reagiert, wenn getippt oder geklickt wird (INP), und wie stark beim Laden alles verspringt (CLS). „Gut“ heißt: LCP unter 2,5 Sekunden, INP unter 200 Millisekunden und CLS unter 0,1. Sie beeinflussen Rankings ein wenig — guter Inhalt zählt aber weit mehr.

Was Core Web Vitals sind

Google möchte Seiten belohnen, die sich angenehm nutzen lassen, und hat „gute Page Experience“ deshalb auf drei messbare Dinge heruntergebrochen. Zusammen sind das die Core Web Vitals (oft abgekürzt als CWV):

• Largest Contentful Paint (LCP) — Ladezeit. Wie lange es dauert, bis das größte Element auf dem Bildschirm (meist ein Hero-Bild oder eine Überschrift) erscheint. Gut ist ≤ 2,5 Sekunden.
• Interaction to Next Paint (INP) — Reaktionsfähigkeit. Wenn ein Button angetippt oder etwas eingegeben wird: wie lange es dauert, bis die Seite reagiert. Gut ist ≤ 200 Millisekunden.
• Cumulative Layout Shift (CLS) — visuelle Stabilität. Wie stark die Seite beim Laden verspringt (eine Anzeige schiebt den Text nach unten, gerade wenn man tippen will). Gut ist ≤ 0,1.

Woher die Werte stammen

Die Werte, die Google tatsächlich verwendet, stammen von echten Menschen, die Ihre Website besuchen — in Chrome, nicht aus einem Test, den Sie selbst ausführen. Google sammelt diese Daten, und eine Seite wird danach beurteilt, was 75 % der Besucher erlebt haben. Sie können also nicht „bestehen“, indem Sie auf Ihrem eigenen Rechner ein schnelles Ergebnis erzielen; die meisten Ihrer echten Besucher müssen eine gute Erfahrung haben. Evidence for this claim Core Web Vitals are real-world experience metrics used by Google ranking systems; lab measurements are diagnostic and can differ from field measurements. Scope: Google Search use of Core Web Vitals and Chrome UX Report field data. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search web.dev: Lab and field data

Deshalb garantiert ein perfekter Wert in einem Speed-Test-Tool noch nicht, dass Sie bestehen. Diese Tools (etwa PageSpeed Insights und Lighthouse) führen einen einzelnen Labortest auf einem simulierten Smartphone aus — hervorragend, um Probleme zu finden, aber nicht die Zahlen, auf deren Basis Google rankt.

Beeinflussen sie das Ranking?

Ein wenig. Google sagt, dass Core Web Vitals von seinen Ranking-Systemen verwendet werden — es sind ihnen aber keine offizielle Gewichtung und kein Prozentsatz zugeordnet, und Google stellt ausdrücklich klar, dass relevanter Inhalt weiterhin besser ranken kann als eine Seite mit mangelhafter Page Experience. Wenn Ihr Inhalt nicht relevant ist, retten Sie schnell und stabil nicht. John Mueller von Google formulierte es so: “it’s not going to make your site’s rankings jump up.” (Übersetzung) „Das wird die Rankings Ihrer Website nicht nach oben springen lassen.“

Meine ehrliche Einschätzung nach Jahren in diesem Feld: Die meisten Websites werden durch das Jagen dieser Zahlen keinen großen Ranking-Vorteil sehen. Es spricht aber nichts dagegen, die eigene Website schneller und stabiler zu machen — die Besucher merken es, und es hilft den Conversions, selbst wenn sich am Ranking nichts bewegt.

Ein häufiges Missverständnis

Achtung, alter Name: Ihnen begegnet vielleicht noch FID (First Input Delay) als Core Web Vital. Das ist vorbei — INP hat FID am 12. März 2024 abgelöst. Wenn ein Tool oder ein Artikel Ihnen immer noch rät, FID zu optimieren, ist er veraltet.

Sie wollen die ausführliche Version — exakte Schwellenwerte, Feld- vs. Labordaten, wie stark sie tatsächlich fürs Ranking zählen und welches Tool wann das richtige ist? Wechseln Sie zum Tab Fortgeschritten.

TL;DR — Core Web Vitals sind drei im Feld gemessene UX-Metriken: LCP (Ladezeit, „gut“ bei ≤ 2,5 s), INP (Reaktionsfähigkeit, ≤ 200 ms) und CLS (visuelle Stabilität, ≤ 0,1), jeweils bewertet am 75. Perzentil echter Chrome-Nutzer (CrUX) über ein rollierendes 28-Tage-Fenster. Die Schwellenwerte sind für Mobil und Desktop identisch, Google bewertet sie aber getrennt und erwartet, dass alle drei Metriken gut sind — nicht nur eine. INP hat FID am 12. März 2024 abgelöst. Google sagt, seine Ranking-Systeme verwenden Core Web Vitals, es ist aber keine offizielle Gewichtung und kein „Tiebreaker“-Prozentsatz damit verbunden — ein guter Wert garantiert keine besseren Rankings, und Relevanz kann sich trotzdem durchsetzen. Laborwerte (Lighthouse/PSI) sind diagnostische Messungen und stimmen oft nicht mit den Felddaten überein. TTFB und FCP sind diagnostische „andere Web Vitals“; TBT und Speed Index sind Labor-Proxys.

Was als Core Web Vital zählt

Google definiert Core Web Vitals als “the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (Übersetzung) „die Teilmenge der Web Vitals, die für alle Webseiten gelten, von allen Website-Betreibern gemessen werden sollten und in allen Google-Tools ausgewiesen werden.“ Es gibt genau drei, die jeweils eine andere Dimension davon messen, wie sich eine Seite anfühlt:

Google bewertet die drei Schwellenwerte für „gut“ am 75. Perzentil: LCP bei 2,5 Sekunden, INP bei 200 Millisekunden und CLS bei 0,1. Eine Seite gilt insgesamt erst dann als „gut“, wenn alle drei ihre Marke am p75 erreichen — nicht nur eine oder zwei. Die Schwellenwerte selbst sind für Mobil und Desktop identisch, Google bewertet und berichtet jede Geräteklasse jedoch getrennt. Evidence for this claim Core Web Vitals are assessed at the 75th percentile, with good thresholds of 2.5 seconds for LCP, 200 milliseconds for INP, and 0.1 for CLS. Scope: Current stable Core Web Vitals definitions from the Chrome team. Confidence: high · Verified: 2026-07-14 web.dev: Web Vitals

Alles andere, wovon Sie gehört haben — TTFB, FCP, TBT, Speed Index —, ist kein Core Web Vital. Dazu unten mehr.

LCP — Ladezeit

LCP “reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page.” (Übersetzung) „meldet die Renderzeit des größten Bildes, Textblocks oder Videos, das im Viewport sichtbar ist, relativ zu dem Zeitpunkt, an dem der Nutzer erstmals zur Seite navigiert hat.“ In der Praxis ist das LCP-Element meist ein Hero-Bild, ein großes Hintergrundbild oder Ihr Überschriftenblock. Beachten Sie: Es ist das größte sichtbare Element — unterschiedliche Viewport-Größen können unterschiedliche LCP-Elemente haben, was einer der Gründe dafür ist, dass Feld- und Laborwerte auseinandergehen.

INP — Reaktionsfähigkeit

INP “assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (Übersetzung) „bewertet die allgemeine Reaktionsfähigkeit einer Seite auf Nutzerinteraktionen, indem die Latenz aller Klick-, Tipp- und Tastaturinteraktionen beobachtet wird, die während der gesamten Dauer des Besuchs eines Nutzers auf einer Seite auftreten.“ Gemessen wird die vollständige Interaktion: Eingabeverzögerung → Verarbeitung im Event-Handler → die Zeit bis zum Rendern des nächsten Frames.

Das ist die große Verbesserung gegenüber der Metrik, die sie ersetzt hat. INP verbessert FID, indem alle Interaktionen beobachtet werden, nicht nur die erste — FID hat lediglich die Eingabeverzögerung der allerersten Interaktion gemessen. INP wurde am 12. März 2024 zum Core Web Vital und hat First Input Delay (FID) abgelöst. Evidence for this claim INP became a Core Web Vital and replaced FID on March 12, 2024. Scope: Chrome and Google tooling transition from FID to INP. Confidence: high · Verified: 2026-07-14 web.dev: INP launch FID wurde an diesem Tag aus der Search Console entfernt. Es ist vollständig eingestellt — optimieren Sie nicht darauf.

Eine Nuance, die man sich merken sollte: INP ist nicht Ihre schlechteste einzelne Interaktion, sondern ein hohes Perzentil aller Interaktionen. Ein einzelner ruckelnder Klick ruiniert eine ansonsten gute Seite nicht.

CLS — visuelle Stabilität

CLS “is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” (Übersetzung) „ist ein Maß für den größten Ausbruch an Layout-Shift-Werten für jede unerwartete Layout-Verschiebung, die während des gesamten Lebenszyklus einer Seite auftritt.“ Der „Burst“ (Session-Fenster) fasst Verschiebungen zusammen, die innerhalb von 1 Sekunde aufeinanderfolgen, bis zu einem Gesamtfenster von 5 Sekunden. Die üblichen Verursacher, die Google nennt: “images or videos with unknown dimensions,” (Übersetzung) „Bilder oder Videos mit unbekannten Abmessungen“, “fonts that render larger or smaller than its initial fallback,” (Übersetzung) „Schriften, die größer oder kleiner gerendert werden als ihr anfänglicher Fallback“, und “third-party ads or widgets that dynamically resize themselves.” (Übersetzung) „Anzeigen oder Widgets von Drittanbietern, die ihre Größe dynamisch ändern.“

Felddaten vs. Labordaten — Messung und Diagnose

Das ist die Unterscheidung, die am meisten Verwirrung stiftet — seien Sie hier präzise.

• Felddaten (CrUX) sind “data collected from the real users visiting your site.” (Übersetzung) „Daten, die von den echten Nutzern erhoben werden, die Ihre Website besuchen.“ Sie werden am 75. Perzentil über ein rollierendes 28-Tage-Fenster berichtet, getrennt nach Mobil und Desktop. Core Web Vitals bilden diese Art von realer Nutzererfahrung ab und werden von Googles Ranking-Systemen verwendet. Sie spiegeln echte Geräte, Netzwerke, Cache-Zustände und den Back/Forward Cache wider.
• Labordaten sind “data collected in a controlled environment with predefined device and network settings” (Übersetzung) „Daten, die in einer kontrollierten Umgebung mit vordefinierten Geräte- und Netzwerkeinstellungen erhoben werden“ — ein einzelnes emuliertes Smartphone, kalter Cache, kein echter Nutzer. Lighthouse und der Laborbereich von PageSpeed Insights erzeugen solche Daten. Sie sind ein diagnostisches Werkzeug zum Finden von Problemen und keine Feldmessung. Evidence for this claim Core Web Vitals are real-world experience metrics used by Google ranking systems; lab measurements are diagnostic and can differ from field measurements. Scope: Google Search use of Core Web Vitals and Chrome UX Report field data. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search web.dev: Lab and field data

Googles eigene Empfehlung: “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” (Übersetzung) „Wenn Sie für eine bestimmte Seite sowohl Felddaten als auch Labordaten haben, sollten Sie die Felddaten nutzen, um Ihre Maßnahmen zu priorisieren.“ Und der Performance Score von Lighthouse “often does not correlate with field Core Web Vitals.” (Übersetzung) „korreliert oft nicht mit den Core Web Vitals aus dem Feld.“ Dasselbe sage ich in meinem Core-Web-Vitals-Leitfaden: Labordaten sind für das Testen und Iterieren nützlicher, weil die CWV-Felddaten auf einem rollierenden 28-Tage-Durchschnitt beruhen — Sie sehen Ihre Korrektur dort erst nach Wochen.

Die p75-Regel und warum sie wichtig ist

Eine Seite besteht nur, wenn 75 % der echten Nutzer den Schwellenwert für „gut“ erreichen. Das ist eine bewusst nachsichtige, aber reale Hürde: Die meisten Ihrer Besucher (3 von 4) hatten eine gute Erfahrung, während Sie nicht einigen wenigen Ausreißern mit miserablen Verbindungen ausgeliefert sind. Deshalb sagt es auch nichts aus, wenn Ihr Smartphone eine Ladezeit von 1,8 s anzeigt — es zählt Ihr p75 über alle Nutzer hinweg.

Seitenebene vs. Origin-Ebene — lassen Sie sich nicht täuschen

Viele Tools zeigen standardmäßig einen Wert auf Origin-Ebene (Durchschnitt der gesamten Website), der weitaus schmeichelhafter ausfallen kann als Ihre einzelnen Seiten. In meiner CWV-Datenstudie (CrUX plus 5,2 Mio. Seiten aus Ahrefs Site Audit) bestanden nur 21,2 % der einzelnen Seiten alle drei Schwellenwerte, gegenüber 33 % auf Origin-Ebene. Googles Dokumentation zur Page Experience sagt, dass seine Systeme Seiten in der Regel einzeln bewerten, daneben aber auch breitere Website-weite Bewertungen vornehmen — ein Origin, der „besteht“, kann also immer noch reichlich durchfallende Einzelseiten verbergen. Wenn ein Tool beide Sichten anbietet, gehen Sie nicht davon aus, dass der Durchschnitt auf Origin-Ebene Ihnen sagt, wie eine bestimmte Seite abschneidet; prüfen Sie auch den Wert auf Seitenebene.

Ein verwandter Fallstrick: Seiten ohne ausreichenden Traffic haben überhaupt keine CrUX-Felddaten, und CrUX umfasst nur Chrome-Nutzer, die der Erhebung von Nutzungsstatistiken zugestimmt haben (kein Chrome unter iOS, keine anderen Browser). Das ist eine Lücke bei der Datenberechtigung und kein Durchfallen — fehlende Felddaten sind nicht dasselbe wie ein schlechter Wert. Wie genau ein bestimmtes Tool ähnliche Seiten gruppiert oder für URLs mit wenig Traffic auf Ersatzwerte zurückgreift (PSI, Search Console, die CrUX-API), dokumentiert das jeweilige Produkt und nicht eine universelle Regel.

Wie viel zählen Core Web Vitals tatsächlich fürs Ranking?

Sie sind ein bestätigtes Ranking-Signal — Google sagt, dass seine Ranking-Systeme Core Web Vitals verwenden. Was Googles aktuelle Dokumentation nicht tut: diesem Signal eine offizielle Gewichtung, einen Prozentsatz oder das Etikett „Tiebreaker“ zuschreiben. Seien Sie also vorsichtig damit, solche Formulierungen zu wiederholen, als wären es Googles eigene Worte.

Für die Seite „es ist real“: Googles Dokumentation sagt, Core Web Vitals “along with other page experience aspects, aligns with what our core ranking systems seek to reward,” (Übersetzung) „stimmen zusammen mit anderen Aspekten der Page Experience mit dem überein, was unsere Kern-Ranking-Systeme zu belohnen suchen“, und John Mueller erklärte öffentlich, es sei “more than a tie-breaker, but it also doesn’t replace relevance.” (Übersetzung) „mehr als ein Tiebreaker, ersetzt aber auch die Relevanz nicht.“

Für die Seite „übertreiben Sie es nicht“: Mueller sagte außerdem “Core Web Vitals are not giant factors in ranking, and I doubt you’d see a big drop just because of that,” (Übersetzung) „Core Web Vitals sind keine gigantischen Faktoren im Ranking, und ich bezweifle, dass Sie allein deswegen einen großen Absturz sehen würden“, und beim Dokumentations-Update im März 2024 ergänzte er über LinkedIn, “it’s not going to make your site’s rankings jump up.” (Übersetzung) „Das wird die Rankings Ihrer Website nicht nach oben springen lassen.“ Googles eigene Page-Experience-Dokumentation wird deutlich: “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” (Übersetzung) „Die Google-Suche versucht immer, den relevantesten Inhalt zu zeigen, selbst wenn die Page Experience mangelhaft ist.“ Die Dokumentation von 2024 warnt sogar, dass “trying to get a perfect score just for SEO reasons may not be the best use of your time.” (Übersetzung) „der Versuch, allein aus SEO-Gründen einen perfekten Wert zu erreichen, möglicherweise nicht die beste Nutzung Ihrer Zeit ist.“ Evidence for this claim Google says Core Web Vitals are used by ranking systems, while page experience does not override more relevant content. Scope: Google Search ranking guidance; no fixed weight or ranking-position effect is promised. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search Google: Page experience

Meine pragmatische Einschätzung: Relevanz dominiert, Google hat nie beziffert, wie stark CWV zählen, und die meisten Websites werden davon fürs Ranking keinen großen Nutzen sehen. Die zugrunde liegenden UX-Verbesserungen lohnen sich dennoch für Nutzer und Conversions — und Plattformen (WordPress, Cloudflare, Frameworks) nehmen laufend einen großen Teil der Optimierungsarbeit automatisch ab. Gerade für kleine und lokale Unternehmen sollte das normalerweise nicht ganz oben auf der Liste stehen.

Noch eine Klarstellung aus dem Update von 2024: Von den breiteren Signalen der Page Experience ist nur für Core Web Vitals bestätigt, dass sie direkt zum Ranking beitragen. HTTPS, Mobilfreundlichkeit, keine störenden Interstitials, inhaltliche Klarheit — alles gute Praxis, aber sie verbessern das Ranking nicht direkt so, wie die Dokumentation es früher nahegelegt hat.

Die „anderen Web Vitals“ — diagnostisch, nicht Core

Diese kommen ständig auf und werden falsch einsortiert. Keine davon ist ein Core Web Vital:

• Time to First Byte (TTFB) — wie lange es dauert, bis das erste Byte der Antwort eintrifft. Sie “precedes every other meaningful loading performance metric” (Übersetzung) „geht jeder anderen aussagekräftigen Lade-Performance-Metrik voraus“ und fließt in LCP ein, aber Google stellt klar: “Because TTFB isn’t a Core Web Vitals metric, it’s not absolutely necessary that sites meet the ‘good’ TTFB threshold.” (Übersetzung) „Da TTFB keine Core-Web-Vitals-Metrik ist, ist es nicht zwingend notwendig, dass Websites den Schwellenwert ‚gut‘ für TTFB einhalten.“ (Gut ist ≤ 0,8 s.) Diagnostisch.
• First Contentful Paint (FCP) — die Zeit, bis irgendein Inhalt gerendert wird. Eine nützliche Lade-Diagnose (gut ist ≤ 1,8 s), aber nicht Core.
• Total Blocking Time (TBT) — ein Labor-Proxy für INP. Tools wie Lighthouse “cannot measure INP” (Übersetzung) „können INP nicht messen“ ohne einen echten Nutzer, daher berichten sie stattdessen TBT. Nur Labor.
• Speed Index — ein Labor-Proxy für die wahrgenommene Ladegeschwindigkeit. Nur in Lighthouse.

Nutzen Sie diese zum Debuggen. Melden Sie diese nicht als Core Web Vitals und behandeln Sie ihre Schwellenwerte nicht als Ranking-Hürden.

Ein Mythos, der verschwinden sollte

Möglicherweise begegnet Ihnen „Engagement Reliability“ als angeblich neues Core Web Vital. Es gibt keine offizielle Ankündigung von Google für eine solche Metrik — sie zirkuliert ausschließlich in Inhalten von Drittanbietern. Die Core Web Vitals sind LCP, INP und CLS. Bis Google etwas anderes sagt, ist das die Liste.

Wie man misst — und welches Tool wofür

Passen Sie das Tool zur Aufgabe an:

• Ranking-relevant (Felddaten): PageSpeed Insights (zeigt CrUX-Felddaten auf Seiten- und Origin-Ebene), der Core-Web-Vitals-Bericht der Google Search Console (gruppiert ähnliche Seiten, zeigt Website-weite Muster), die CrUX-API / BigQuery (individuelle Analysen und Auswertungen auf Länderebene) und die JavaScript-Bibliothek web-vitals (erheben Sie Ihre eigenen RUM-Daten).
• Debugging (Labordaten): Lighthouse, das Performance-Panel der Chrome DevTools und der Laborbereich von PSI. Diese finden die Ursache; sie entscheiden nicht über Ihr Ranking.

Der Workflow, den ich vorschlagen würde: Nutzen Sie GSC, um zu finden, welche Seitengruppen im Feld durchfallen, bestätigen Sie das mit PageSpeed Insights auf Seitenebene und steigen Sie dann in Lighthouse / DevTools ein, um zu diagnostizieren und zu iterieren — im Wissen, dass sich die Feldwerte bis zu 28 Tage lang nicht aktualisieren.

Wie es weitergeht: der Cluster zur Web-Performance

Dieser Hub ist die Landkarte. Jedes Thema unten ist ein eigener vertiefender Artikel.

Die drei Core Web Vitals

• Largest Contentful Paint — die Lade-Metrik: was als LCP-Element zählt, das Ziel von ≤ 2,5 s und wie man es früher rendern lässt.
• Interaction to Next Paint — die Metrik für Reaktionsfähigkeit, die FID abgelöst hat: Eingabeverzögerung, Event-Verarbeitung und Darstellungsverzögerung und wie man jede davon reduziert.
• Cumulative Layout Shift — die Metrik für visuelle Stabilität: Session-Fenster, die üblichen Ursachen (Medien ohne Größenangabe, Schriften, nachgeladene Anzeigen) und wie man ≤ 0,1 erreicht.

Unterstützende und diagnostische Metriken

• Time to First Byte — Server-/Antwortlatenz, die in LCP einfließt; nützlich zum Debuggen, aber kein Core Web Vital.
• First Contentful Paint — wann der erste Inhalt gerendert wird; eine Lade-Diagnose.
• Total Blocking Time — der Labor-Proxy, mit dem Lighthouse INP annähert.
• Speed Index — der Labor-Proxy für die wahrgenommene Ladegeschwindigkeit.

Wie sie gemessen werden

• PageSpeed Insights — Felddaten (CrUX) plus ein Lighthouse-Laborbericht an einem Ort.
• Google Lighthouse — die Labor- und Diagnose-Engine hinter PSI und den DevTools.
• Chrome UX Report (CrUX) — der Datensatz echter Nutzer, auf dem Googles Bewertung läuft.

Für den gesamten Cluster siehe den Hub zur Web-Performance. Jeder Schwesterartikel verlinkt automatisch hierher, sobald er erscheint.

KI-Zusammenfassung

Eine verdichtete Fassung der Advanced-Version:

• Core Web Vitals = drei Feldmetriken: LCP (Ladezeit, gut bei ≤ 2,5 s), INP (Reaktionsfähigkeit, ≤ 200 ms), CLS (visuelle Stabilität, ≤ 0,1). Alles andere (TTFB, FCP, TBT, Speed Index) ist kein Core.
• Bewertet anhand von Felddaten: echte Chrome-Nutzer über CrUX, am 75. Perzentil, über ein rollierendes 28-Tage-Fenster. Die Schwellenwerte sind für Mobil/Desktop identisch, werden aber getrennt bewertet, und Google erwartet, dass alle drei Metriken gut sind, nicht nur eine.
• INP hat FID am 12. März 2024 abgelöst. FID ist vollständig eingestellt; INP misst alle Interaktionen, nicht nur die erste.
• Labor-Tools (Lighthouse/PSI) sind diagnostisch, keine Feldmessungen, und stimmen oft nicht mit den CWV aus dem Feld überein. Nutzen Sie die Tools, um Ursachen zu finden; Feldwerte hinken bis zu 28 Tage hinterher.
• Seitenebene vs. Origin-Ebene ist wichtig: ~21,2 % der Seiten bestehen gegenüber ~33 % der Origins (meine CWV-Studie). Google nutzt die Seitenebene — Origin-Durchschnitte verbergen durchfallende Seiten.
• Ranking-Gewicht: verwendet, aber ungewichtet. Google sagt, seine Ranking-Systeme verwenden Core Web Vitals, ohne dass ein offizieller Prozentsatz oder das Etikett „Tiebreaker“ damit verbunden wäre; Relevanz dominiert, und ein guter Wert ist keine Ranking-Garantie. Mueller: “not giant factors in ranking.” (Übersetzung) „keine gigantischen Faktoren im Ranking.“ Laut der Dokumentation von 2024 tragen nur CWV (nicht HTTPS, Mobilfreundlichkeit, Interstitials) direkt bei.
• Mythos zum Überspringen: „Engagement Reliability“ ist kein bestätigtes Core Web Vital.
• Tooling: Feld = PSI, GSC-CWV-Bericht, CrUX-API, web-vitals.js; Debugging = Lighthouse, DevTools, PSI-Laborbereich.

Offizielle Dokumentation

Dokumentation aus erster Hand von Google.

web.dev (Chrome-Team)

• Web Vitals — die Initiative, die drei Metriken, die p75-Regel und warum TTFB/FCP „andere“ Web Vitals sind.
• Largest Contentful Paint (LCP) — Definition, Schwellenwerte und infrage kommende LCP-Elemente.
• Interaction to Next Paint (INP) — Definition, Schwellenwerte und die Aufschlüsselung in Eingabeverzögerung → Verarbeitung → Darstellung.
• Cumulative Layout Shift (CLS) — Definition, Session-Fenster und häufige Ursachen.
• Definition der Schwellenwerte für die Core-Web-Vitals-Metriken — warum die jeweiligen Schwellenwerte für „gut“ und das 75. Perzentil gewählt wurden.
• Unterschiede zwischen Labor- und Felddaten — warum Feldwerte (CrUX) und Laborwerte (Lighthouse) auseinandergehen.
• Workflows und Tools für Core Web Vitals — welches Tool Feld- und welches Labordaten berichtet.
• INP wird zu Core Web Vitals weiterentwickelt (Mai 2023) — die Ankündigung, dass INP FID ersetzen würde.
• Interaction to Next Paint ist am 12. März 2024 offiziell ein Core Web Vital — die Bestätigung des Starts.
• TTFB und FCP — die diagnostischen „anderen Web Vitals“.

Google Search Central

• Core Web Vitals und Google-Suchergebnisse verstehen — wie CWV mit dem Ranking zusammenhängen.
• Page Experience in den Google-Suchergebnissen verstehen — das breitere Bild der Page Experience und die Einordnung „Relevanz gewinnt“.
• INP in Core Web Vitals einführen (Mai 2023) — die Ankündigung bei Search Central.

Chrome für Entwickler

• Chrome-Nutzererfahrungsbericht (CrUX) — der Datensatz echter Nutzer, die Voraussetzungen für die Aufnahme und das 28-Tage-Fenster.

Zitate aus der Quelle

Offizielle Aussagen von Google. Jeder Link ist ein Deeplink, der zur zitierten Passage auf der Quellseite springt.

Google — was Core Web Vitals sind

• “Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (Übersetzung) „Core Web Vitals sind die Teilmenge der Web Vitals, die für alle Webseiten gelten, von allen Website-Betreibern gemessen werden sollten und in allen Google-Tools ausgewiesen werden.“ — Philip Walton, web.dev. Zum Zitat springen
• “LCP reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page.” (Übersetzung) „LCP meldet die Renderzeit des größten Bildes, Textblocks oder Videos, das im Viewport sichtbar ist, relativ zu dem Zeitpunkt, an dem der Nutzer erstmals zur Seite navigiert hat.“ — web.dev (LCP). Zum Zitat springen
• “INP is a metric that assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (Übersetzung) „INP ist eine Metrik, welche die allgemeine Reaktionsfähigkeit einer Seite auf Nutzerinteraktionen bewertet, indem sie die Latenz aller Klick-, Tipp- und Tastaturinteraktionen beobachtet, die während der gesamten Dauer des Besuchs eines Nutzers auf einer Seite auftreten.“ — web.dev (INP). Zum Zitat springen
• “CLS is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” (Übersetzung) „CLS ist ein Maß für den größten Ausbruch an Layout-Shift-Werten für jede unerwartete Layout-Verschiebung, die während des gesamten Lebenszyklus einer Seite auftritt.“ — web.dev (CLS). Zum Zitat springen

Google — INP ersetzt FID

• “Interaction to Next Paint (INP) is now a stable Core Web Vital metric, replacing First Input Delay (FID).” (Übersetzung) „Interaction to Next Paint (INP) ist jetzt eine stabile Core-Web-Vital-Metrik und ersetzt First Input Delay (FID).“ — Rick Viscomi, web.dev (12. März 2024). Zum Zitat springen

Google — Feld vs. Labor und Ranking

• “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” (Übersetzung) „Wenn Sie für eine bestimmte Seite sowohl Felddaten als auch Labordaten haben, sollten Sie die Felddaten nutzen, um Ihre Maßnahmen zu priorisieren.“ — Philip Walton, web.dev. Zum Zitat springen
• “The Chrome User Experience Report (also known as the Chrome UX Report, or CrUX for short) is a dataset that reflects how real-world Chrome users experience popular destinations on the web.” (Übersetzung) „Der Chrome User Experience Report (auch bekannt als Chrome UX Report oder kurz CrUX) ist ein Datensatz, der abbildet, wie echte Chrome-Nutzer beliebte Ziele im Web erleben.“ — Chrome for Developers (CrUX-Dokumentation). Zum Zitat springen

John Mueller, Google

• “It is a ranking factor, and it’s more than a tie-breaker, but it also doesn’t replace relevance.” (Übersetzung) „Es ist ein Ranking-Faktor, und es ist mehr als ein Tiebreaker, aber es ersetzt auch die Relevanz nicht.“ — über Search Engine Journal (Reddit, August 2021). Zur Berichterstattung
• “Core Web Vitals are not giant factors in ranking, and I doubt you’d see a big drop just because of that.” (Übersetzung) „Core Web Vitals sind keine gigantischen Faktoren im Ranking, und ich bezweifle, dass Sie allein deswegen einen großen Absturz sehen würden.“ — über Stan Ventures (2024). Zur Berichterstattung

Core-Web-Vitals-Checkliste

Ein schneller Durchgang, um zu bestätigen, dass Sie das Richtige messen und die richtigen Seiten korrigieren:

• Sie lesen Felddaten (CrUX) und nicht nur einen Laborwert für die Metriken, auf deren Basis Google rankt.
• Sie sehen sich Werte auf Seitenebene an, nicht nur den Durchschnitt auf Origin-Ebene.
• Alle drei werden geprüft: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 am p75.
• Mobil und Desktop werden getrennt geprüft (Google bewertet beides einzeln).
• Sie optimieren nicht auf FID — es wurde am 12. März 2024 eingestellt (nutzen Sie INP).
• Der Core-Web-Vitals-Bericht der GSC wurde auf durchfallende Seitengruppen geprüft, nicht auf Einzelfälle.
• Ihnen ist klar, dass Seiten mit wenig Traffic möglicherweise überhaupt keine CrUX-Felddaten haben.
• Labor-Tools (Lighthouse/PSI) werden zum Diagnostizieren genutzt und nicht als Bestanden-/Nicht-bestanden-Hürde — und Sie warten nicht auf einen perfekten Performance Score.
• Sie räumen bis zu 28 Tage ein, bis sich Korrekturen im Feld zeigen.
• Sie jagen CWV nicht vor inhaltlicher Relevanz und größeren SEO-Gewinnen hinterher.

Die mentalen Modelle

1. Drei Dimensionen, drei Metriken. LCP = Ladezeit, INP = Reaktionsfähigkeit, CLS = visuelle Stabilität. Wenn Sie benennen können, in welcher Dimension ein Problem liegt, wissen Sie, welche Metrik (und welchen vertiefenden Artikel) Sie öffnen müssen.

2. Das Feld ist fürs Ranking, das Labor fürs Beheben. Google rankt anhand von CrUX-Felddaten am p75 über 28 Tage. Laborwerte aus Lighthouse/PSI finden Ursachen. Behandeln Sie einen Laborwert nie als Ihre Ranking-Zahl — die beiden korrelieren oft nicht einmal.

3. Seitenebene schlägt Origin-Ebene. Ein Origin, der „besteht“, kann durchfallende Seiten verbergen. Google nutzt Daten auf Seitenebene, wo sie vorliegen. Wenn ein Tool beides zeigt, vertrauen Sie der Sicht auf Seitenebene.

4. Verwendet, aber ungewichtet. CWV sind ein bestätigtes Ranking-Signal, dem Google nie eine offizielle Gewichtung zugeordnet hat — Relevanz kann es weiterhin überstimmen. Beheben Sie CWV für Nutzer und Conversions; erwarten Sie keine Ranking-Sprünge.

5. Der Test „ist das überhaupt Core?“ Nur LCP, INP und CLS sind Core Web Vitals. TTFB und FCP sind diagnostisch; TBT und Speed Index sind Labor-Proxys. „Engagement Reliability“ ist überhaupt nicht bestätigt.

Core Web Vitals — Spickzettel

Die drei Core Web Vitals (Felddaten, p75)

Diagnostische Metriken — KEINE Core Web Vitals

Schnelle Fakten

• Bewertung = CrUX-Felddaten, 75. Perzentil, rollierendes 28-Tage-Fenster, Mobil und Desktop getrennt.
• INP hat FID am 12. März 2024 abgelöst. FID ist vollständig eingestellt.
• Laborwerte (Lighthouse/PSI) sind diagnostisch, keine Feldmessungen — und stimmen oft nicht mit den CWV aus dem Feld überein.
• Google nutzt die Seitenebene; Durchschnitte auf Origin-Ebene können in die Irre führen (~21,2 % der Seiten bestehen gegenüber ~33 % der Origins in meiner CWV-Studie).
• Ranking-Gewicht: von Googles Ranking-Systemen verwendet, keine offizielle Gewichtung genannt — Relevanz dominiert, und ein guter Wert ist keine Garantie.
• „Engagement Reliability“ ist kein bestätigtes Core Web Vital.

Welches Core Web Vital sollte ich zuerst untersuchen?

Core Web Vitals verschlechtern sich nach einem Release

1. Bestätigen Sie das Signal. Trennen Sie Feld von Labor, URL von Origin und Mobil von Desktop. Wenn sich nur ein einzelner Laborlauf verändert hat, reproduzieren Sie ihn, bevor Sie einen Incident ausrufen.
2. Identifizieren Sie das betroffene Vital. LCP, INP und CLS stehen für unterschiedliche Probleme. Wenn sich mehrere bewegt haben, prüfen Sie zuerst gemeinsame Release-Änderungen und Drittanbieter-Skripte.
3. Verknüpfen Sie die Verschlechterung mit einem Deployment. Vergleichen Sie RUM oder wiederholbare Labor-Traces vor und nach dem Release. Wenn das zeitlich nicht zusammenpasst, prüfen Sie stattdessen den Traffic- und Gerätemix.
4. Diagnostizieren Sie die Metrik, nicht den Score. Bei LCP prüfen Sie Element und Teilabschnitte; bei INP langsame Interaktionen und Arbeit im Main Thread; bei CLS die Quellen der Verschiebungen.
5. Liefern Sie die kleinste zuordenbare Korrektur aus. Validieren Sie die Korrektur sofort im Labor. Wenn sie Funktionalität beschädigt oder ein anderes Vital verschlechtert, rollen Sie zurück.
6. Beobachten Sie echte Nutzer. Nutzen Sie RUM als führendes Signal und CrUX/Search Console für das rollierende Feldurteil. Dokumentieren Sie Umfang und Zeitfenster, damit Stakeholder kein Zurücksetzen von CrUX am selben Tag erwarten.

Core-Web-Vitals-Fehler, die Arbeit verschwenden

Den zusammengesetzten Lighthouse-Score optimieren

Googles Feldbewertung nutzt LCP, INP und CLS aus Daten echter Nutzer, nicht die einzelne Lighthouse-Performance-Zahl. Diagnostizieren Sie die durchfallende Feldmetrik und nutzen Sie Lighthouse als eine kontrollierte Debugging-Umgebung.

Core Web Vitals als Ranking-Abkürzung behandeln

CWV sind ein Page-Experience-Signal, dem Google nie eine offizielle Gewichtung zugewiesen hat; Relevanz dominiert weiterhin. Beheben Sie schlechte Erfahrungen für Nutzer, versprechen Sie aber keinen Ranking-Sprung und verdrängen Sie ohne Belege keine wichtigere Arbeit an Inhalten und Indexierung.

URL-, Origin-, Mobil- und Desktop-Werte vermischen

Unterschiedliche Betrachtungsebenen können unterschiedliche Geschichten erzählen. Kennzeichnen Sie jeden Wert und behaupten Sie nicht, eine Seite bestehe, weil ein Origin-Ersatzwert oder ein Desktop-Aggregat grün ist.

Auf CrUX warten, bevor ein Release geprüft wird

Das rollierende 28-Tage-Fenster ist für die QA eines Deployments zu langsam. Validieren Sie den Mechanismus sofort im Labor und über RUM und nutzen Sie CrUX anschließend, um das längerfristige Feldergebnis zu bestätigen.

Tools zum Messen der Core Web Vitals

Prüfen Sie es mit dem Core Web Vitals History & Competitor Comparison:

1. Fügen Sie eine Website hinzu (ein blanker Origin wie example.com hat die meisten CrUX-Daten; fügen Sie bis zu 5 hinzu, um zu vergleichen).
2. Wählen Sie Mobil oder Desktop und starten Sie dann den Vergleich.
3. Lesen Sie die Scorecard für das heutige Bestanden/Nicht bestanden bei LCP, INP und CLS und anschließend das Wochentrend-Diagramm, um zu sehen, ob sich jede Metrik auf den guten Bereich zubewegt oder sich davon entfernt.

Felddaten — Messung der Core Web Vitals bei echten Nutzern

• PageSpeed Insights — CrUX-Felddaten auf Seiten- und Origin-Ebene, dazu ein Lighthouse-Laborbericht daneben.
• Google Search Console — Core-Web-Vitals-Bericht — gruppiert ähnliche Seiten und zeigt Website-weite Feldmuster; der schnellste Weg, durchfallende Seitengruppen zu finden.
• CrUX-API / BigQuery — individuelle Analysen und Auswertungen auf Länderebene direkt aus dem Quelldatensatz.
• JavaScript-Bibliothek web-vitals — erheben Sie Ihre eigenen Daten echter Nutzer (RUM) und leiten Sie diese etwa in Ihre Analytics weiter.

Labordaten — zum Debuggen (nicht fürs Ranking)

• Lighthouse — diagnostische Ansatzpunkte und der (nicht ranking-relevante) Performance Score.
• Performance-Panel der Chrome DevTools — Debugging auf Trace-Ebene für LCP, Layout-Verschiebungen und Long Tasks.
• Laborbereich von PageSpeed Insights — die von Lighthouse gespeisten Empfehlungen unterhalb der Felddaten.

Faustregel: GSC, um zu finden, wo Sie im Feld durchfallen → PSI, um es auf Seitenebene zu bestätigen → Lighthouse / DevTools, um zu diagnostizieren und zu iterieren.

Ressourcen, die Ihre Zeit wert sind

Meine verwandten Texte

• Core Web Vitals: So lassen sie sich verbessern (Ahrefs) — mein vollständiger Praxisleitfaden zu den drei Metriken und dem, was zu beheben ist.
• Datenstudie zu Core Web Vitals (Ahrefs) — CrUX + 5,2 Mio. Seiten; der Befund zur Bestehensquote auf Seiten- gegenüber Origin-Ebene.
• Leitfaden zu Largest Contentful Paint (LCP).
• Leitfaden zu Cumulative Layout Shift (CLS).
• Leitfaden zu PageSpeed Insights.
• Technische SEO: Einsteigerleitfaden — wo die Page Experience im größeren Bild steht.

Offiziell

• web.dev — Web Vitals und die Artikel zu den einzelnen Metriken, die unter Offizielle Dokumentation verlinkt sind.
• Google updates its page experience docs to clarify ranking signals (Search Engine Land) — Barry Schwartz über die Dokumentationsänderung vom März 2024.

Aus der Branche

• Google Core Web Vitals als Rankingfaktor: mehr als ein Tiebreaker (Search Engine Journal) — Berichterstattung zu John Muellers Reddit-Aussage, CWV seien „mehr als ein Tiebreaker“, ersetzten aber die Relevanz nicht.
• Priorität von Core Web Vitals für kleine/lokale Unternehmen (Search Engine Roundtable) — Muellers Mastodon-Kommentar, dass CWV-Arbeit für kleine und lokale Unternehmen keine Top-Priorität sein sollte.
• Bestätigt: Core Web Vitals sind kein großer Rankingfaktor (Stan Ventures) — Muellers Zitat „not giant factors in ranking“ im Kontext.
• Auswirkungen von Core Web Vitals auf SEO (RUMvision) — aktualisiert im November 2025; gründliche Zusammenstellung von Aussagen der Google-Vertreter und Nuancen zum Ranking-Signal im FAQ-Stil.
• Google-Page-Experience-Update: Tiebreaker (Search Engine Roundtable) — frühe Tiebreaker-Einordnung von Mueller und Illyes aus der Zeit vor dem Start des Updates.

Zahlen, die sich zu zitieren lohnen

• Nur ~21,2 % der einzelnen Seiten bestehen alle drei Core Web Vitals — gegenüber ~33 % auf Origin-Ebene — aus meiner CWV-Datenstudie (CrUX + 5,2 Mio. Seiten aus Ahrefs Site Audit). Googles Systeme bewerten Seiten in der Regel einzeln, ein schmeichelhafter Durchschnitt auf Origin-Ebene kann also immer noch reichlich durchfallende Seiten verbergen. Quelle
• Am meisten kämpfen Websites mit LCP. Diese Studie fand, dass Websites beim alten FID und bei CLS Fortschritte machten, bei LCP aber zurückblieben — und “almost no sites on 3G or slower connections are passing.” (Übersetzung) „nahezu keine Website auf 3G oder langsameren Verbindungen besteht.“ Quelle
• Die Schwellenwerte für „gut“: LCP ≤2,5 s, INP ≤200 ms, CLS ≤0,1, jeweils am 75. Perzentil der Felddaten — Googles dokumentierte Core-Web-Vitals-Ziele. Quelle
• INP hat FID am 12. März 2024 abgelöst — das Datum, an dem FID aufhörte, ein Core Web Vital zu sein, und aus der Search Console entfernt wurde. Quelle

Testen Sie sich: Core Web Vitals

Fünf kurze Fragen zu Core Web Vitals. Wählen Sie jeweils eine Antwort und prüfen Sie dann.

Belegen, dass eine LCP-/INP-/CLS-Korrektur tatsächlich gewirkt hat

Die Falle bei einer Performance-Korrektur ist, den Laborwert am Tag des Ausrollens zu feiern. Das Labor (Lighthouse) sagt Ihnen, ob die Änderung wirken kann; nur Felddaten (CrUX) sagen Ihnen, ob sie für echte Nutzer gewirkt hat — und die bewegen sich mit einer rollierenden Verzögerung von 28 Tagen. Führen Sie beides aus, in dieser Reihenfolge.

Test 1 — Die Korrektur hat die Labormetrik verbessert

• Durchzuführender Test — Lassen Sie die Seite vor und nach der Änderung durch den Core Web Vitals Checker (oder Lighthouse / PageSpeed Insights) laufen.
• Erwartetes Ergebnis — Die adressierte Labormetrik bewegt sich in die richtige Richtung — das LCP-Element rendert etwa früher, es entsteht keine neue Layout-Verschiebung, die konkrete Diagnose, die Sie behoben haben, ist bereinigt.
• Deutung eines Fehlschlags — Keine Bewegung im Labor bedeutet, dass die Änderung den kritischen Pfad nicht berührt hat (Sie haben ein Element optimiert, das nicht das LCP-Element war, oder ein Skript, das nicht blockierend war).
• Beobachtungsfenster — Sofort — Labortests laufen auf Abruf.
• Rollback-Auslöser — Eine Verschlechterung bei einer anderen Metrik (Sie haben LCP behoben, aber CLS eingeführt, oder JS ergänzt, das INP schadet) — das Labor fängt das ab, bevor echte Nutzer es merken.

Test 2 — Echte Nutzer spüren es tatsächlich (Felddaten)

• Durchzuführender Test — Verfolgen Sie den p75 der Seite bzw. des Origins für LCP, INP und CLS in CrUX — über Verlauf und Wettbewerbsvergleich der Core Web Vitals oder den Core-Web-Vitals-Bericht der GSC.
• Erwartetes Ergebnis — Der p75 der korrigierten Metrik wechselt in den Bereich „Gut“ und bleibt dort (Googles Schwellenwerte: LCP ≤ 2,5 s, INP ≤ 200ms, CLS ≤ 0,1).
• Deutung eines Fehlschlags — Das Labor hat sich verbessert, das Feld nicht — die Korrektur half einem Test mit schneller Verbindung, aber nicht dem realen Geräte- und Netzwerkmix, oder zu wenige URLs der Gruppe haben die Korrektur erhalten.
• Beobachtungsfenster — rollierende 28 Tage — CrUX ist ein nachlaufendes 28-Tage-Fenster, eine Korrektur braucht also rund 4 Wochen angesammelter Felddaten, bevor der p75 belastbar ist. Beurteilen Sie es nicht in Woche eins.
• Rollback-Auslöser — Der p75 rutscht zurück über den Schwellenwert „schlecht“, oder die Zahl der „guten“ URLs in der GSC fällt nach einer Template-Änderung — ein starkes Zeichen dafür, dass das Deployment die Performance für echte Nutzer verschlechtert hat.

Der dauerhafte KPI für dieses Thema

Unabhängig davon, ob eine einzelne Korrektur validiert wird, ist das der Wert, den Sie Quartal für Quartal beobachten, um zu wissen, ob die Page Experience gesund ist. Es gibt hier einen belastbaren Benchmark — Google veröffentlicht die Schwellenwerte —, es sind also keine Zahlen erfunden.

p75 von LCP, INP und CLS (Felddaten)

• Metrik — Der Wert am 75. Perzentil jedes Core Web Vital über echte Besuche hinweg, je Seitengruppe und Gerät.
• Was sie Ihnen sagt — Ob 75 % der echten Nutzer eine gute Erfahrung haben — genau die Hürde, die Google nutzt, um eine URL als bestanden einzustufen. Der p75 (und nicht der Durchschnitt) ist die maßgebliche Zahl, weil er den langsameren Long Tail abbildet.
• Wie Sie den Wert erheben — CrUX über Verlauf und Wettbewerbsvergleich der Core Web Vitals, den Core-Web-Vitals-Bericht der GSC (Felddaten gruppiert nach URL-Muster) oder PageSpeed Insights für eine einzelne URL.
• Benchmark / realistischer Bereich — Googles eigene Schwellenwerte: LCP ≤ 2,5 s, INP ≤ 200ms, CLS ≤ 0,1 für „Gut“; die Bereiche „Verbesserungswürdig“ / „Schlecht“ sind 2,5–4 s / >4 s, 200–500ms / >500ms und 0,1–0,25 / >0,25. Das sind die veröffentlichten Linien, kein erfundenes Ziel.
• Takt — rollierende 28 Tage, prüfen Sie also monatlich — eine tägliche Prüfung liest nur dasselbe nachlaufende Fenster erneut. Behandeln Sie Laborwerte als führenden und den CrUX-p75 als nachlaufenden Indikator.

Abdeckung mit „guten URLs“ über die Website hinweg

• Metrik — Der Anteil Ihrer indexierten URLs im Bereich „Gut“ des Core-Web-Vitals-Berichts der GSC (Mobil und Desktop getrennt erfasst).
• Was sie Ihnen sagt — Wie breit sich die Korrekturen verteilt haben — eine einzelne schnelle Seite bewegt die Website nicht; Erfolge auf Template-Ebene tun es.
• Wie Sie den Anteil erheben — GSC → Core-Web-Vitals-Bericht → Anzahl der URLs in Gut / Verbesserungswürdig / Schlecht im Zeitverlauf.
• Benchmark / realistischer Bereich — Situationsabhängig — es hängt von Ihren Templates und Ihrem Traffic-Mix ab. Etablieren Sie also Ihre eigene Baseline und treiben Sie den Anteil „Gut“ über die Zeit nach oben, statt einem erfundenen Prozentsatz hinterherzujagen.
• Takt — monatlich, oder wöchentlich unmittelbar nach einer Template- bzw. Theme-Änderung, während das Feldfenster nachzieht.

Änderungsprotokoll