Core Web Vitals und mobile Nutzbarkeit prüfen: Tools richtig einsetzen
Eine Performance-Prüfung verbindet Felddaten mit Laboranalysen. Ein einzelner Toolwert belegt weder Ursache noch Rankingwirkung. Felddaten zeigen, wie reale Chrome-Nutzende eine veröffentlichte Seite erlebt haben. Labordaten erzeugen einen kontrollierten Aufruf für Tests und Vergleiche. Beide Datenarten beantworten verschiedene Fragen.
Die drei Core Web Vitals messen Ladeerlebnis, Reaktionsfähigkeit und visuelle Stabilität: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS). Als Richtwerte am 75. Perzentil gelten höchstens 2,5 Sekunden für LCP, höchstens 200 Millisekunden für INP und höchstens 0,1 für CLS. Diese Schwellen helfen bei der Einordnung. Gute Core-Web-Vitals-Werte garantieren keine bestimmten Suchpositionen.
Die Prüfung gehört in den technischen Teil eines SEO-Audits. Wer den Zusammenhang von Erreichbarkeit, Rendering und Auslieferung sucht, findet ihn im Hub Technisches SEO: Infrastruktur, Architektur und Jamstack. Die Einordnung von Leistungen und Grenzen behandelt der Beitrag Was ist Suchmaschinenoptimierung (SEO)?.
Die passende Datenart für die Prüfentscheidung wählen
Felddaten entstehen bei echten Seitenaufrufen. Der Chrome User Experience Report (CrUX) sammelt anonymisierte Messwerte aus Chrome-Browsern. Ein Feldwert beschreibt eine Verteilung von Erfahrungen über einen Zeitraum von 28 Tagen. Das 75. Perzentil bildet den Maßstab: 75 Prozent aller erfassten Aufrufe liegen unter diesem Wert.
Labordaten entstehen unter festgelegten Bedingungen mit simuliertem Gerät und Netzwerk. Lighthouse dient als Werkzeug für diese Tests. Die kontrollierte Umgebung erlaubt reproduzierbare Vergleiche. Ein Laborlauf bildet aber nicht die Geräte, Regionen, Caches und Nutzungsmuster der Zielgruppe ab.
| Datenart | Geeignete Frage | Werkzeuge | Grenzen der Aussage |
|---|---|---|---|
| Felddaten | Wie haben reale Nutzergruppen die Seite erlebt? | CrUX, PageSpeed Insights, Search Console, RUM | nennt keine technische Einzelursache |
| Labordaten | Lässt sich ein Befund unter gleichen Bedingungen wiederholen? | Lighthouse, Chrome DevTools, PageSpeed Insights | zeigt nicht die Erfahrung aller Aufrufe |
| Sitzungsaufzeichnung | Welche Ressource erzeugt den Befund auf diesem Gerät? | Chrome DevTools mit Mobilgerät, RUM-Kontext | beschreibt keine Verteilung im Publikum |
Prüfregel: Felddaten bewerten die veröffentlichte Erfahrung und steuern Prioritäten. Labordaten prüfen eine technische Hypothese. Ein Laborwert ersetzt keinen Feldwert; ein Feldwert ersetzt keine Ursachenanalyse.
Lighthouse lädt eine Seite ohne menschliche Eingabe und misst INP nicht. Der Laborwert Total Blocking Time (TBT) liefert Hinweise auf Hauptthread-Arbeit, ersetzt INP im Feld aber nicht.
Core Web Vitals einordnen
Die drei Metriken erfassen unterschiedliche Teile einer Seitenerfahrung. Sie bewerten weder Inhalt noch Bedienlogik oder Barrierefreiheit.
| Metrik | Gemessener Vorgang | Richtwert (75. Perzentil) | Prüffrage |
|---|---|---|---|
| LCP | Zeitpunkt des größten sichtbaren Inhaltselements | höchstens 2,5 Sekunden | Welches Element ist im Viewport das größte sichtbare Element? |
| INP | Verzögerung der Oberfläche nach Eingaben | höchstens 200 Millisekunden | Welche Eingabe reagiert träge? |
| CLS | Ausmaß unerwarteter Layout-Verschiebungen | höchstens 0,1 | Welche Verschiebung trifft welchen Nutzungsschritt? |
Der Wert hängt vom Kontext ab. LCP schwankt mit Viewport, Cache und Element. INP verlangt echte Klicks und Taps während einer Sitzung. CLS tritt auf, wenn nach dem Laden Elemente nachrücken. Ein Testlauf liefert eine technische Spur, nimmt die Feldverteilung aber nicht vorweg.
Ein Tool-Score bildet keine eigene Zielgröße. PageSpeed Insights zeigt im Laborbereich Lighthouse-Werte und im Feldbereich CrUX-Daten. Laborberichte helfen bei der Fehlersuche, ersetzen aber keine Feldmessung.
Werkzeuge nach Aussagekraft einsetzen
PageSpeed Insights: Einstieg für URL und Datenebene
PageSpeed Insights prüft öffentliche URLs auf zwei Ebenen. Der Feldbereich liest CrUX-Daten; der Laborbereich führt Lighthouse aus. Die Prüfung startet mit der Datenebene: Liegen Daten für die einzelne URL oder für den gesamten Ursprung vor?
Die Auswertung folgt vier Schritten:
- →URL, Datum, Geräteklasse und Datenebene (URL, Ursprung oder keine Daten) notieren.
- →Verteilung und 75. Perzentil für LCP, INP und CLS getrennt erfassen.
- →Befund als Beobachtung festhalten („Mobile Felddaten zeigen erhöhten LCP“). Ursachenursprünge verlangen eigene Prüfschritte.
- →Testumgebung im Laborbereich dokumentieren und Hypothese untersuchen.
PageSpeed Insights dient nicht als Echtzeit-Monitoring nach Veröffentlichungen. Der Feldbereich zeigt einen rückblickenden Zeitraum von 28 Tagen.
Search Console: Muster über URL-Gruppen priorisieren
Der Core-Web-Vitals-Bericht in der Google Search Console fasst Felddaten nach Gerät, Metrik, Status und URL-Gruppen zusammen. Er zeigt, welche Seitentypen Aufmerksamkeit verlangen. Der Bericht arbeitet mit Stichproben und fasst ähnliche Seiten zusammen.
Das Team behandelt Gruppen als Priorisierungshinweis. Repräsentative URLs aus dem Seitentyp offenbaren im Detail, ob Vorlage, Inhalte, Auslieferung oder Interaktion übereinstimmen.
| Frage in Search Console | Nächster Schritt | Unzulässiger Schluss |
|---|---|---|
| Welcher Seitentyp fällt im Feld auf? | Repräsentative URLs und Vorlagen wählen | Alle URLs der Gruppe besitzen denselben Fehler |
| Welcher Status liegt vor? | LCP, INP und CLS getrennt betrachten | Eine Metrik erklärt automatisch die Ursache |
| Fehlen Felddaten für eine Gruppe? | Einzelne URL in PageSpeed Insights prüfen | Fehlende Daten bedeuten automatische Ladezeit-Garantie |
Die Search Console erfasst keine kurzfristigen Änderungen. Die Einordnung von Befunden nach Reichweite, Risiko und Kapazität behandelt der SEO-Strategie-Hub.
Chrome DevTools und Lighthouse: Ursachen im Labor untersuchen
Chrome DevTools prüft lokale Entwicklungsstände, Testumgebungen und Seiten mit Logins. Lighthouse liefert Hinweise für Performance, Barrierefreiheit und SEO. Ein Testlauf dient der Fehlersuche, bildet aber kein Qualitätszertifikat.
Für die Analyse gilt ein fester Testrahmen: URL, Release-Stand, Gerät, Viewport, Drosselung und Cache-Zustand stehen vorab fest.
Der Gerätemodus simuliert Viewport, Touch und Drosselung auf dem Desktop. Er ersetzt keine Mobilgeräte-Hardware. Remote Debugging auf einem verbundenen Telefon prüft echte Ausführung und Netzwerklasten.
CrUX und eigenes Real User Monitoring (RUM)
CrUX liefert Felddaten für öffentliche Seiten mit ausreichendem Aufrufvolumen. Fehlen Daten in CrUX, belegt das nur ein geringes Messvolumen, keine fehlerfreie Ladezeit.
Ein eigenes Real User Monitoring (RUM) misst LCP, INP und CLS direkt im Browser der Nutzenden. Vor dem Einsatz klären Produkt- und Datenschutzverantwortliche Zweck, Datenminimierung und Einwilligung. Ein RUM-Dashboard erfordert saubere Angaben zu Quelle, Segment, Zeitraum und Datenlücken.
Widersprüchliche Messwerte einordnen
Abweichende Werte zwischen Labor und Feld basieren auf unterschiedlichen Bedingungen. Das Labor steuert Parameter; das Feld erfasst echte Geräte, Netzwerke und Eingaben.
| Beobachtung | Ursache | Nächster Schritt |
|---|---|---|
| Labor unauffällig, Felddaten auffällig | Laborbedingungen erfassen keine echten Geräte oder Nutzungsschritte | Feldsegment eingrenzen; reale Geräte testen |
| Felddaten unauffällig, Laborwert auffällig | Labor-Drosselung liegt über dem Durchschnitt der Nutzenden | Testparameter dokumentieren; kritischen Weg prüfen |
| URL zeigt keine Felddaten, Ursprung besitzt Daten | URL-Datenvolumen reicht nicht aus | Ursprungswert als Kontext nutzen; Templates prüfen |
| Search Console meldet URL-Gruppe | Ähnlichkeiten existieren auf Vorlagenebene | Repräsentative Einzel-URLs vergleichen |
Ein LCP-Element im Bericht zeigt einen Analyseansatz, keinen automatischen Beweis für ein Feldproblem. Ein hoher TBT-Wert stützt eine Interaktionshypothese, belegt aber keinen bestimmten INP-Wert.
Tickets trennen drei Punkte:
- →gemessener Befund
- →technische Hypothese
- →geplante Prüfung
Mobile Nutzbarkeit getrennt von Performance prüfen
Eine Seite kann im Labor schnell laden und auf dem Smartphone schwer bedienbar sein. Google stellte den Mobile-Usability-Bericht im Dezember 2023 ein. Die Prüfung verlangt eine ganzheitliche Sicht.
| Prüfbereich | Testinhalt | Werkzeug | Grenze |
|---|---|---|---|
| Darstellung | Breiten, Hoch- und Querformat, Zoom prüfen | DevTools-Gerätemodus, reale Geräte | Emulation ersetzt kein Telefon |
| Bedienung | Navigation, Formulare, Dialoge, Touch testen | Reale Geräte, Remote Debugging | Automatische Audits erkennen Nutzeraufgaben nicht |
| Zugänglichkeit | Fokus, Semantik, Kontraste prüfen | Browserwerkzeuge, manuelle Tests | Lighthouse belegt keine WCAG-Konformität |
Der Test startet beim Hauptweg der Seite: Lesen, Vergleichen oder Formularabsendung. Überlappungen, verdeckte Inhalte oder unschließbare Banner stören diesen Ablauf.
Die Nutzbarkeit im Funktionskontext behandelt der Beitrag User Experience (UX) als Rankingfaktor. Die technische Einhaltung von WCAG-Kriterien vertieft der Artikel Barrierefreie Websites technisch umsetzen.
Ablauf der Performance-Prüfung
- →Prüfobjekt festlegen: Seitentyp, Nutzungsschritt und Testfrage wählen. Test- und Produktionsstände trennen.
- →Felddaten dokumentieren: Search Console und PageSpeed Insights für Mobilgeräte und Desktop auswerten. Datenlücken offen festhalten.
- →Befunde priorisieren: Nutzungsschaden, betroffene Seitenzahl und Umsetzungschancen bewerten.
- →Hypothese im Labor testen: Annahme formulieren und unter definierten Testbedingungen aufzeichnen.
- →Änderung dokumentieren: Ticket, Code, URL und Testergebnis verknüpfen. Redaktionelle Übergaben berücksichtigt der Leitfaden Content Marketing und SEO-Redaktion.
- →Nach Release messen: Laborwerte nach dem Deploy prüfen; Felddaten nach Ablauf des Beobachtungszeitraums bewerten.
Vorlage für ein Performance-Ticket
Prüfobjekt / URL oder Seitentyp:
Produktionsstand oder Release:
Nutzungsschritt:
Datenquelle und Abrufdatum:
Geräteklasse, URL- oder Ursprungsebene, Zeitraum:
Gemessener Befund:
Betroffene Metrik oder mobile Beobachtung:
Technische Hypothese:
Laborbedingungen und Reproduktionsschritte:
Geplante Änderung:
Nebenprüfungen: Inhalt, Bedienung, Barrierefreiheit:
Ergebnis nach Veröffentlichung:
Offene Grenzen oder fehlende Daten:
Häufige Fehlannahmen
- →„Ein grüner Lighthouse-Score garantiert schnelle Felddaten.“ Nein. Lighthouse simuliert Testbedingungen; reale Geräte und Netze weichen ab.
- →„Keine CrUX-Daten bedeuten fehlerfreie Performance.“ Nein. Es fehlen auswertbare Daten. Das verlangt eigene Prüfungen.
- →„Der Search-Console-Status gilt für jede einzelne URL der Gruppe.“ Nein. Der Bericht fasst Stichproben zusammen.
- →„Lighthouse misst INP.“ Nein. INP verlangt echte Nutzereingaben. TBT dient nur als Diagnosehinweis im Labor.
- →„Der Gerätemodus ersetzt ein Mobiltelefon.“ Nein. Die Ausführung läuft weiterhin auf Desktop-Hardware.
- →„Gute Core Web Vitals garantieren ein besseres Ranking.“ Nein. Sie verbessern die Seitenerfahrung, ersetzen aber weder Inhalt noch Relevanz.
Nächster Schritt
OLDSCHOOLSEO prüft Felddaten, Labordaten und technische Ursachen im Rahmen einer nachhaltigen Betreuung. Die Übersicht aller Leistungen steht unter Suchmaschinenoptimierung Stuttgart.
Projektanfrage per E-Mail senden · Erstgespräch mit Sandra buchen
▋
Michael Kienzler ist Partner und Gründer von OLDSCHOOLSEO. Seine Arbeit beginnt bei der Analyse der technischen Architektur und der Daten, um daraus die Potenziale für die redaktionelle und strategische Weiterentwicklung abzuleiten.