Jeśli po zobaczeniu zielonego wyniku szybkości szukają Państwo odpowiedzi na hasło „ocena Core Web Vitals niezaliczona”, najpierw warto sprawdzić, jakie dane opisuje każdy wynik. PageSpeed Insights (PSI) łączy dane z rzeczywistych wizyt z osobnym testem w kontrolowanych warunkach. Przed zakupem narzędzia lub zleceniem przebudowy strony proszę zapisać adres, urządzenie, zakres danych i wskaźnik, który nie spełnił wymagań.
Zaczynamy od takiego zapisu, ponieważ polecenie „zrobić zielony wynik” pozostawia zbyt wiele niewiadomych. Programista musi wiedzieć, który aspekt korzystania ze strony wymaga poprawy i jakie dowody pozwolą uznać naprawę za przydatną.
Ocena Core Web Vitals niezaliczona: co zmierzył raport?
Ocena opisuje zarejestrowane doświadczenia odwiedzających, natomiast sekcja Lighthouse zawiera test diagnostyczny. Dokumentacja PageSpeed Insights Google wyjaśnia, że dane z rzeczywistych wizyt pochodzą z Chrome User Experience Report, czyli CrUX, i obejmują ostatnie 28 dni w kroczącym okresie zbierania danych. Świeży test diagnostyczny i ta historia mogą więc dawać różne wyniki.
Warunki testów się różnią. Jeden kontrolowany test nie obejmie każdego urządzenia, połączenia i działania występującego podczas rzeczywistych wizyt. Warto użyć go do zbadania możliwej przyczyny, a przy ustalaniu, co nadal wymaga poprawy, uwzględniać także dane odwiedzających.
Wynik może dotyczyć szerszego zakresu. Jeśli dla konkretnej strony jest za mało danych, PSI może pokazać dane dla origin, czyli wspólnego źródła adresów określonego przez protokół i nazwę hosta. Taki wynik łączy wizyty na różnych stronach. Zanim potraktują go Państwo jako dowód dotyczący konkretnej strony produktu lub usługi, proszę sprawdzić zakres widoczny w raporcie.
Okres obejmuje wcześniejsze wizyty. Zmiana wprowadzona dzisiaj nie przepisuje wczorajszych obserwacji. Proszę zapisać datę wdrożenia, aby odróżnić natychmiastowe sprawdzenie poprawki od późniejszych danych o odwiedzających.
Dzięki temu każdy raport ma własne zadanie: dane odwiedzających wskazują doświadczenie wymagające zbadania, a test kontrolowany pomaga je odtworzyć i przeanalizować.
Który wskaźnik wymaga uwagi?
Przed wyborem poprawki proszę osobno sprawdzić LCP, INP i CLS. Wytyczne Google dotyczące Web Vitals rozróżniają wczytywanie, szybkość reakcji i stabilność wizualną. Poniższa tabela przedstawia progi oceny Dobra podane w tych wytycznych, oceniane na 75. percentylu dla odpowiedniej grupy urządzeń. Przewodnik Google po progach wyjaśnia 75. percentyl następująco: co najmniej 75% zmierzonych odsłon musi spełniać próg oceny Dobra dla danego wskaźnika. To coś innego niż średnia czy łączny wynik Lighthouse.
| Wskaźnik | Co opisuje | Próg oceny Dobra | O co zapytać osobę utrzymującą stronę |
|---|---|---|---|
| LCP, Largest Contentful Paint | Kiedy pojawia się największy widoczny element treści | Nie więcej niż 2,5 sekundy | Który element pojawia się z opóźnieniem i na jakim etapie wczytywania? |
| INP, Interaction to Next Paint | Jak szybko strona reaguje na interakcje | Nie więcej niż 200 milisekund | Które dotknięcie, kliknięcie lub naciśnięcie klawisza działa wolno w warunkach, w których występuje problem? |
| CLS, Cumulative Layout Shift | Nieoczekiwane przesunięcia układu | Nie więcej niż 0,1 | Który element się przesuwa i w którym momencie wizyty? |
Gdy dla wszystkich tych wskaźników jest wystarczająco dużo danych, zaliczenie w PSI wymaga oceny Dobra dla ich wartości na 75. percentylu. Jeśli dane INP są niewystarczające, dobre LCP i CLS nadal mogą pozwolić na zaliczenie. Jeśli brakuje wystarczających danych LCP lub CLS, PSI nie może ocenić danej strony ani całego origin.
Brak danych należy traktować jako niepewność. Metodologia CrUX Google wymaga wizyt spełniających kryteria pomiaru i wystarczającej popularności; nie podaje uniwersalnej minimalnej liczby odwiedzających. Brak wyniku nie oznacza, że nikt nie odwiedza strony, że korzysta się z niej dobrze ani że poprawka się nie udała.
Co mogą Państwo sprawdzić przed opłaceniem prac?
Przed wyborem narzędzia proszę zapisać raport wyjściowy i przejść na telefonie tę samą ścieżkę co klient. Potrzebny jest jasny opis problemu: strona, dane stojące za ostrzeżeniem i zachowanie, które można odtworzyć. Jeśli nie udaje się go odtworzyć, proszę zapisać to ograniczenie zamiast zastępować brakujące informacje domysłem.
- Proszę otworzyć w PSI konkretną stronę ważną dla biznesu. Należy zachować jej adres i datę raportu. Warto uwzględnić stronę docelową lub szablon istotny dla analizowanego zapytania albo zakupu.
- Proszę zapisać wybór urządzenia i zakres danych. Należy zanotować, czy sekcja danych z rzeczywistych wizyt dotyczy adresu URL, całego origin, czy wskazuje niewystarczające dane. Późniejsze porównania powinny korzystać z tego samego wyboru.
- Proszę wskazać wskaźnik wymagający uwagi. Punktem wyjścia są poszczególne wyniki Core Web Vitals, a sekcja diagnostyczna dostarcza wskazówek. Brakujące próbki trzeba nadal wyraźnie oznaczać.
- Proszę wykonać na telefonie rzeczywiste zadanie. Otworzyć menu, użyć odpowiedniego filtra lub wypełnić odpowiedni formularz. Zapisać, co wczytuje się późno, reaguje powoli lub niespodziewanie się przesuwa.
- Proszę powiązać wskazówkę z testem. Osobę utrzymującą stronę warto poprosić o odtworzenie problematycznej czynności lub opóźnienia wczytywania oraz wyjaśnienie, co dany test może ustalić.
Szersze sprawdzenie obrazów, widżetów, pamięci podręcznej i hostingu opisuje nasz poradnik o typowych przyczynach wolnego działania strony. Bieżące zadanie warto ograniczyć do niezaliczonej oceny i dowodów potrzebnych do weryfikacji poprawki.
Co powinna obejmować poprawka?
Warto wybrać najmniejszą zmianę uzasadnioną diagnozą, a następnie uzgodnić sposób jej sprawdzenia. Punktem wyjścia powinny być dostępne już raporty i funkcje. Prace techniczne łatwiej ocenić, gdy wykonawca wskazuje stronę lub szablon, wyjaśnia wąskie gardło i zapewnia porównywalne warunki przed zmianą i po niej.
- Proszę dopasować propozycję do wskaźnika. Przewodnik web.dev dotyczący LCP rozróżnia opóźnienia odpowiedzi, wykrycia zasobu, wczytywania i renderowania największego elementu. Przewodnik INP skupia analizę na powolnych interakcjach. Poradnik CLS uwzględnia przesunięcia występujące po początkowym wczytaniu. Warto poprosić o odpowiednie dowody zamiast ogólnej obietnicy przyspieszenia strony.
- Proszę usunąć wskazaną przyczynę i ponownie sprawdzić zachowanie. Celowana poprawka zasobu lub szablonu może być częścią tworzenia i utrzymania stron internetowych. Należy zapisać, co i kiedy zmieniono, oraz sposób wycofania zmiany, jeśli jest to możliwe.
- Proszę sprawdzić, czy zadanie klienta nadal da się wykonać. Trzeba przetestować nawigację, formularze i etapy zakupu istotne dla strony. Mechanizmy zgody muszą nadal działać; należy zbadać ich zachowanie i układ, zachowując zgodę zgodną z prawem.
- Proszę ustalić, czy potrzeba więcej danych. Jeśli dostępne raporty nie pozwalają wskazać problematycznej interakcji lub strony, dodatkowe pomiary mogą pomóc. Przed dodaniem płatnej usługi warto zapytać, na jakie pytanie odpowie proponowany monitoring.
Jeśli priorytet techniczny jest niejasny, prace nad technicznym SEO można zacząć od diagnozy i listy prac możliwej do oceny. Przebudowa strony lub pakiet optymalizacji wymagają osobnego uzasadnienia.
Mogą Państwo skopiować tę kartę zadania i pozostawić nieznane pola puste:
Strona i zadanie biznesowe:
Urządzenie i zakres danych z rzeczywistych wizyt:
Wskaźnik wymagający uwagi:
Zaobserwowane zachowanie i warunki testu:
Proponowana przyczyna i zmiana:
Data wdrożenia:
Porównywalne sprawdzenie po zmianie:
Późniejsza obserwacja rzeczywistych wizyt i pozostała niepewność:Jak sprawdzić, czy prace pomogły?
Najpierw należy ocenić zmienione zachowanie, a potem porównać późniejsze dane z rzeczywistych wizyt w tym samym zakresie. Według dokumentacji PSI aktualizuje te dane codziennie, zachowując kroczące okno zbierania danych. Data wdrożenia powinna pozostać przy zapisie. To okno nie jest obiecanym odliczaniem do zaliczenia oceny.
Proszę porównać wybrany wskaźnik i zadanie klienta w podobnych warunkach testowych. Jeśli objaw pozostaje, trzeba wrócić do diagnozy. Jeśli test wykazuje poprawę, ale późniejsze dane z wizyt jej nie potwierdzają, należy ponownie zbadać odpowiednie strony i warunki korzystania z nich. Brak danych z rzeczywistych wizyt powinien pozostać wyraźnie zapisanym ograniczeniem.
W czym pomagamy
Zaczynamy od raportu, ważnych stron i zadania, które możemy odtworzyć. Osobno określamy proponowaną poprawkę, jej sprawdzenie i późniejsze dane od odwiedzających, aby każda decyzja miała podstawę, którą mogą Państwo ocenić. Brief dotyczący wydajności strony można zacząć od powyższej karty zadania; nieznane pola powinny pozostać widoczne.
