Główne landing pages
Monitoruj strony przedstawiające produkt, usługę lub kampanię, ponieważ wolne pierwsze doświadczenie może wpływać na odkrywanie i konwersję.
Monitoruj Core Web Vitals na najważniejszych stronach witryny
Śledź LCP, CLS i wskaźniki ładowania wybranych publicznych stron domeny projektu. Sprawdzaj pięć metryk na adres URL oraz osobne podsumowanie strony głównej ze Speed Index, a konkretną poprawkę oceniaj późniejszym wynikiem. To kontrolowane testy, nie dane terenowe rzeczywistych użytkowników.
Kontrole Core Web Vitals
LCP
Znajdź wybrane adresy URL, na których główna treść pojawia się późno.
CLS
Sprawdź nieoczekiwane przesunięcia układu na wybranych adresach URL.
Codzienne pomiary laboratoryjne
Zanotuj aktualne wartości i sprawdź późniejszy wynik laboratoryjny po konkretnej poprawce.
Monitoruj Largest Contentful Paint
Largest Contentful Paint mierzy, kiedy największy kwalifikujący się obraz, blok tekstu lub film staje się widoczny w obszarze testu. Wartość LCP każdego monitorowanego adresu URL pomaga wybrać stronę wymagającą dokładniejszej analizy ładowania.
- Screpy wyświetla LCP w sekundach: do 2,5 s włącznie wynik jest dobry, powyżej 2,5 s do 4 s wymaga poprawy, a powyżej 4 s jest słaby.
- Szybki FCP przy wolnym LCP oznacza, że część treści pojawiła się przed głównym elementem. Sprawdź jego dostarczanie i wyświetlanie, zamiast zakładać, że cała strona była pusta.
- Potwierdź właściwy obraz, font lub opóźnienie wyświetlania w analizie wydajności prowadzonej przez programistę. Sama liczba nie wskazuje elementu ani odpowiedniej poprawki.
example.comLaboratorium
LCP2,1 s
Mierz Cumulative Layout Shift
Strona może ładować się szybko, a mimo to niespodziewanie przesunąć przycisk lub akapit. Cumulative Layout Shift podaje laboratoryjny wynik stabilności dla każdego monitorowanego adresu URL, pozwalając analizować ruch niezależnie od szybkości ładowania.
- CLS nie ma jednostki czasu: do 0,1 włącznie wynik w Screpy jest dobry, powyżej 0,1 do 0,25 wymaga poprawy, a powyżej 0,25 jest słaby.
- Sprawdź miejsce zarezerwowane na obrazy, reklamy i osadzone treści oraz zmiany fontów. To możliwe przyczyny; wynik Screpy nie wskazuje, który element się przesunął.
- Niski CLS w teście ładowania nie wyklucza późniejszych przesunięć podczas wizyty. Jeśli problem pojawia się po załadowaniu, sprawdź rzeczywistą interakcję i dane terenowe.
CLS
0,04Sprawdzaj Total Blocking Time
Total Blocking Time pomaga wykrywać pracę głównego wątku, która może opóźniać reakcję na dane wejściowe podczas ładowania. Czytaj TBT razem z LCP i FCP: szybkie pojawienie się treści nie musi oznaczać szybkiej reakcji strony.
- TBT jest wyświetlany w milisekundach: do 200 ms włącznie wynik jest dobry, powyżej 200 ms do 600 ms wymaga poprawy, a powyżej 600 ms jest słaby.
- Czas blokowania sumuje części długich zadań przekraczające 50 ms w okresie pomiaru. Nie jest to całkowity czas wykonywania JavaScript.
- Przy wysokim TBT przeanalizuj długie zadania i zbędne skrypty narzędziami programistycznymi przed zmianą kodu. Wartość w panelu nie przypisuje opóźnienia konkretnemu skryptowi.
- TBT nie jest INP. INP mierzy interakcje i można go testować w laboratorium, wykonując te interakcje; ta funkcja Screpy nie podaje pomiaru INP.
example.comLaboratorium
TBT180 ms
Porównuj FCP i TTFB
First Contentful Paint oznacza pojawienie się pierwszej widocznej treści, a Time to First Byte początek odpowiedzi. Odczyt obu wartości dla tego samego adresu URL pomaga odróżnić początkowe opóźnienie odpowiedzi od czasu potrzebnego na wyświetlenie treści.
- FCP jest wyświetlany w sekundach: do 1,8 s włącznie wynik jest dobry, powyżej 1,8 s do 3 s wymaga poprawy, a powyżej 3 s jest słaby.
- TTFB jest wyświetlany w milisekundach: do 800 ms włącznie wynik jest dobry, powyżej 800 ms do 1800 ms wymaga poprawy, a powyżej 1800 ms jest słaby. Wpływ mogą mieć połączenie, przekierowania i zachowanie odpowiedzi.
- Jeśli TTFB jest niski, a FCP wolny, zbadaj, co opóźnia pierwsze wyświetlenie. Przy wolnej odpowiedzi zacznij od dostarczania; pojedyncza wartość nie dowodzi przyczyny po stronie serwera lub wyświetlania.
Laboratorium2100 ms
TTFB450 ms
FCP1100 ms
LCP2100 ms
TBT95 ms
Monitoruj ważne strony witryny
Śledź rozsądny zestaw publicznych stron projektu, zamiast uznawać wynik strony głównej za pomiar całej witryny. Wykorzystaj limit projektu w planie na strony, dla których problemy ładowania lub układu mają największe znaczenie.
- Strona główna jest dodawana podczas tworzenia projektu. Możesz dodać kolejne publiczne adresy URL z domeny projektu lub jej subdomen, jeśli plan pozwala na monitoring.
- Wybierz reprezentatywne strony produktów, kategorii, artykułów i wejścia do konwersji. Powtarzający się problem szablonu może uzasadnić szerszą analizę, ale test jednego adresu nie mierzy wszystkich stron tego szablonu.
- Przy dodawaniu normalizowane są protokół i host, brakujące HTTPS jest uzupełniane, a fragmenty usuwane. Ścieżki i parametry zapytania pozostają istotne; duplikat znormalizowanego adresu zostaje odrzucony.
- Dodana strona czeka na pierwszą zaplanowaną kontrolę, zanim pojawi się w tabeli wyników. Dodanie adresu nie uruchamia natychmiastowego testu.
- Potwierdź usunięcie, aby zatrzymać monitoring i zwolnić miejsce w limicie. Usuwany jest monitorowany wpis, nie strona z witryny ani z Google.
example.comLaboratorium
/1,4 s/shop/linen2,8 s/guides/seo1,9 sSprawdzaj wydajność strony głównej
Podsumowanie nad tabelą korzysta ze sprawdzonej strony głównej projektu. Łączy aktualne pomiary laboratoryjne, w tym Speed Index; tabela poniżej nadal przypisuje pięć wyświetlanych metryk każdemu monitorowanemu adresowi URL.
- W podsumowaniu strony głównej odczytasz FCP, LCP, CLS, TTFB, TBT i Speed Index. To wartości tej strony, a nie średnia monitorowanych stron.
- Speed Index opisuje, jak szybko widoczna treść powstaje podczas ładowania. Screpy pokazuje sekundy: do 3,4 s włącznie wynik jest dobry, powyżej 3,4 s do 5,8 s wymaga poprawy, a powyżej 5,8 s jest słaby.
- Każdy słupek przedstawia bieżący pomiar. Nie jest to zapisany trend, odsetek odwiedzających ani 75. percentyl danych terenowych Google.
- Bez sprawdzonego wyniku strony głównej podsumowanie jest niedostępne. Wynik innego monitorowanego adresu nie jest podstawiany w jego miejsce.
example.comLaboratorium
LCP2,1 s
TBT180 ms
CLS0,04
Śledź codzienne kontrole laboratoryjne
Aktywne strony spełniające warunki kwalifikują się do kolejnej zaplanowanej kontroli po jednym dniu. Po konkretnej zmianie sprawdź aktualny wynik, uwzględniając uprawnienia planu i dostępność kontroli zamiast oczekiwać testu o gwarantowanej dokładnej godzinie.
- Sortuj wyniki według adresu URL lub stanu CWV. FCP, LCP, CLS, TTFB i TBT pozostają widoczne dla każdego sprawdzonego adresu.
- Etykieta CWV wykorzystuje najgorszą dostępną klasyfikację LCP, CLS i TBT. PASS oznacza dobre dostępne wartości; FAIL obejmuje wyniki wymagające poprawy i słabe.
- Sprawdź brakujące wartości nawet przy etykiecie PASS. Brak metryki nie jest zdrowym pomiarem; etykieta nie potwierdza oceny Google opartej na terenowych LCP, INP i CLS.
- Brak danych oznacza niedostępną ocenę laboratoryjną. Brakująca wartość nie jest zerem, a nieudana kontrola nie dowodzi dobrej kondycji strony.
- Zanotuj aktualne wartości przed wdrożeniem poprawki i porównaj je z późniejszym wynikiem tego samego adresu. Tabela pokazuje aktualne wyniki, a nie zapisaną historię przed zmianą i po niej.
Codziennie09:00
123456789101112131415161718192021
Odczytuj dane przez SEO MCP
Wykorzystaj zapisane laboratoryjne podsumowanie strony głównej w rozmowie z AI lub integracji REST. Poproś o wyjaśnienie dostępnych pomiarów i ukierunkowaną analizę, oddzielając dowody od proponowanej poprawki.
- Uwierzytelnij się i wybierz projekt, do którego masz dostęp. Dostęp REST wymaga też dostępności Core Web Vitals w planie projektu.
- Odpowiedź zawiera adres strony głównej, zapisany czas kontroli i dostępne wartości FCP, LCP, CLS, TTFB, TBT oraz Speed Index. To dane strony głównej, nie lista wszystkich monitorowanych stron.
- Bez sprawdzonej strony głównej nie ma podsumowania; poszczególne brakujące pomiary pozostają niedostępne. Poproś asystenta o wskazanie braków przed wyciąganiem wniosków.
- Narzędzie MCP Core Web Vitals odczytuje zapisane dane. Nie uruchamia testu, nie dodaje stron, nie identyfikuje odpowiedzialnego elementu i nie zamienia TBT w INP.
GET
/projectsJSON{
"data": [
{ "domain": "example.com" }
]
}Porozmawiaj o Core Web Vitals. Z SEO MCP.
Odczytaj zapisane laboratoryjne podsumowanie strony głównej projektu przez SEO MCP. Wyjaśnij dostępne metryki z adresem i czasem kontroli, a potem wybierz analizę bez zakładania raportu wszystkich stron lub nowego testu.
- Screpy: Cześć! Przyjrzyjmy się Core Web Vitals dla example.com. Co chcesz wiedzieć?
- Ty: Wyjaśnij zapisane wyniki laboratoryjne strony głównej example.com i wskaż, czego nadal nie wiadomo.
- Screpy: W tym przykładzie strony głównej LCP wynosi 3,2 s i wymaga poprawy, a CLS 0,04 jest dobry. Sprawdź zapisany adres i czas przed użyciem wartości. Te dwie liczby nie pokazują wszystkich metryk, nie mierzą INP i nie wskazują odpowiedzialnego elementu. Mogę zaproponować analizę, ale nie wykonać nowego testu. Przykładowe wartości laboratoryjne strony głównej: LCP: 3,2 s. CLS: 0,04.
- Ty: Zamień to w krótki plan działania.
- Screpy: Oddzielę ustalenia od rekomendacji. Sprawdź dowody, wybierz jedną zmianę i później zweryfikuj wyniki. Twoje następne kroki: Sprawdź: Zweryfikuj źródło i datę każdego ustalenia.. Zdecyduj: Wybierz pierwszą zmianę.. Zweryfikuj: Porównaj wyniki po zmianie..
- Ty: Możesz wyjaśnić dowody prostymi słowami?
- Screpy: Tak. Zapytaj o obsługiwany wynik, a wyjaśnię, co pokazuje, skąd pochodzi i co pozostaje niepewne. Brakujące dane pozostają niedostępne; rekomendacje nie są automatycznymi poprawkami.
Zamień wolny adres URL w testowalną poprawkę wydajności.
Zachowaj stabilny adres URL i metodę pomiaru, użyj najsłabszej metryki do zawężenia analizy i zweryfikuj jedną zmianę późniejszą kontrolą.
-
Wybierz reprezentatywny publiczny adres URL
Wybierz publiczne adresy domeny projektu lub jej subdomen. W ramach limitu zacznij od strony głównej, wejścia do konwersji i reprezentatywnego adresu ważnego szablonu.
-
Ustal bazę zaplanowaną kontrolą laboratoryjną
Uprawnione aktywne adresy otrzymują cykliczne zaplanowane kontrole laboratoryjne. Po pierwszej próbie sprawdź dostępne FCP, LCP, CLS, TTFB i TBT badanego adresu; osobne podsumowanie strony głównej zawiera również Speed Index.
-
Podążaj za słabą metryką do konkretnej hipotezy
Wybierz konkretną analizę według słabej metryki: LCP dla głównej treści, CLS dla nieoczekiwanych przesunięć, TBT dla blokującej pracy, FCP z TTFB dla początkowego ładowania. Speed Index strony głównej opisuje postęp wizualny, nie dowodzi przyczyny.
-
Zmień jedną przyczynę i zmierz ponownie
Zanotuj wartości przed konkretną zmianą, zachowaj adres i porównaj późniejszy zaplanowany wynik. Panel pokazuje aktualne pomiary: przechowuj wcześniejszą bazę osobno i badaj powtarzające się zmiany zamiast uznawać pojedyncze wahanie za dowód.
Monitoruj strony, na których regresja miałaby największe znaczenie.
Mały, reprezentatywny zestaw adresów URL łatwiej analizować niż dashboard pełen mało wartościowych stron. Zacznij od ścieżek krytycznych dla biznesu i wielokrotnego użytku szablonów.
Wspólne szablony stron
Wybierz reprezentatywny adres URL produktu, kategorii, artykułu lub dokumentacji, aby ujawnić problemy wydajności powtarzające się w tym samym szablonie.
Ścieżki konwersji
Monitoruj strony cen, rejestracji, leadów i wejścia do checkoutu, gdy skrypty, embedy, eksperymenty lub tagi zewnętrzne zmieniają ich wydajność.
Strony wrażliwe na wdrożenia
Śledź adresy URL dotknięte redesignami, zmianami frameworka, nowymi multimediami, aktualizacjami tag managera lub dostarczania, zanim rozszerzysz wzorzec.
Interpretuj wyniki laboratoryjne bez przesady.
Screpy ma ułatwiać podejmowanie działań na podstawie cyklicznych kontroli wydajności. Te granice zachowują dokładność, gdy pytanie dotyczy danych polowych, diagnozy przyczynowej lub wpływu na pozycje.
Dane laboratoryjne, nie polowe
Screpy wykonuje kontrolowane testy stron. Wynik nie reprezentuje opóźnionego zbioru danych rzeczywistych użytkowników z Chrome UX Report ani Google Search Console.
TBT nie jest INP
TBT opisuje blokującą pracę w mierzonym okresie ładowania. INP wymaga pomiarów interakcji i można go testować w laboratorium, wykonując interakcje; ta funkcja Screpy nie podaje INP i nie zastępuje dowodów reaktywności rzeczywistych użytkowników.
Ocena nie jest przyczyną
Słaba metryka wskazuje miejsce analizy. Potwierdź konkretny element, żądanie, skrypt, szablon lub zachowanie serwera przed decyzją o zmianie.
Wydajność nie gwarantuje pozycji
Dobre doświadczenie strony wspiera użytkowników i jakość wyszukiwania, ale nie zastępuje trafnej treści, crawlowalności, indeksowania, linków ani innych sygnałów wyszukiwania.
Użyj procesu wydajności odpowiedniego do pytania.
Monitoruj wybrane adresy URL pod kątem cyklicznych wyników laboratoryjnych, audytuj szerszą witrynę pod kątem wzorców technicznych lub poznaj metodologię przed porównaniem Screpy z raportem danych polowych.
Monitoruj wybrane publiczne adresy projektu cyklicznymi kontrolami: pięć metryk w tabeli i sześć w osobnym podsumowaniu strony głównej.
Przeskanuj witrynę pod kątem linków, obrazów i problemów strony wokół zmienionego adresu lub szablonu. Użyj ustaleń jako kontekstu technicznego, a nie szczegółowego zapisu wydajności.
Poznaj zakres, czas i ograniczenia danych laboratoryjnych Screpy przed porównaniem ich z raportami rzeczywistych użytkowników.
Dokumentacja Screpy
Dowiedz się, jak interpretować kontrole laboratoryjne
Użyj przewodnika do wyboru adresów, odczytu metryk laboratoryjnych i odróżniania ich od danych terenowych. Zapisz bazę oddzielnie przed porównaniem konkretnej poprawki z późniejszym wynikiem.
Odpowiedzi na pytania o monitoring Core Web Vitals.
Poznaj dane laboratoryjne i terenowe, LCP, CLS, TBT, pomocnicze metryki szybkości, codzienne kontrole, wybór URL-i, werdykty i ograniczenia twierdzeń o doświadczeniu strony.
Które strony monitorować najpierw?
Zacznij od strony głównej, ważnych publicznych stron wejściowych, wejść do konwersji i reprezentatywnego adresu każdego istotnego szablonu. Dodane adresy muszą należeć do domeny projektu lub jej subdomen i mieścić się w limicie. Próbka szablonu nie testuje wszystkich jego stron.
Co mierzy Screpy Core Web Vitals Monitoring?
Tabela adresów Screpy pokazuje laboratoryjne FCP, LCP, CLS, TTFB i TBT. Podsumowanie sprawdzonej strony głównej dodaje Speed Index. Tabela używa PASS/FAIL; uwierzytelnione odpowiedzi API i MCP zawierają też adres strony głównej i zapisany czas kontroli. Nie są to pomiary rzeczywistych użytkowników.
Jak często sprawdzane są monitorowane adresy URL?
Uprawnione aktywne adresy kwalifikują się do następnej zaplanowanej kontroli po jednym dniu. Plan projektu i dostępność kontroli wpływają na jej ukończenie; wynik codziennie o tej samej godzinie nie jest gwarantowany. Nowy adres pojawia się w tabeli po pierwszej próbie kontroli.
Czy PASS w Screpy oznacza, że adres spełnia Core Web Vitals Google?
Nie. Ocena tabeli wykorzystuje najgorszą dostępną klasyfikację laboratoryjnych LCP, CLS i TBT, a wartości mogą być niepełne. Google ocenia dane rzeczywistych użytkowników, w tym INP, zgodnie z własnymi zasadami pokrycia i percentyli. Sprawdź dostępne metryki i właściwy raport terenowy przed wyciągnięciem takiego wniosku.
Dlaczego Screpy pokazuje TBT zamiast INP?
Ta funkcja mierzy ładowanie i podaje TBT jako diagnostykę blokowania; nie mierzy interakcji potrzebnych dla INP. INP można testować w laboratorium, wykonując interakcje, ale TBT nie jest INP i nie opisuje wszystkich interakcji po załadowaniu.
Które metryki są oficjalnymi Core Web Vitals?
Google definiuje obecnie Largest Contentful Paint, Interaction to Next Paint i Cumulative Layout Shift jako Core Web Vitals. Screpy mierzy LCP i CLS laboratoryjnie, a TBT raportuje jako diagnostykę responsywności obok FCP, TTFB i Speed Index.
Czy poprawa Core Web Vitals zagwarantuje wyższe pozycje?
Nie. Google zaleca dobre Core Web Vitals dla użytkowników i wyszukiwarki, ale doświadczenie strony jest tylko częścią znacznie szerszego zestawu sygnałów. Trafna treść może nadal rankować przy słabszym doświadczeniu strony, a szybka strona nie gwarantuje pozycji.
Czy dane Screpy Core Web Vitals pochodzą od prawdziwych użytkowników?
Nie. Screpy raportuje kontrolowane pomiary laboratoryjne sprawdzanego URL-a. Dane terenowe z Chrome UX Report lub Google Search Console odzwierciedlają rzeczywiste wizyty i mogą się różnić.