Page Experience Metrics: Core Web Vitals richtig verstehen

Kurzdefinition

Page Experience Metrics sind Messwerte für die Frage, wie gut sich eine Seite für echte Menschen anfühlt: lädt der Hauptinhalt schnell, bleibt das Layout ruhig, reagieren Buttons und Menüs ohne spürbare Verzögerung, ist die Seite mobil nutzbar, sicher und frei von störenden Unterbrechungen? Im SEO-Kontext sind die Core Web Vitals die bekannteste Teilmenge: Largest Contentful Paint, Interaction to Next Paint und Cumulative Layout Shift.

Wichtig ist die Einordnung: Page Experience ersetzt nicht Relevanz, Suchintention oder hilfreichen Inhalt. Google beschreibt selbst, dass gute Page Experience ein Erfolgsfaktor sein kann, aber nicht allein gewinnt, wenn der Inhalt die Suchaufgabe nicht löst. Für Teams ist Page Experience deshalb kein technisches Nebenthema, sondern der Teil der Content-Qualität, den Nutzer im Browser körperlich spüren.

Ordne Nutzungsmessungen in den technischen Audit-Ablauf ein und prüfe anschließend, ob die Korrektur die tatsächliche Bedienung verbessert.

Begriffe auf dieser Seite

• Page Experience Signal
• Largest Contentful Paint, kurz LCP
• Cumulative Layout Shift, kurz CLS
• Interaction to Next Paint, kurz INP
• First Input Delay, kurz FID, heute deprecated
• First Contentful Paint, kurz FCP
• Time to First Byte, kurz TTFB
• Total Blocking Time, kurz TBT
• Speed Index
• Layout Stability
• Input Latency
• Perceived Performance
• Performance API for Core Web Vitals Monitoring

Einfach erklärt

Eine Seite kann inhaltlich stark sein und sich trotzdem schlecht anfühlen. Vielleicht erscheint die Überschrift schnell, aber das Hero-Bild kommt spät. Vielleicht springt ein Button nach unten, weil ein Werbeplatz nachgeladen wird. Vielleicht tippt ein Nutzer auf ein Menü und die Seite reagiert erst nach einer halben Sekunde, weil zu viel JavaScript den Hauptthread blockiert. Genau solche Momente versuchen Page Experience Metrics sichtbar zu machen.

Die Core Web Vitals decken drei Grundfragen ab. LCP fragt: Wann ist der wichtigste sichtbare Inhalt da? INP fragt: Wie schnell reagiert die Seite auf Interaktionen während des Besuchs? CLS fragt: Wie stabil bleibt das Layout? Diese drei Werte werden in Felddaten gemessen und sollten am 75. Perzentil gut sein, getrennt nach Mobile und Desktop. Das ist wichtig, weil Durchschnittswerte schön aussehen können, während ein großer Teil echter Nutzer noch leidet.

Unterstützende Metriken helfen bei der Diagnose. FCP zeigt, wann überhaupt etwas sichtbar wird. TTFB zeigt, ob der Server und die Auslieferung früh bremsen. TBT zeigt im Lab, ob lange JavaScript-Aufgaben Interaktion blockieren können. Speed Index beschreibt, wie schnell der sichtbare Bereich wahrgenommen voll wird. Diese Werte sind nicht alle Ranking-Signale, aber sie helfen, das richtige Problem zu finden.

Warum das Thema oft falsch verstanden wird

Der erste Fehler ist Score-Denken. Ein Lighthouse-Score von 100 ist schön, aber er ist nicht dasselbe wie reale Nutzererfahrung. Lighthouse ist Lab-Diagnose unter kontrollierten Bedingungen. Search Console und Chrome UX Report zeigen Felddaten aus echten Nutzersituationen. Beides ist wertvoll, aber für unterschiedliche Fragen.

Der zweite Fehler ist, Page Experience gegen Content auszuspielen. Gute Performance macht schlechten Inhalt nicht hilfreich. Umgekehrt verschenkt guter Inhalt Wirkung, wenn die Seite langsam, instabil oder störend ist. Die richtige Frage lautet nicht "Content oder Technik?", sondern "Welche Reibung verhindert, dass der Inhalt seine Aufgabe erledigt?"

Der dritte Fehler ist, einzelne Metriken isoliert zu optimieren. Ein LCP-Problem kann am Server, an Bildern, Fonts, Render-Blocking CSS, Client-Side Rendering oder Priorisierung liegen. Ein INP-Problem kann an JavaScript, Third-Party-Code, langen Tasks oder komplexen Interaktionen liegen. Ein CLS-Problem kann durch Bilder ohne Dimensionen, Anzeigen, iframes, Fonts oder spät eingefügte Inhalte entstehen.

