Core Web Vitals: za mało danych w Search Console

Search Console wyświetla komunikat „Za mało danych o użytkowaniu”, gdy Google ma za mało wizyt z Chrome na twoich stronach. Możesz mierzyć rzeczywistych odwiedzających bez czekania na Google.

Bezpłatny okres próbny

Trusted by market leaders · Client results

saturnebayhappyhorizonkpnadevintaerasmusmcsnvnina careharvarddpg mediafotocasaworkivawhowhatwearnestlemonarchvpnmy work featured on web.devcompareperionmarktplaatsloopearplugsaleteia

Co oznacza „Za mało danych o użytkowaniu”

Raport Core Web Vitals w Search Console pokazuje, jak twoje strony działały u rzeczywistych użytkowników Chrome. Za każdym razem, gdy ktoś w Chrome z odpowiednimi ustawieniami otwiera twoją stronę, wyniki LCP, INP i CLS z tej wizyty trafiają do Google. Lądują w publicznym zbiorze danych o nazwie Chrome User Experience Report, w skrócie CrUX. Search Console czyta dane z tego zbioru i pokazuje je tobie. Wbrew powszechnemu przekonaniu Search Console wcale nie wchodzi na stronę, żeby ją zmierzyć – zbiera po prostu dane rzeczywistych użytkowników.

Gdy takich wizyt na twoich stronach jest za mało, nie ma czego pokazać. Wtedy pojawia się komunikat „Za mało danych o użytkowaniu w ciągu ostatnich 90 dni dla tego typu urządzeń” dla urządzeń mobilnych, komputerów lub obu naraz.

Search Console Core Web Vitals report for desktop: Not enough usage data in the last 90 days for this device type

Niektórzy uważają to za zły znak, ale brak danych nie mówi nic o tym, czy strona jest szybka, czy wolna. Google po prostu nie zarejestrował wystarczającej liczby odwiedzających, by móc to ocenić.

Dlaczego CrUX nie ma danych o twojej stronie

