Zwei Situationen tauchen immer wieder auf. In der ersten ist der PageSpeed-Bericht grün, während Search Console auf Mobilgeräten Hunderte URLs mit dem Status „Schlecht“ auflistet. In der zweiten, die bei Websites, deren Besucher über gute Verbindungen surfen, sogar noch häufiger vorkommt, zeigt PageSpeed einen orangefarbenen oder roten Wert, während Search Console jede URL als „Gut“ einstuft. Wer von beiden lügt?

Keiner. Sie messen nicht dasselbe. Sobald Sie wissen, was jeder von beiden sieht, verrät Ihnen die Abweichung zwischen ihnen, in welchem Fall Sie sich befinden und was zu tun ist.

Zwei Arten von Messung

Labordaten sind der Wert und die Metriken unten im Bericht. Es ist ein einziger simulierter Besuch: ein emuliertes Smartphone, eine gedrosselte Verbindung, ein leerer Cache, aus einem Google-Rechenzentrum, und niemand berührt die Seite. Er ist wiederholbar, was ihn gut zum Debuggen macht, und er endet, wenn die Seite geladen ist.

Felddaten nutzt Search Console, und sie stehen oben im PageSpeed-Bericht im Abschnitt zu echten Nutzern. Sie stammen aus dem Chrome User Experience Report: echte Chrome-Besucher, ihre Geräte, ihre Netzwerke, über gleitende 28 Tage. Eine Seite besteht, wenn 75 % der Besuche gut sind, also entscheidet das langsamste Viertel Ihres Publikums.

Kurz gefasst

Labor: ein simulierter Ladevorgang, keine Interaktion, wiederholbar.
Feld: echte Besuche über 28 Tage, bewertet am 75. Perzentil.
Die Page-Experience-Signale von Google nutzen die Felddaten, nicht den Laborwert.

Fall 1: Labordaten grün, Felddaten schlecht

Hier ist der Test gnädiger als die Realität. Sechs Gründe erklären das:

1. INP gibt es im Labor nicht. Interaction to Next Paint misst, wie schnell die Seite auf Klicks und Tippen reagiert. Das Labor klickt nie. Schlimmer noch: Eine Optimierung, die JavaScript bis zur ersten Interaktion aufschiebt, verbessert das Labor und kann das erste echte Tippen langsamer machen. Siehe den Leitfaden zur JavaScript-Verzögerung.

2. Das Labor hört beim Laden auf, CLS nicht. Das Feld zählt Layout-Verschiebungen während des gesamten Besuchs: beim Scrollen, wenn ein Banner hereingleitet, wenn eine Anzeige oder ein Embed seine Größe ändert. Ein Labor-CLS von null sagt nichts darüber, was unterhalb des sichtbaren Bereichs passiert. Die üblichen Verursacher bei Page Buildern finden Sie in unserem CLS-Leitfaden.

3. Echte Geräte sind langsamer. Das 75. Perzentil Ihres Publikums ist vielleicht ein älteres Smartphone mit schwacher Verbindung, weit unter dem Laborprofil. Eine Seite, die im Labor knapp besteht, fällt bei ihnen durch.

4. Echte Besuche verfehlen Ihren Cache. Das Labor trifft oft auf einen warmen Seiten-Cache. Echter Traffic umfasst nicht gecachte Seiten: erste Besuche nach einer Leerung, eingeloggte Kunden und URLs mit Tracking-Parametern wie utm_source, gclid oder fbclid, die viele Caches als neue Seiten behandeln. Ihre Server-Antwortzeit landet im Feld-LCP.

5. Search Console gruppiert URLs. Der Bericht zeigt Gruppen ähnlicher Seiten, und Seiten ohne genügend Traffic erben die Daten ihrer Gruppe oder der ganzen Website. Die URL, die Sie testen, ist vielleicht nicht die, die die Gruppe nach unten zieht.

6. Das Zeitfenster beträgt 28 Tage. Eine heute ausgelieferte Korrektur ist nach etwa vier Wochen vollständig sichtbar. Wer am nächsten Morgen in Search Console nachsieht, sieht die alten Daten.

Fall 2: Labordaten mittelmäßig, Felddaten grün