Entscheidungsregeln

• Nutze Felddaten, wenn du wissen willst, wie echte Nutzer die Seite erleben.
• Nutze Lab-Daten, wenn du Ursachen reproduzierbar debuggen willst.
• Priorisiere LCP zuerst, wenn der Hauptinhalt zu spät sichtbar wird.
• Priorisiere INP, wenn Klicks, Taps oder Tastatureingaben träge wirken.
• Priorisiere CLS, wenn Layoutsprünge Vertrauen zerstören oder Fehlklicks auslösen.
• Nutze FCP und TTFB als Lade-Diagnose, nicht als Ersatz für LCP.
• Nutze TBT als Lab-Hinweis für mögliche INP-Probleme.
• Beurteile Page Experience nach Template und Seitentyp, nicht nur nach Domain-Durchschnitt.
• Optimiere nicht für perfekte Zahlen, wenn Nutzer und Geschäftsziel bereits gut bedient sind.

Praktischer Audit-Workflow

Beginne mit Search Console und PageSpeed Insights. Welche URL-Gruppen haben schlechte Core Web Vitals? Sind Mobile und Desktop unterschiedlich? Betrifft es alle Seiten, ein Template, ein Land oder nur wenige stark besuchte URLs? Danach wählst du Beispielseiten: eine wichtige URL mit vielen Impressionen, eine schlechte URL aus der betroffenen Gruppe und eine gute Vergleichs-URL.

Im zweiten Schritt trennst du Feld und Lab. Felddaten sagen, ob echte Nutzer ein Problem haben. Lab-Daten zeigen, wo du suchen kannst. Wenn LCP schlecht ist, prüfe zuerst das LCP-Element, Bildgröße, Priorität, Serverzeit, CSS und Rendering. Wenn INP schlecht ist, suche nach langen Tasks, Third-Party-Skripten, teuren Event-Handlern und unnötigem JavaScript. Wenn CLS schlecht ist, prüfe reservierte Größen, Ads, Embeds, Fonts und spät eingefügte Banner.

Im dritten Schritt verbindest du das mit Content. Hat die Seite eine klare oberste Antwort, oder muss der Nutzer trotz schneller Technik suchen? Stören Newsletter-Popups oder Chat-Widgets vor der eigentlichen Aufgabe? Ist die interne Verlinkung so platziert, dass sie hilft, statt abzulenken? Page Experience ist nicht nur Millisekundenarbeit. Sie ist die Reibung zwischen Nutzerintention und Antwort.

Gutes und schlechtes Beispiel

Schlechtes Beispiel: "Lighthouse ist 96, also ist Page Experience erledigt." Das ist zu kurz. Vielleicht ist der Lab-Test gut, aber echte mobile Nutzer auf langsamen Geräten haben schlechte INP-Werte. Vielleicht ist die technische Performance gut, aber ein Cookie-Banner verdeckt den Hauptinhalt.

Gutes Beispiel: "Die Ratgeber-Templates haben auf Mobile ein schlechtes 75. Perzentil für LCP. Das LCP-Element ist meist das Hero-Bild. Wir reduzieren Bildgewicht, priorisieren das Hauptbild, prüfen TTFB und testen danach, ob die wichtigsten Non-Brand-Seiten bessere Felddaten bekommen. Parallel entfernen wir ein Newsletter-Overlay aus dem ersten Viewport." Diese Diagnose ist brauchbar, weil sie Metrik, Template, Ursache und Nutzeraufgabe verbindet.

Details, die oft fehlen

FID ist nicht mehr der aktuelle Core-Web-Vitals-Wert für Responsiveness. INP hat FID ersetzt, weil FID nur die erste Eingabeverzögerung betrachtete. INP bewertet Interaktionen über die Lebensdauer des Besuchs und ist dadurch näher an dem, was Nutzer als träge Seite erleben.

Core Web Vitals werden mit Perzentilen beurteilt. Das 75. Perzentil bedeutet: mindestens drei Viertel der Seitenaufrufe sollten die gute Schwelle erreichen. Wer nur Durchschnittswerte betrachtet, übersieht oft genau die Nutzer mit schlechter Verbindung, schwachen Geräten oder komplexen Sitzungen.

Perceived Performance ist kein einzelner offizieller Core-Web-Vital, aber praktisch wichtig. Eine Seite kann messbar mittelmäßig sein und trotzdem ruhig wirken, wenn sie schnell Feedback gibt, Skeletons sinnvoll nutzt und keine Sprünge erzeugt. Umgekehrt kann eine technisch schnelle Seite unruhig wirken, wenn der Inhalt erst sichtbar wird, dann verschwindet oder ständig nachrutscht.

