Largest Contentful Paint (LCP)
Schätzen Sie, wann das größte sichtbare Bild oder der größte Textblock im Labortest fertig gerendert ist. Untersuchen Sie bei einem langsamen Ergebnis den Hauptinhalt, Assets und die Auslieferung.
Core Web Vitals wichtiger Website-Seiten überwachen
Führen Sie tägliche Labortests für ausgewählte öffentliche URLs aus und halten Sie LCP, CLS, FCP, TTFB, TBT, Speed Index, die aktuelle Bewertung und Prüfzeit neben Ihrem technischen SEO-Workflow. Finden Sie Regressionen und testen Sie gezielte Korrekturen erneut, ohne synthetische Messungen mit echten Felddaten zu verwechseln.
TL;DR
Zu lang; nicht gelesen
Zusammenfassung anzeigen Zusammenfassung ausblenden
TL;DR
Zu lang; nicht gelesen
Was macht die Core-Web-Vitals-Überwachung von Screpy?
Screpy führt wiederkehrende Labortests für ausgewählte öffentliche URLs aus. Es meldet LCP und CLS sowie FCP, TTFB, TBT, Speed Index, eine Laborbewertung und die Aktualität der Prüfung. So finden Teams Performance-Regressionen, untersuchen eine konkrete Ursache und messen erneut, ohne synthetische Ergebnisse mit echten Nutzerdaten zu verwechseln.
Monitoring-Umfang wählen
- Die Startseite wird einbezogen, wenn ein Projekt für Monitoring eingerichtet ist.
- Weitere öffentliche URLs können innerhalb des aktuellen Tarifkontingents hinzugefügt werden.
- Jede aktive URL ist nach einem Tag für eine weitere geplante Prüfung berechtigt.
- Die genaue URL und der Zeitpunkt der letzten Prüfung bleiben neben dem Ergebnis sichtbar.
Primäre Laborsignale lesen
- Largest Contentful Paint schätzt, wann der wichtigste sichtbare Inhalt fertig gerendert ist.
- Cumulative Layout Shift misst unerwartete Verschiebungen während des Tests.
- Eine Laborbewertung zeigt URLs, die zuerst Aufmerksamkeit benötigen.
- Die Bewertung ist eine synthetische Diagnose, keine Bewertung von Googles Felddaten.
Unterstützende Diagnosen verwenden
- First Contentful Paint liefert Kontext für das frühe Rendering.
- Time to First Byte grenzt die Untersuchung auf Verzögerungen bei der ersten Antwort ein.
- Total Blocking Time zeigt blockierende Main-Thread-Aufgaben im Labor.
- Speed Index fasst zusammen, wie schnell sichtbarer Inhalt im Test erscheint.
Ergebnisse sicher interpretieren
- Labordaten sollten mit derselben URL und Messmethode verglichen werden.
- Total Blocking Time ist nicht Interaction to Next Paint.
- Eine schwache Metrik grenzt die Untersuchung ein, beweist aber nicht die Ursache.
- Eine bessere Seitenerfahrung unterstützt Nutzer, garantiert aber keine Rankings oder keinen Traffic.
Die Labormetriken hinter jeder geprüften Seite lesen.
Der Bericht trennt Ladezeit, visuelle Stabilität, Serverantwort und Main-Thread-Diagnosen, damit eine Gesamtbewertung das zu untersuchende Signal nicht verbirgt.
Cumulative Layout Shift (CLS)
Messen Sie unerwartete visuelle Bewegungen während des Tests. Bilder ohne Abmessungen, Einbettungen, Schriften und spät geladener Inhalt sind häufige Untersuchungsstellen.
First Contentful Paint (FCP)
Sehen Sie, wann der erste Text, das erste Bild oder anderer Seiteninhalt gezeichnet wird. FCP hilft, Verzögerungen beim frühen Rendering einzugrenzen.
Time to First Byte (TTFB)
Prüfen Sie die anfängliche Serverantwort-Verzögerung des Labortests. Ein langsamer Wert kann auf Hosting, Caching, Weiterleitungen oder Backend-Arbeit hinweisen.
Total Blocking Time (TBT)
Messen Sie, wie lange Main-Thread-Aufgaben die Reaktionsfähigkeit im Labor blockieren. TBT ist eine nützliche Diagnose, aber nicht die echte Nutzer-Metrik Interaction to Next Paint.
Speed Index
Fassen Sie zusammen, wie schnell sichtbarer Seiteninhalt während des Labortests erscheint, statt sich nur auf einen Rendering-Meilenstein zu verlassen.
Bewertung der Labor-Performance
Nutzen Sie die Bewertungen Gut, Verbesserungsbedarf oder Schlecht, um ausgewählte URLs mit dem größten Handlungsbedarf zu finden. Sie fassen Laborergebnisse zusammen, nicht Googles Nutzerbewertung.
URL und Aktualität der Prüfung
Verknüpfen Sie jedes Ergebnis mit der genauen öffentlichen URL und dem Zeitpunkt der letzten Prüfung, damit keine alte oder unpassende Messung aktuelle Entscheidungen beeinflusst.
Wichtige Seiten regelmäßig im Labortest halten.
Fügen Sie repräsentative öffentliche URLs hinzu und prüfen Sie nach jeder täglichen Prüfung das aktuelle Ergebnis. Jede Bewertung bleibt mit der getesteten URL und dem Erfassungszeitpunkt verbunden.
- Startseite und ausgewählte wertvolle URLs überwachen
- Geprüfte Seiten nach Bewertung oder URL sortieren
- Vor Maßnahmen den Zeitpunkt der letzten Prüfung verwenden
Core Web Vitals von unterstützenden Diagnosen trennen.
Prüfen Sie LCP und CLS zusammen mit FCP, TTFB, TBT und Speed Index. Screpy kennzeichnet TBT als Labor-Diagnose der Reaktionsfähigkeit und nicht als echte INP-Messung.
- Lade- und visuelle Stabilitätsmessungen untersuchen
- Antwort- und Rendering-Metriken zur Eingrenzung der nächsten Prüfung verwenden
- Aussagen zu Labor- und Felddaten getrennt halten
Von einer schwachen Metrik zu einer prüfbaren Änderung.
Nutzen Sie die aktuell schwächste Metrik, um Inhaltsdarstellung, Layout-Reservierung, Serverantwort, Assets oder Main-Thread-Arbeit zu untersuchen. Ändern Sie eine wahrscheinliche Ursache und messen Sie dieselbe URL erneut.
- Geschäftskritische Seiten und gemeinsame Vorlagen priorisieren
- Seite und Auslieferungspfad vor Codeänderungen untersuchen
- Die gezielte Korrektur mit einem späteren Ergebnis bestätigen
Eine langsame URL in eine prüfbare Performance-Korrektur verwandeln.
Halten Sie URL und Messmethode stabil, verwenden Sie die schwächste Metrik zur Eingrenzung und bestätigen Sie eine Änderung mit einer späteren Prüfung.
- 01
Eine repräsentative öffentliche URL wählen
Beginnen Sie mit Startseite, Conversion-Seite oder einer URL einer wichtigen Vorlage. Jede wertarme Seite zu überwachen erzeugt zunächst Rauschen statt Erkenntnisse.
- 02
Geplante Laborprüfung als Ausgangsbasis nutzen
Screpy prüft berechtigte überwachte URLs täglich und speichert aktuelle Laborbewertung, unterstützende Metriken, getestete URL und Prüfzeit.
- 03
Der schwachen Metrik zu einer Hypothese folgen
Nutzen Sie LCP, CLS, FCP, TTFB, TBT und Speed Index, um zuerst Inhaltsdarstellung, Layout-Reservierung, Serverantwort, Assets oder Main-Thread-Arbeit zu untersuchen.
- 04
Eine Ursache ändern und erneut messen
Veröffentlichen Sie die kleinste relevante Korrektur, lassen Sie die überwachte URL unverändert und prüfen Sie mit dem nächsten Ergebnis, ob sich die Labormessung verbessert hat.
Seiten überwachen, bei denen eine Regression am meisten schaden würde.
Eine kleine repräsentative URL-Auswahl ist leichter zu untersuchen als ein Dashboard voller wertarmer Seiten. Beginnen Sie mit geschäftskritischen Abläufen und wiederverwendbaren Vorlagen.
Wichtige Landingpages
Überwachen Sie Seiten, die Produkt, Service oder Kampagne vorstellen, da ein langsamer erster Eindruck Entdeckung und Conversion beeinflussen kann.
Gemeinsame Seitenvorlagen
Wählen Sie eine repräsentative Produkt-, Kategorie-, Artikel- oder Dokumentations-URL, um Performance-Probleme aufzudecken, die sich über dieselbe Vorlage wiederholen.
Conversion-Pfade
Halten Sie Preis-, Registrierungs-, Lead- und Checkout-Einstiegsseiten sichtbar, wenn Skripte, Einbettungen, Experimente oder Drittanbieter-Tags ihre Performance verändern.
Release-empfindliche Seiten
Verfolgen Sie von Redesigns, Framework-Änderungen, neuen Medien, Tag-Manager-Updates oder Auslieferungsänderungen betroffene URLs, bevor Sie das Muster weiter ausrollen.
Laborergebnisse interpretieren, ohne sie zu überbewerten.
Screpy macht wiederkehrende Performance-Prüfungen umsetzbar. Diese Grenzen halten das Ergebnis korrekt, wenn Felddaten, Ursachenanalyse oder Rankingwirkung die eigentliche Frage sind.
Labordaten, keine Felddaten
Screpy führt kontrollierte Seitentests aus. Das Ergebnis repräsentiert nicht den laufenden echten Nutzerdatensatz von Chrome UX Report oder Google Search Console.
TBT ist nicht INP
TBT hilft bei der Diagnose der Laborreaktionsfähigkeit. INP erfordert echte Nutzerinteraktionen; ein TBT-Ergebnis darf daher nicht als INP-Messung dargestellt werden.
Eine Bewertung ist keine Ursache
Eine schlechte Metrik zeigt, wo Sie suchen sollten. Bestätigen Sie das tatsächliche Element, die Anfrage, das Skript, die Vorlage oder das Serververhalten vor einer Änderung.
Performance ist keine Ranking-Garantie
Gute Seitenerfahrung unterstützt Nutzer und Suchqualität, ersetzt aber keine relevanten Inhalte, Crawlbarkeit, Indexierung, Links oder andere Suchsignale.
Den Performance-Workflow passend zur Frage wählen.
Überwachen Sie ausgewählte URLs für wiederkehrende Laborergebnisse, prüfen Sie die gesamte Website auf wiederholte technische Muster oder lesen Sie die Messmethode vor dem Vergleich mit Felddaten.
Führen Sie tägliche Labortests für ausgewählte öffentliche URLs aus und prüfen Sie Bewertung, Metriken und Aktualität.
Crawlen Sie die gesamte Website, um wiederholte Seiten-, Asset-, Rendering- und technische Muster rund um eine betroffene URL oder Vorlage zu finden.
Verstehen Sie Umfang, Zeitpunkt und Grenzen der Screpy-Labordaten, bevor Sie sie mit echten Nutzerberichten vergleichen.
Screpy-Dokumentation
Labor-Performance-Prüfungen richtig interpretieren
Folgen Sie dem Screpy-Leitfaden, um URLs auszuwählen, jede Metrik mit URL und Datum zu lesen, Labor- von Felddaten zu trennen und eine gezielte Verbesserung zu testen.
Antworten auf Fragen zum Core-Web-Vitals-Monitoring.
Verstehen Sie Labor- und Felddaten, LCP, CLS, TBT, unterstützende Geschwindigkeitsmetriken, tägliche Prüfungen, URL-Auswahl, Bewertungen und die Grenzen von Aussagen zur Seitenerfahrung.
Was misst das Core-Web-Vitals-Monitoring von Screpy?
Screpy führt laborbasierte Prüfungen für ausgewählte öffentliche URLs aus. Es meldet LCP, CLS, FCP, TTFB, TBT, Speed Index, eine Laborbewertung und den Zeitpunkt der letzten Prüfung.
Basieren die Core-Web-Vitals-Daten von Screpy auf echten Nutzern?
Nein. Screpy meldet kontrollierte Labormessungen für die geprüfte URL. Felddaten aus Chrome UX Report oder Google Search Console spiegeln echte Besuche über einen rollierenden Zeitraum wider und können wegen Geräten, Netzwerken, Regionen und Nutzerverhalten abweichen.
Welche Metriken sind die offiziellen Core Web Vitals?
Google definiert derzeit Largest Contentful Paint, Interaction to Next Paint und Cumulative Layout Shift als Core Web Vitals. Screpy misst LCP und CLS im Labor und meldet TBT als Labor-Diagnose neben FCP, TTFB und Speed Index. TBT wird nicht als INP dargestellt.
Warum zeigt Screpy TBT statt INP?
Interaction to Next Paint hängt von echten Nutzerinteraktionen ab und ist eine Feldmetrik. Total Blocking Time kann in einem kontrollierten Labortest gemessen werden und zeigt blockierende Main-Thread-Arbeit, aber beide Metriken sind nicht austauschbar.
Wie oft werden überwachte URLs geprüft?
Aktive URLs sind nach einem Tag für eine weitere geplante Prüfung berechtigt. Warteschlange, Seitenverfügbarkeit und Tarif können beeinflussen, wann ein Ergebnis bereitsteht; beachten Sie daher den angezeigten Zeitpunkt der letzten Prüfung.
Welche Seiten sollte ich zuerst überwachen?
Beginnen Sie mit Startseite, stark besuchten Landingpages, Conversion-Einstiegen und einer repräsentativen URL jeder wichtigen Vorlage. Fügen Sie Seiten hinzu, bei denen eine Regression viele Besucher betrifft oder dieselbe Implementierung oft wiederverwendet wird.
Bedeutet eine gute Screpy-Bewertung, dass die URL Googles Core Web Vitals besteht?
Nicht unbedingt. Screpy fasst einen Labortest zusammen, während Googles Bewertung echte LCP-, INP- und CLS-Felddaten nutzt, wenn genügend Daten vorhanden sind. Verwenden Sie die Screpy-Bewertung als Testhilfe und vergleichen Sie bei Bedarf den relevanten Feldbericht.
Garantiert eine Verbesserung der Core Web Vitals höhere Rankings?
Nein. Google empfiehlt gute Core Web Vitals für Nutzer und Suche, doch Seitenerfahrung ist nur ein Teil vieler Signale. Relevanter Inhalt kann auch bei schwächerer Seitenerfahrung ranken, und eine schnelle Seite erhält keine Rankinggarantie.
Performance-Prüfungen auf wichtige Seiten konzentrieren.
Wählen Sie repräsentative öffentliche URLs, erstellen Sie eine tägliche Laborbasis, untersuchen Sie die schwächste Metrik und messen Sie nach einer gezielten Änderung erneut.