Hier ist der Test strenger als die Realität. Der mobile Laborlauf emuliert ein Mittelklasse-Smartphone mit einer um den Faktor vier verlangsamten CPU und einer gedrosselten Mobilverbindung von etwa 1,6 Mbit/s bei 150 ms Latenz. Dieses Profil ist bewusst pessimistisch, und viele reale Zielgruppen sind weit schneller:

Schnellere Netze und Smartphones. Besucher mit Glasfaser, schnellem 4G oder 5G und aktuellen Smartphones sind lange vor dem emulierten Gerät fertig geladen. Am 75. Perzentil bleiben sie im grünen Bereich.
Warme Besuche. Wiederkehrende Besucher und die Navigation von Seite zu Seite nutzen gecachte Dateien und offene Verbindungen erneut. Das Labor startet immer kalt, mit leerem Cache.
Skripte kosten auf echter Hardware weniger. Ein schweres Skript, das die emulierte CPU sekundenlang blockiert, braucht auf einem aktuellen Smartphone nur einen Bruchteil davon; die Blockierzeit im Labor überzeichnet also, was Besucher spüren.

Wo Ihre Besucher sind, entscheidet, in welchem Fall Sie sich befinden. Eine Zielgruppe in Ländern mit langsamen Mobilverbindungen verhält sich wie das Labor oder schlechter: Das ist Fall 1. Eine Zielgruppe in schnellen Netzen verhält sich besser als das Labor: Das ist Fall 2. Search Console und PageSpeed zeigen einen einzigen Wert für alle Ihre Besucher zusammen; ist Ihre Zielgruppe international, lassen sich die öffentlichen Daten des Chrome UX Report nach Land aufschlüsseln.

Was im Fall 2 zu tun ist. Die Page-Experience-Signale von Google stützen sich auf die Felddaten, also zählen grüne Felddaten. Machen Sie keine funktionierende Website kaputt, um einem Laborwert hinterherzujagen. Behalten Sie das Labor als Diagnosewerkzeug: Es zeigt, was Ihre langsamsten Besucher erleben, und fängt Regressionen ab, bevor sie in den Felddaten ankommen. Verbessern Sie, worauf es hinweist, eine sichere Änderung nach der anderen, wie in unserer Methode für Optimierungen ohne Bruch.

Kurz gefasst

Fall 1, Labordaten grün und Felddaten schlecht: Ihre Zielgruppe ist langsamer als der Test, oder das Problem tritt nach dem Laden auf.
Fall 2, Labordaten mittelmäßig und Felddaten grün: Ihre Zielgruppe ist schneller als der Test, der bewusst pessimistisch ist.
Google nutzt die Felddaten; das Labor ist ein Diagnosewerkzeug, kein Urteil.

Schritt 1: Lesen, was Search Console wirklich sagt

Welche Metrik: LCP, INP oder CLS. Die Methode ist für jede völlig unterschiedlich.
Welches Gerät: Mobil und Desktop sind getrennte Berichte.
Welche Gruppe: Öffnen Sie das Problem und sehen Sie sich die Beispiel-URLs an. Sie verweisen fast immer auf ein Template: Produktseiten, Artikel, Kategorieseiten, die Startseite.

Öffnen Sie dann eine Beispiel-URL in PageSpeed und sehen Sie sich zuerst den Abschnitt zu echten Nutzern an. Zeigt er Daten für diese URL, haben Sie die eigenen Feldwerte der Seite; zeigt er den gesamten Ursprung, wird die Seite zusammen mit dem Rest der Website bewertet.

Schritt 2: Das Feldproblem im Browser reproduzieren

Für INP: Öffnen Sie die DevTools, Panel Performance, stellen Sie die CPU-Drosselung auf 4x oder 6x, starten Sie die Aufzeichnung und interagieren Sie wie ein Besucher: Menü öffnen, eine Variante wechseln, in den Warenkorb legen, das Cookie-Banner akzeptieren. Lange gelbe Blöcke nach Ihrem Klick sind die Verzögerung. Neuere Chrome-Versionen zeigen in diesem Panel auch Live-Werte für LCP, CLS und INP.

Für CLS: Laden Sie mit Drosselung neu, scrollen Sie dann langsam durch die ganze Seite und interagieren Sie. Im Tab Rendering lässt „Layout Shift Regions“ jede Verschiebung in dem Moment aufblitzen, in dem sie passiert.