Häufige Fehler

• Lighthouse-Score mit realer Nutzererfahrung gleichsetzen.
• FID weiterhin als aktuellen Hauptwert reporten.
• LCP optimieren, ohne das echte LCP-Element pro Template zu prüfen.
• INP ignorieren, weil alte FID-Daten gut aussahen.
• CLS nur beim initialen Laden prüfen und spätere Layoutsprünge übersehen.
• Third-Party-Skripte als unveränderbar behandeln.
• Page Experience nur technisch betrachten und Content-Reibung ignorieren.

Quellen für den Review

• Google Search Central: Page Experience: https://developers.google.com/search/docs/appearance/page-experience
• Google Search Central: Core Web Vitals and Search: https://developers.google.com/search/docs/appearance/core-web-vitals
• Search Console Core Web Vitals report: https://support.google.com/webmasters/answer/9205520
• web.dev Web Vitals: https://web.dev/articles/vitals
• Core Web Vitals thresholds: https://web.dev/articles/defining-core-web-vitals-thresholds
• Largest Contentful Paint: https://web.dev/articles/lcp
• Interaction to Next Paint: https://web.dev/articles/inp
• Cumulative Layout Shift: https://web.dev/articles/cls
• First Contentful Paint: https://web.dev/articles/fcp
• Time to First Byte: https://web.dev/articles/ttfb
• Total Blocking Time: https://web.dev/articles/tbt
• Core Web Vitals tools workflow: https://web.dev/articles/vitals-tools
• INP replacing FID: https://web.dev/blog/inp-cwv

Metrik-Profile

Page Experience Signal

Es gibt keinen einzelnen Page-Experience-Schalter. Google beschreibt mehrere Aspekte: Core Web Vitals, sichere Auslieferung, mobile Nutzbarkeit, wenig störende Anzeigen, keine intrusiven Interstitials und klare Trennung von Hauptinhalt und Nebenelementen.

LCP

LCP misst, wann das größte relevante sichtbare Element im Viewport gerendert ist. Typische Hebel sind Serverzeit, Bildoptimierung, Ressourcenpriorität, CSS, Fonts und Rendering-Strategie.

CLS

CLS misst unerwartete Layoutverschiebungen. Gute Praxis: Dimensionen reservieren, Ads und Embeds stabil platzieren, Fonts sauber laden und keine Banner ohne reservierten Platz einschieben.

INP

INP misst Responsiveness über Interaktionen hinweg. Schlechte Werte entstehen oft durch lange Tasks, zu viel JavaScript, teure Event-Handler oder Third-Party-Code.

FID

FID ist deprecated und wurde durch INP ersetzt. Er bleibt historisch wichtig, sollte aber nicht mehr als Hauptziel für moderne Core-Web-Vitals-Optimierung verwendet werden.

FCP

FCP zeigt, wann erstmals sichtbarer Inhalt erscheint. Es hilft bei Lade-Diagnosen, sagt aber nicht, wann der wichtigste Inhalt da ist.

TTFB

TTFB misst die Zeit bis zum ersten Byte der Antwort. Schlechte Werte können LCP direkt belasten, besonders bei dynamischen Seiten und internationaler Auslieferung.

TBT

TBT ist eine Lab-Metrik für blockierte Hauptthread-Zeit nach FCP. Sie ist kein Core Web Vital, aber sehr hilfreich, um INP-Risiken zu finden.

Speed Index

Speed Index beschreibt, wie schnell der sichtbare Bereich visuell gefüllt wird. Er ist besonders nützlich, um wahrgenommene Ladegeschwindigkeit zu diskutieren.

Layout Stability

Layout Stability ist die praktische Qualität hinter CLS: Nutzer sollen lesen, tippen und klicken können, ohne dass Ziele plötzlich wegspringen.

Input Latency

Input Latency ist die Wartezeit zwischen Eingabe und Reaktion. Nutzer merken sie schnell, auch wenn alle Ladewerte gut aussehen.

Perceived Performance

Perceived Performance beschreibt das subjektive Gefühl von Tempo und Kontrolle. Sie entsteht aus schnellen Rückmeldungen, stabiler Oberfläche, klarer Priorität und wenig Störung.

Mit Crawl Foundry anwenden

Sammle und organisiere Keywords in der Keyword-Datenbank von Crawl Foundry. So bleibt deine Recherche zusammen, bevor du entscheidest, welche Seiten du erstellst oder überarbeitest.

Keyword-Datenbank ansehen