Wichtige Landingpages
Überwachen Sie Seiten, die Produkt, Service oder Kampagne vorstellen, da ein langsamer erster Eindruck Entdeckung und Conversion beeinflussen kann.
Core Web Vitals wichtiger Website-Seiten überwachen
Überwachen Sie LCP, CLS und Ladediagnosen ausgewählter öffentlicher Seiten Ihrer Projektdomain. Prüfen Sie fünf Kennzahlen pro URL sowie die getrennte Startseitenübersicht mit Speed Index und bewerten Sie eine gezielte Korrektur anhand eines späteren Laborergebnisses. Das sind kontrollierte Tests, keine Felddaten realer Nutzer.
Core-Web-Vitals-Prüfungen
LCP
Finden Sie ausgewählte URLs, auf denen der Hauptinhalt spät erscheint.
CLS
Prüfen Sie unerwartete Layoutverschiebungen auf ausgewählten URLs.
Tägliche Labormessungen
Notieren Sie aktuelle Werte und prüfen Sie nach einer gezielten Korrektur ein späteres Laborergebnis.
Largest Contentful Paint überwachen
Largest Contentful Paint misst, wann das größte geeignete Bild, der größte Textblock oder ein Video im sichtbaren Testbereich erscheint. Der LCP-Wert jeder überwachten URL zeigt, welche Seite eine genauere Untersuchung des Ladevorgangs verdient.
- Screpy zeigt LCP in Sekunden: bis einschließlich 2,5 s gut, über 2,5 s bis 4 s verbesserungsbedürftig und über 4 s schlecht.
- Ein schneller FCP bei langsamem LCP bedeutet, dass bereits Inhalt vor dem Hauptelement sichtbar war. Untersuchen Sie dessen Auslieferung und Darstellung, statt von einer vollständig leeren Seite auszugehen.
- Bestätigen Sie das betreffende Bild, die Schrift oder die Darstellungsverzögerung durch eine technische Leistungsanalyse. Die Zahl allein benennt weder das Element noch die richtige Korrektur.
example.comLabor
LCP2,1 s
Cumulative Layout Shift messen
Eine Seite kann schnell laden und trotzdem eine Schaltfläche oder einen Absatz unerwartet verschieben. Cumulative Layout Shift liefert für jede überwachte URL einen Stabilitätswert im Labortest, damit Sie Bewegung getrennt von Ladegeschwindigkeit untersuchen können.
- CLS ist keine Zeitangabe: bis einschließlich 0,1 gilt in Screpy als gut, über 0,1 bis 0,25 als verbesserungsbedürftig und über 0,25 als schlecht.
- Prüfen Sie reservierten Platz für Bilder, Anzeigen und eingebettete Inhalte sowie Schriftwechsel. Das sind mögliche Ursachen; der Screpy-Wert identifiziert kein verschobenes Element.
- Ein niedriger CLS im Ladetest schließt spätere Verschiebungen während eines Besuchs nicht aus. Prüfen Sie die tatsächliche Interaktion und Felddaten, wenn das Problem erst nach dem Laden auftritt.
CLS
0,04Total Blocking Time prüfen
Total Blocking Time macht Arbeit des Hauptthreads sichtbar, die Eingaben während des Ladens verzögern kann. Lesen Sie TBT zusammen mit LCP und FCP: Schnell sichtbarer Inhalt bedeutet nicht zwangsläufig, dass die Seite schnell reagiert.
- TBT wird in Millisekunden angezeigt: bis einschließlich 200 ms gut, über 200 ms bis 600 ms verbesserungsbedürftig und über 600 ms schlecht.
- Die Blockierungszeit summiert die Anteile langer Aufgaben oberhalb von 50 ms im Messzeitraum. Sie ist nicht die gesamte JavaScript-Laufzeit.
- Analysieren Sie bei hohem TBT lange Aufgaben und unnötige Skripte mit Entwicklerwerkzeugen, bevor Sie Code ändern. Der Dashboard-Wert ordnet die Verzögerung keinem bestimmten Skript zu.
- TBT ist nicht INP. INP misst Interaktionen und lässt sich mit solchen Interaktionen auch im Labor testen; diese Screpy-Funktion liefert keinen INP-Messwert.
example.comLabor
TBT180 ms
FCP und TTFB vergleichen
First Contentful Paint kennzeichnet den ersten sichtbaren Inhalt, Time to First Byte den Beginn der Antwort. Beide Werte derselben URL helfen, eine frühe Antwortverzögerung von der Zeit bis zur sichtbaren Darstellung zu unterscheiden.
- FCP erscheint in Sekunden: bis einschließlich 1,8 s gut, über 1,8 s bis 3 s verbesserungsbedürftig und über 3 s schlecht.
- TTFB erscheint in Millisekunden: bis einschließlich 800 ms gut, über 800 ms bis 1.800 ms verbesserungsbedürftig und über 1.800 ms schlecht. Verbindung, Weiterleitungen und Antwortverhalten können den Wert beeinflussen.
- Ist TTFB niedrig, FCP aber langsam, untersuchen Sie den verzögerten ersten Bildaufbau. Bei langsamer Antwort prüfen Sie zuerst die Auslieferung; kein Einzelwert beweist eine Backend- oder Darstellungsursache.
Labor2.100 ms
TTFB450 ms
FCP1.100 ms
LCP2.100 ms
TBT95 ms
Wichtige Website-Seiten überwachen
Überwachen Sie eine überschaubare Auswahl öffentlicher Projektseiten, statt ein einzelnes Startseitenergebnis auf die gesamte Website zu übertragen. Nutzen Sie das projektbezogene Kontingent Ihres Tarifs für Seiten, bei denen Lade- oder Layoutprobleme besonders zählen.
- Die Projektstartseite wird bei der Projekterstellung hinzugefügt. Weitere öffentliche URLs der Projektdomain oder ihrer Subdomains lassen sich hinzufügen, wenn Ihr Tarif die Überwachung erlaubt.
- Wählen Sie repräsentative Produkt-, Kategorie-, Artikel- und Konversionseinstiegsseiten. Ein wiederkehrendes Vorlagenproblem kann weitere Untersuchungen rechtfertigen; ein URL-Test misst aber nicht jede Seite dieser Vorlage.
- Die Eingabe vereinheitlicht Protokoll und Host, ergänzt fehlendes HTTPS und entfernt Fragmente. Pfade und Abfrageparameter bleiben relevant; dieselbe normalisierte URL wird kein zweites Mal angenommen.
- Eine hinzugefügte Seite erscheint erst nach ihrem ersten geplanten Prüfversuch in der Ergebnistabelle. Das Hinzufügen startet keinen sofortigen Test.
- Bestätigen Sie das Entfernen, um die Überwachung zu beenden und einen Kontingentplatz freizugeben. Der überwachte Eintrag wird entfernt, nicht die Seite von Ihrer Website oder aus Google.
example.comLabor
/1,4 s/shop/linen2,8 s/guides/seo1,9 sStartseitenleistung ansehen
Die Übersicht oberhalb der URL-Tabelle verwendet die geprüfte Projektstartseite. Sie vereint aktuelle Labormessungen einschließlich Speed Index; die Tabelle darunter ordnet ihre fünf angezeigten Kennzahlen weiterhin jeder überwachten URL einzeln zu.
- Die Startseitenübersicht enthält FCP, LCP, CLS, TTFB, TBT und Speed Index. Das sind Startseitenwerte, kein Durchschnitt der überwachten Seiten.
- Speed Index beschreibt, wie schnell sichtbarer Inhalt beim Laden aufgebaut wird. Screpy zeigt Sekunden: bis einschließlich 3,4 s gut, über 3,4 s bis 5,8 s verbesserungsbedürftig und über 5,8 s schlecht.
- Jeder Balken steht für die aktuelle Messung. Er ist weder ein gespeicherter Verlauf noch ein Besucheranteil oder Googles 75. Perzentil aus Felddaten.
- Ohne geprüftes Startseitenergebnis ist die Übersicht nicht verfügbar. Das Ergebnis einer anderen überwachten URL wird nicht als Ersatz verwendet.
example.comLabor
LCP2,1 s
TBT180 ms
CLS0,04
Tägliche Labortests verfolgen
Aktive, berechtigte Seiten werden nach einem Tag für eine weitere geplante Prüfung fällig. Sehen Sie nach einer gezielten Änderung das aktuelle Ergebnis an und berücksichtigen Sie Tarifberechtigung und Verfügbarkeit der Prüfung statt einer garantierten Uhrzeit.
- Sortieren Sie Ergebnisse nach Seiten-URL oder CWV-Status. FCP, LCP, CLS, TTFB und TBT bleiben für die jeweilige geprüfte URL sichtbar.
- Der CWV-Status nutzt die schlechteste verfügbare Einstufung aus LCP, CLS und TBT. PASS bedeutet, dass diese vorhandenen Werte gut sind; FAIL umfasst verbesserungsbedürftige und schlechte Ergebnisse.
- Prüfen Sie fehlende Werte auch bei PASS. Eine fehlende Kennzahl zählt nicht als gesunde Messung, und der Status bestätigt keine Google-Bewertung von LCP, INP und CLS aus Felddaten.
- Keine Daten bedeutet, dass die Laborbewertung nicht verfügbar ist. Ein fehlender Anzeigewert ist keine Null, und eine erfolglose Prüfung beweist keine gesunde Seite.
- Notieren Sie die aktuellen Werte vor einer Korrektur und vergleichen Sie später dieselbe URL. Die Tabelle zeigt aktuelle Ergebnisse statt eines gespeicherten Vorher-Nachher-Verlaufs.
Täglich09:00
123456789101112131415161718192021
Leistungsdaten mit SEO MCP lesen
Nutzen Sie die gespeicherte Laborübersicht der Startseite im KI-Gespräch oder in einer REST-Integration. Lassen Sie vorhandene Messungen erklären und eine gezielte Untersuchung vorschlagen; unterscheiden Sie dabei Belege von einer empfohlenen Korrektur.
- Authentifizieren Sie sich und wählen Sie ein zugängliches Projekt. Der REST-Endpunkt setzt außerdem voraus, dass Core Web Vitals im Projekttarif verfügbar ist.
- Die Antwort enthält Startseiten-URL, gespeicherten Prüfzeitpunkt und vorhandene FCP-, LCP-, CLS-, TTFB-, TBT- und Speed-Index-Werte. Es sind Startseitendaten, keine Liste aller überwachten Seiten.
- Ohne geprüfte Startseite gibt es keine Übersicht; einzelne fehlende Messungen bleiben nicht verfügbar. Lassen Sie den Assistenten Datenlücken benennen, bevor er Schlüsse zieht.
- Das Core-Web-Vitals-MCP-Werkzeug liest gespeicherte Daten. Es startet keinen neuen Test, fügt keine Seiten hinzu, identifiziert kein verantwortliches Element und wandelt TBT nicht in INP um.
GET
/projectsJSON{
"data": [
{ "domain": "example.com" }
]
}Über Core Web Vitals sprechen. Mit SEO MCP.
Lesen Sie die gespeicherte Laborübersicht Ihrer Projektstartseite über SEO MCP. Lassen Sie vorhandene Kennzahlen mit URL und Prüfzeitpunkt erklären und wählen Sie eine Untersuchung, ohne einen Bericht aller Seiten oder einen neuen Test vorauszusetzen.
- Screpy: Hallo! Sehen wir uns Core Web Vitals für example.com an. Was möchten Sie wissen?
- Sie: Erkläre die gespeicherten Laborwerte der Startseite von example.com und benenne offene Fragen.
- Screpy: In diesem Startseitenbeispiel beträgt LCP 3,2 s und ist verbesserungsbedürftig; CLS ist mit 0,04 gut. Prüfen Sie gespeicherte URL und Prüfzeitpunkt vor der Nutzung. Diese zwei Zahlen zeigen nicht alle Kennzahlen, messen kein INP und identifizieren kein verantwortliches Element. Ich kann eine Untersuchung vorschlagen, aber keinen neuen Test ausführen. Beispielwerte der Startseite im Labor: LCP: 3,2 s. CLS: 0,04.
- Sie: Mach daraus einen kurzen Maßnahmenplan.
- Screpy: Ich trenne Befunde und Empfehlungen. Prüfen Sie die Belege, wählen Sie eine Änderung und kontrollieren Sie anschließend die Ergebnisse. Ihre nächsten Schritte: Prüfen: Quelle und Datum jedes Befunds kontrollieren.. Entscheiden: Die erste Änderung auswählen.. Verifizieren: Ergebnisse nach der Änderung vergleichen..
- Sie: Kannst du die Belege verständlich erklären?
- Screpy: Ja. Fragen Sie nach einem unterstützten Ergebnis. Ich erkläre, was es zeigt, woher es stammt und was unklar bleibt. Fehlende Daten bleiben nicht verfügbar; Empfehlungen sind keine automatischen Korrekturen.
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.
-
Eine repräsentative öffentliche URL wählen
Wählen Sie öffentliche URLs der Projektdomain oder ihrer Subdomains. Beginnen Sie innerhalb des Projektkontingents mit Startseite, Konversionseinstieg und einer repräsentativen URL einer wichtigen Vorlage.
-
Geplante Laborprüfung als Ausgangsbasis nutzen
Berechtigte aktive URLs erhalten wiederkehrende geplante Labortests. Prüfen Sie nach dem ersten Versuch die vorhandenen FCP-, LCP-, CLS-, TTFB- und TBT-Werte der getesteten URL; die getrennte Startseitenübersicht enthält zusätzlich Speed Index.
-
Der schwachen Metrik zu einer Hypothese folgen
Wählen Sie anhand der schwachen Kennzahl ein konkretes Untersuchungsthema: LCP für Hauptinhalte, CLS für unerwartete Verschiebungen, TBT für blockierende Arbeit und FCP mit TTFB für den frühen Ladevorgang. Speed Index der Startseite ergänzt den sichtbaren Fortschritt, beweist aber keine Ursache.
-
Eine Ursache ändern und erneut messen
Notieren Sie vor einer gezielten Änderung die aktuellen Werte, behalten Sie die URL bei und vergleichen Sie ein späteres geplantes Ergebnis. Das Dashboard zeigt aktuelle Messungen; bewahren Sie den früheren Ausgangswert separat auf und untersuchen Sie wiederkehrende Änderungen statt einer einzelnen Schwankung.
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.
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 beschreibt blockierende Arbeit während des gemessenen Ladezeitraums. INP braucht Interaktionsmessungen und lässt sich mit Interaktionen auch im Labor testen; diese Screpy-Funktion liefert aber kein INP und ersetzt keine Belege zur Reaktionsfähigkeit realer Nutzer.
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.
Überwachen Sie ausgewählte öffentliche Projekt-URLs mit wiederkehrenden Labortests: fünf Tabellenkennzahlen und eine getrennte Startseitenübersicht mit sechs Kennzahlen.
Crawlen Sie die Website nach Links, Bildern und Onpage-Problemen rund um eine betroffene URL oder Vorlage. Verwenden Sie die Befunde als technischen Kontext, nicht als Leistungsaufzeichnung.
Verstehen Sie Umfang, Zeitpunkt und Grenzen der Screpy-Labordaten, bevor Sie sie mit echten Nutzerberichten vergleichen.
Screpy-Dokumentation
Labor-Performance-Prüfungen richtig interpretieren
Nutzen Sie den Leitfaden zur URL-Auswahl, zum Lesen der Laborkennzahlen und zur Abgrenzung von Felddaten. Halten Sie einen Ausgangswert separat fest, bevor Sie eine gezielte Verbesserung mit einem späteren Ergebnis vergleichen.
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.
Warum zeigt Screpy TBT statt INP?
Diese Funktion misst das Laden und liefert TBT als Blockierungsdiagnose; die für INP nötigen Interaktionen misst sie nicht. INP lässt sich durch ausgeführte Interaktionen im Labor testen. Ein TBT-Wert ist aber kein INP-Wert und beschreibt nicht jede Interaktion nach dem Laden.
Welche Seiten sollte ich zuerst überwachen?
Beginnen Sie mit Startseite, wichtigen öffentlichen Landingpages, Konversionseinstiegen und einer repräsentativen URL je wichtiger Vorlage. Hinzugefügte URLs müssen zur Projektdomain oder ihren Subdomains gehören und ins Kontingent passen. Eine Vorlagenstichprobe testet nicht alle Seiten dieser Vorlage.
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.
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.
Wie oft werden überwachte URLs geprüft?
Aktive berechtigte URLs werden nach einem Tag für eine weitere geplante Prüfung fällig. Projekttarif und Prüfverfügbarkeit beeinflussen den Abschluss; ein Ergebnis täglich zur gleichen Uhrzeit ist nicht garantiert. Eine neue URL erscheint nach ihrem ersten Prüfversuch in der Ergebnistabelle.
Was misst das Core-Web-Vitals-Monitoring von Screpy?
Screpys URL-Tabelle zeigt Laborwerte für FCP, LCP, CLS, TTFB und TBT. Die geprüfte Startseitenübersicht ergänzt Speed Index. Die Tabelle verwendet PASS/FAIL; authentifizierte API- und MCP-Antworten enthalten außerdem gespeicherte Startseiten-URL und Prüfzeitpunkt. Es sind keine Felddaten realer Nutzer.
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.
Bedeutet PASS in Screpy, dass die URL Googles Core Web Vitals besteht?
Nein. Screpys Tabellenstatus nutzt die schlechteste verfügbare Laboreinstufung aus LCP, CLS und TBT; Werte können fehlen. Googles Feldbewertung verwendet echte Core-Web-Vitals-Nutzerdaten einschließlich INP mit eigenen Regeln für Datenabdeckung und Perzentile. Prüfen Sie vorhandene Kennzahlen und den passenden Feldbericht, bevor Sie diesen Schluss ziehen.