Szybkość i stabilność działania strony są częścią szeroko rozumianego page experience, a Core Web Vitals należą do sygnałów, które Google może uwzględniać w swoich systemach rankingowych. Nie należy jednak traktować ich jako prostego „boostera dla pozycji”. Dobre wyniki CWV wspierają SEO, ale nie zastępują jakości treści, dopasowania do intencji użytkownika, autorytetu domeny czy poprawnej indeksacji.
Większość specjalistów sięga po PageSpeed Insights, choć równie cenne dane oferuje Google Search Console – w raporcie nazywanym potocznie raportem prędkości, a formalnie funkcjonującym pod hasłem „Podstawowe wskaźniki internetowe”. Dla osób, które kojarzą jeszcze dawny, samodzielny Speed Report, to praktycznie nowy raport – z innym układem, innymi metrykami i znacznie głębszym kontekstem. Pokażę, jak go znaleźć, jak go czytać i jak wyciągnąć z niego wnioski, których nie zapewni żadne inne narzędzie.
Spis treści
Kartka z kalendarza
Google od kilku lat sygnalizuje, że szybkość ładowania to nie kwestia kosmetyki, ale wymierny czynnik rankingowy. Pierwszy duży krok w tę stronę przyniósł Page Experience Update z 2021 roku. W marcu 2024 metryka INP zastąpiła FID na pozycji jednego z trzech filarów oceny wydajności. W listopadzie 2024 Google usunęło z Search Console zbiorczy raport Page Experience, pozostawiając osobne raporty Core Web Vitals oraz HTTPS. Mimo tych przetasowań wielu właścicieli serwisów wciąż patrzy wyłącznie na wynik z PageSpeed Insights i interpretuje pojedyncze pomiary laboratoryjne tak, jakby decydowały o pozycji w wyszukiwarce.
A przecież w Google Search Console od dawna działa raport, który pokazuje to, co naprawdę „widzi” Google – dane od realnych użytkowników, agregowane z Chrome User Experience Report. To właśnie ten zbiór nazywany przez seowców „raportem prędkości” (formalnie: „Podstawowe wskaźniki internetowe” / Core Web Vitals) jest punktem wyjścia każdej rozsądnej optymalizacji performance’u.
Gdzie znaleźć raport prędkości strony w Google Search Console?
Ścieżka jest prosta, choć drobne zmiany w lewym menu GSC potrafią wybić z rytmu osoby, które dawno tu nie zaglądały. Po zalogowaniu się na search.google.com/search-console i wybraniu odpowiedniej usługi należy w panelu bocznym rozwinąć sekcję Eksperymenty i personalizacja, a następnie kliknąć pozycję Podstawowe wskaźniki internetowe.
Tu drobne, ale ważne wyjaśnienie. Pierwotny „Raport prędkości” (Speed Report), który Google wprowadziło w 2019 roku jako odrębny moduł, dawno został zintegrowany z Core Web Vitals i nie funkcjonuje pod osobną nazwą. Dziś, niezależnie od tego, czy mówimy o „raporcie prędkości”, „raporcie szybkości” czy „Podstawowych wskaźnikach internetowych”, chodzi dokładnie o ten sam ekran – i o trzy te same metryki: LCP, INP (oparty na diagnostyce LoAF) oraz CLS.
Dostęp do raportu wymaga zweryfikowanej własności domeny lub prefiksu URL. W przypadku usługi typu Domain Property zobaczymy zagregowane dane dla wszystkich subdomen i protokołów – to bywa wygodne, ale potrafi też zaciemniać obraz, jeśli serwis składa się z kilku różnych szablonów (np. blog na osobnym frameworku, sklep na czymś innym, landing pages na trzecim CMS-ie).
Jak raport prędkości wygląda w praktyce i jak go czytać?
Po wejściu w raport widzimy dwa główne panele ułożone jeden pod drugim: pierwszy dedykowany urządzeniom mobilnym, drugi – komputerom. Każdy z nich prezentuje liczbę adresów URL podzielonych na trzy stany: Dobrej jakości (zielony), Wymagająca poprawy (pomarańczowy) i Słabej jakości (czerwony). Dane obejmują okno ostatnich 28 dni i pochodzą wyłącznie z rzeczywistych sesji użytkowników, którzy odwiedzili witrynę przez Chrome i zgodzili się na udostępnianie statystyk. Żaden symulator, żadne syntetyczne testy – pure field data.
Co istotne i często mylące – raport nie pokazuje pojedynczych stron, lecz grupy adresów URL. Google klastruje je automatycznie, opierając się na strukturze adresów i podobieństwie ścieżek URL (łącząc np. adresy w obrębie tego samego katalogu produktów). Dlatego w sekcji „Raport” zwykle zobaczymy kilka reprezentatywnych adresów, a nie pełną listę URL-i z problemami. To zabieg celowy: raport ma diagnozować problemy systemowe – te wynikające z architektury strony czy globalnego sposobu ładowania zasobów – a nie anomalie pojedynczych podstron.
Klikając „Otwórz raport” przy konkretnej platformie, przechodzimy do widoku szczegółowego. Pojawia się tam tabela z listą problemów oraz liczbą dotkniętych grup URL-i. Najczęściej trafimy na zapisy typu LCP przekraczające 2,5 s (strefa pomarańczowa) lub 4 s (czerwona), INP powyżej 200 ms (lub 500 ms w stanie krytycznym) oraz CLS większy niż 0,1 (granica dobrego wyniku). Progi te odnoszą się do 75. percentyla pomiarów. W praktyce oznacza to, że co najmniej 75% wizyt na danej grupie stron musi spełniać kryterium dobrego wyniku, aby algorytm podświetlił ją na zielono. Dzięki temu ocena uwzględnia także starsze urządzenia, wolniejsze sieci i mniej korzystne warunki.
Tu warto zatrzymać się na zasadzie, którą Google opisuje w dokumentacji, a o której łatwo zapomnieć: status grupy URL-i przyjmuje wartość najgorszej z metryk. Jeśli LCP jest dobre, INP w normie, ale CLS przekracza dopuszczalny próg, cała grupa może trafić do strefy „Słabej jakości”. To z jednej strony surowe (jedno potknięcie i mamy czerwony pasek), z drugiej – pragmatyczne, bo realnemu użytkownikowi również wystarczy jeden uciążliwy element, by uznać stronę za kiepską.
Pod listą problemów znajduje się oś czasu z liczbą dotkniętych URL-i w ciągu ostatnich 90 dni. To miejsce, w które warto zaglądać po każdym większym wdrożeniu – wzrost zielonego paska po zmianach na produkcji jest jedną z najbardziej satysfakcjonujących rzeczy, jakie GSC potrafi pokazać.
Po kliknięciu w konkretny problem dostajemy próbkę URL-i z danej grupy, link „Sprawdź adres URL” prowadzący do PageSpeed Insights oraz przycisk Sprawdź poprawkę (Validate fix). Tę opcję trzeba kliknąć po wdrożeniu zmian na produkcji – system natychmiast zmieni status zadania na „W toku” i rozpocznie ponowną walidację.
Cały proces trwa zazwyczaj do 28 dni, ponieważ tyle wynosi ruchome okno zbierania danych w bazie CrUX. Jeżeli jednak serwis generuje duży ruch, a poprawka diametralnie zmieniła zachowanie strony na plus, Google może potwierdzić sukces i zmienić status na zielony nieco wcześniej (np. po 2-3 tygodniach), gdy tylko zbierze wymaganą gęstość nowych danych.
Do czego wykorzystać dane o szybkości ładowania strony z GSC?
Najbardziej oczywiste zastosowanie to priorytetyzacja prac optymalizacyjnych. Zamiast brnąć przez listę wszystkich możliwych usprawnień (a tych w PageSpeed Insights potrafi być kilkadziesiąt na jednej podstronie), zaczynamy od grup URL-i, które realnie generują ruch z wyszukiwarki. Jeśli karty produktów obsługują 70% sesji organicznych, a kategorii jest sześć razy mniej, kierunek pierwszych prac jest dość oczywisty.
Kompleksowy audyt SEO
Zbadaj jakość swojej witryny
Druga, równie istotna kwestia: monitoring zmian po wdrożeniach. Przy większych projektach – zmianie szablonu, migracji do nowego frameworka, podmianie hostingu – raport CWV w GSC działa jak czujnik dymu. Jeżeli po deployu pomarańczowy lub czerwony pasek zaczyna rosnąć, mamy sygnał, że zmiana wprowadziła regresję na produkcji w danych od realnych użytkowników, a nie tylko w testach laboratoryjnych. Z doświadczenia wiem, że ten sygnał wyprzedza zwykle skargi z analityki o dobrych kilka dni – użytkownicy znacznie rzadziej zgłaszają problemy, niż wskaźniki CrUX zaczynają je pokazywać.
Trzecie zastosowanie, o którym mówi się stosunkowo rzadko, to diagnostyka różnic mobile vs desktop. Jeśli wersja desktopowa jest w zieleni, a mobile świeci czerwienią, mamy konkretny trop: problem najprawdopodobniej leży w renderze mobilnym – zbyt duże obrazki bez odpowiednich srcset, niezoptymalizowany JS na słabszych procesorach, blokujące skrypty third-party, które na desktopie giną w szumie wydajnego sprzętu. Często okazuje się, że strona, która „u mnie działa szybko”, jest udręką dla użytkownika z budżetowym Androidem na LTE – a to dziś mediana ruchu w wielu branżach.
Kilka słów o danych
Warto rozróżnić dwa źródła danych. Search Console umożliwia zbiorczy eksport danych skuteczności do BigQuery, co pomaga analizować ruch organiczny według stron, krajów, urządzeń czy zapytań. Same dane Core Web Vitals pochodzą natomiast z Chrome UX Report. Publiczny dataset CrUX w BigQuery pozwala analizować dane zagregowane m.in. według originu, kraju, daty i typu urządzenia, ale nie zastępuje raportu GSC na poziomie grup adresów URL ani nie daje prostego rozbicia CWV według szablonów strony.
Dzięki tak dużej dawce informacji możemy dokładnie przeanalizować podane adresy i odnaleźć przyczyny problemów – z wykorzystaniem PageSpeed Insights. Oprócz dokładnej analizy problemów, mamy możliwość monitorowania przebiegu ich eliminacji.
Podsumowanie
Raport prędkości w Google Search Console – mimo że formalnie figuruje jako Core Web Vitals – pozostaje jednym z najważniejszych źródeł twardych danych o wydajności strony z perspektywy realnych użytkowników. Pokazuje to, co Google faktycznie mierzy i bierze pod uwagę przy ocenie page experience, a przy okazji nie wymaga dodatkowej konfiguracji ani integracji.
Najważniejsze, co warto z niego wynieść: dane są terenowe, nie laboratoryjne; dotyczą grup URL-i, a nie pojedynczych stron; ocena całości schodzi do poziomu najsłabszej z trzech metryk. Stąd droga do zielonego paska prowadzi przez konsekwentną pracę nad LCP, INP i CLS jednocześnie – nie wystarczy załatwić jednej z nich i odhaczyć temat. W praktyce większość problemów daje się rozwiązać w obrębie kilku sprintów developerskich, jeśli kolejność prac wyznacza właśnie raport w GSC, a nie subiektywne odczucia z testów na firmowym MacBooku Pro.
FAQ
Spodobał Ci się ten artykuł?
Zapisz się na newsletter - nie spamujemy!
Loading...
![[CASE STUDY] Jak wystartować ze sprzedażą na Allegro i osiągnąć sukces w 2 miesiące?](https://www.devagroup.pl/blog/wp-content/uploads/2026/06/cs-oromatcha-150x150.jpg)