Główny powód to ruch. CrUX raportuje stronę lub origin (protokół plus domenę, czyli https://www.example.com) tylko wtedy, gdy jest „wystarczająco popularna”. Co to dokładnie oznacza – Google nie mówi. Strona z opisem metodologii podaje tylko, że próg jest na tyle wysoki, by mieć pewność co do rozkładu danych.

Na dodatek do tego progu wlicza się tylko niewielka część odwiedzających. CrUX zbiera dane wyłącznie od użytkowników Chrome, którzy włączyli przesyłanie statystyk użytkowania, synchronizują historię przeglądania i nie ustawili hasła synchronizacji. Chodzi o Chrome na komputerach i Chrome na Androidzie. Chrome na iPhonie się nie liczy (pod spodem działa WebKit, tak samo jak w Safari). Samo Safari, Firefox, Edge czy przeglądarka w aplikacji Instagrama też nie trafiają do zestawienia. Na stronie z dużym ruchem z iPhone'ów większość odwiedzających nigdy nie trafi do tego zbioru. Urządzenia mobilne i komputery liczy się osobno, więc możesz mieć dane dla komputerów i brak danych na urządzeniach mobilnych – albo na odwrót. Typ urządzeń z mniejszym ruchem z Chrome pierwszy zostanie bez danych.

100 visitors by browser share: 69 use Chrome and only count in CrUX if they opted in, 31 use Safari, Edge, Firefox, Samsung Internet, Opera or other browsers that CrUX never counts. Source: StatCounter, August 2026

Druga sprawa: sama strona też musi spełnić określone warunki. Wszystko, co po przekierowaniach zwraca status inny niż 200, jest pomijane. Strony z tagiem meta noindex lub nagłówkiem X-Robots-Tag: noindex również odpadają. Search Console dodaje do tego własną regułę: w raporcie pojawiają się tylko te adresy URL, które są rzeczywiście zaindeksowane.

A jeśli usługa dopiero co trafiła do Search Console, przez pewien czas i tak niczego tam nie zobaczysz. To akurat rozwiąże się samo, gdy Google przetworzy dane.

Strony bez danych przejmują wynik originu

Search Console nie raportuje też pojedynczych stron – grupuje podobne do siebie adresy URL. Gdy danej grupie brakuje własnych danych, Search Console robi fallback do originu, czyli wszystkich adresów URL z tym samym protokołem, hostem i portem. Strona, której CrUX nigdy nie widział, może więc pojawić się w raporcie ze statusem „Dobre” lub „Słabe”, bo pożycza wynik od reszty serwisu.

W praktyce strona główna i blog zbierają większość ruchu, więc to one decydują o wyniku originu. Twoje strony produktowe albo checkout mogą działać znacznie wolniej, a w Search Console w ogóle tego nie zobaczysz. Dlatego nigdy nie wyznaczam ogólnego wyniku CrUX dla całej witryny jako celu. Jest ważony ruchem, więc decydują o nim podstrony z największą liczbą wizyt – a to wcale nie muszą być te, na których najbardziej ci zależy.

Lighthouse tutaj nie pomoże

Wszędzie doradza się uruchamianie PageSpeed Insights lub Lighthouse, dopóki nie pojawią się dane w CrUX. Rozumiem, skąd to się bierze, ale w ten sposób nie dostaniesz tego, czego potrzebujesz. Test w Lighthouse wczytuje stronę tylko raz, na symulowanym telefonie, przy dławionym łączu i z pustym cache'em. To dobre do szukania problemów w samej stronie, ale nie mówi nic o tym, z czym stykają się odwiedzający.

Na przykład INP wymaga prawdziwych ludzi, którzy klikają i dotykają ekranu na rzeczywistych urządzeniach – Lighthouse w nic nie klika. Przy CLS Lighthouse przestaje rejestrować cokolwiek po załadowaniu strony. Spóźniona reklama spychająca treść w dół albo element skaczący przy przewijaniu nigdy nie trafią do raportu. Z kolei LCP zależy od telefonu, łącza i odległości odwiedzającego od twojego CDN. Pojedynczy test sprawdza tylko jeden wariant każdego z tych czynników.

Czekanie ma sens tylko wtedy, gdy rośnie ruch. CrUX bierze pod uwagę wizyty z ostatnich 28 dni (swoją drogą to opóźnienie jest znacznie krótsze, niż ludzie myślą – zobacz, dlaczego 28-dniowe opóźnienie to mit). Jeśli w tym miesiącu zabrakło kwalifikujących się wizyt z Chrome, w kolejnym pewnie też ich nie będzie.

Mierz własnych odwiedzających za pomocą RUM

Alternatywą jest samodzielny pomiar. Real user monitoring, czyli RUM, uruchamia niewielki skrypt w przeglądarce każdego odwiedzającego, mierzy Core Web Vitals danej wizyty i wysyła dane do ciebie, a nie do Google. To ten sam typ field data co w CrUX, tyle że bez żadnego progu do osiągnięcia i bez ograniczania się do użytkowników Chrome.

Illustration: Search Console showing not enough usage data for desktop, next to a Core/Dash panel with example LCP, INP and CLS values for desktop

Strona z 50 wizytami w miesiącu ma dane. To samo dotyczy odwiedzających na iPhone'ach. Safari mierzy LCP i INP od wersji Safari 26.2 (grudzień 2025), więc pojawiają się oni w RUM, podczas gdy CrUX nadal ich pomija. Widzisz też, który element spowodował słaby wynik: obraz będący LCP czy przycisk, który wolno reagował. Po deployu widzisz efekt w kilka minut, a nie gdzieś w 28-dniowej średniej.

Core/Dash to narzędzie RUM, które stworzyłem właśnie w tym celu. Jeden tag skryptu albo wtyczka do WordPressa i dane zaczynają spływać już od pierwszej odsłony. Nie zapisuje ciasteczek ani nie zbiera danych osobowych, więc żaden baner ze zgodą nie jest potrzebny. Na małej stronie ma to ogromne znaczenie. Skrypt RUM ukryty za banerem zgód mierzy tylko osoby, które klikną akceptację – i znowu zostajesz z ułamkiem odwiedzających. Ceny zaczynają się od 16 $ miesięcznie przy rozliczeniu rocznym, a 14-dniowy okres próbny nie wymaga karty kredytowej.

Zostaw monitoring włączony nawet wtedy, gdy CrUX zacznie już widzieć twoją stronę. Search Console pokazuje tylko grupy adresów URL – nigdy nie powie ci, która strona lub jaki element spowolniły grupę.

Sprawdź, co CrUX ma teraz o twojej stronie

Zanim cokolwiek zmienisz, sprawdź, czy CrUX w ogóle zarejestrował twój origin. Narzędzie CrUX History tool na corewebvitals.io pokazuje historię CrUX dla dowolnej witryny. Jeśli dla urządzeń mobilnych jest tam pusto, w Search Console też nic nie będzie.

Zobacz również: instalacja Core/Dash, wymiar przeglądarki dla odwiedzających pomijanych przez CrUX oraz wymiar typu urządzenia do rozdzielenia urządzeń mobilnych i komputerów.

Źródła: Pomoc Search Console: raport Core Web Vitals, Metodologia CrUX, Safari 26.2 dodaje obsługę LCP i INP.


Core Web Vitals: za mało danych w Search Console Core Web Vitals Core Web Vitals: za mało danych w Search Console