Für LCP: Testen Sie das Template in der mobilen Emulation mit einer nicht gecachten URL (hängen Sie einen zufälligen Parameter an) und achten Sie auf die Server-Antwortzeit und darauf, wann das LCP-Element entdeckt wird.

Konsole: LCP und Layout-Verschiebungen der Seite protokollieren, während sie passieren

new PerformanceObserver(l => l.getEntries().forEach(e =>
  console.log('LCP', Math.round(e.startTime), e.element))).observe({ type: 'largest-contentful-paint', buffered: true });
new PerformanceObserver(l => l.getEntries().forEach(e => !e.hadRecentInput &&
  console.log('CLS', e.value.toFixed(3), e.sources?.map(s => s.node)))).observe({ type: 'layout-shift', buffered: true });

Schritt 3: Nie aus einem einzigen Lauf schließen

Der Laborwert schwankt von einem Lauf zum nächsten, auf Mobilgeräten manchmal um zehn Punkte, weil Seite, Netzwerk und Testrechner variieren. Um zwei Versionen zu vergleichen:

Führen Sie jede Version mehrmals aus und vergleichen Sie Mediane, nicht den besten Lauf;
verteilen Sie die Läufe zeitlich, denn ein kurz danach erneut angefordertes Ergebnis kann aus einem Cache kommen und dieselbe Zahl wiederholen;
vergleichen Sie dieselbe URL, dasselbe Gerät, dieselben Bedingungen, mit und ohne die Änderung.

Belastbare Schlussfolgerung

Feldmetrik in Search Console identifiziert, im Browser reproduziert, behoben, über mehrere Laborläufe bestätigt und vier Wochen später in Search Console validiert.

Falsche Schlussfolgerung

Ein einziger grüner PageSpeed-Lauf am Tag nach der Änderung, als Beweis genommen, dass das Problem in Search Console gelöst ist.

Schritt 4: Validieren und warten

Sobald die Korrektur live ist, klicken Sie beim Problem in Search Console auf „Fehlerbehebung überprüfen“. Die Validierung folgt dem 28-Tage-Fenster, rechnen Sie also mit etwa einem Monat. In der Zwischenzeit sagen Ihnen das Labor und Ihre eigenen Messungen im Browser, ob die Korrektur wirkt.

Mit Mantys Core

Mantys Core ersetzt keine Felddaten: Search Console und der Chrome-Bericht bleiben die Referenz. Es macht die Laborseite der Methode sauberer:

Ein einziger Befehl führt PageSpeed für dieselbe URL erst ohne, dann mit den Optimierungen aus, auf Mobil, Desktop oder beidem, sodass ein Vorher-Nachher unter denselben Bedingungen gemessen wird.
Sein Critical CSS wird in denselben Bildschirmgrößen erfasst, die der Speedtest verwendet, sodass das, was der Test beim Laden sieht, genau das ist, was optimiert wurde.
Ein Bypass mit einer einzigen Anfrage zeigt die Rohseite neben der optimierten in Ihrem eigenen Browser, genau das, was Schritt 2 braucht.

Das Feld sagt Ihnen, wo es wehtut. Die Plattform hilft Ihnen, im Labor zu beweisen, dass Ihre Änderung diejenige ist, die hilft.

Zusammenfassung

Der PageSpeed-Wert ist ein einziger simulierter Ladevorgang; Search Console sind 28 Tage echter Besuche am 75. Perzentil.
Labordaten grün und Felddaten schlecht: Das Problem ist eine Interaktion, eine Verschiebung nach dem Laden, ein langsames Gerät, eine nicht gecachte URL oder ein anderes Template.
Labordaten mittelmäßig und Felddaten grün: Ihre Besucher sind schneller als das pessimistische Testprofil; es zählen die Felddaten.
Beginnen Sie bei Search Console: Metrik, Gerät, URL-Gruppe, Template.
Reproduzieren Sie es in den DevTools mit Drosselung und echten Interaktionen, dann vergleichen Sie mehrere Laborläufe, nie nur einen.
Validieren Sie die Korrektur und geben Sie ihr vier Wochen.

Kommentare

Hängen Sie an einem ähnlichen Problem? Beschreiben Sie Ihr Setup und was Sie beobachten. Wir lesen jeden Kommentar und antworten.

Noch keine Kommentare. Teilen Sie als Erste oder Erster Ihren Fall.