Core Web Vitals w 2026: co naprawdę mierzy Google

Trzy wskaźniki i ich progi

Dla każdego wskaźnika Google wyznacza trzy przedziały: dobry, do poprawy i słaby. Progi pochodzą z dokumentacji web.dev, prowadzonej przez zespół Chrome:

INP zastąpił FID (First Input Delay) 12 marca 2024 r. FID mierzył tylko opóźnienie pierwszej interakcji. INP bierze pod uwagę wszystkie kliknięcia, dotknięcia i naciśnięcia klawiszy podczas wizyty (przewijania i najeżdżania kursorem nie liczy). Jeśli audyt, wtyczka albo poradnik wciąż pisze o FID, jest nieaktualny.

Skąd Google bierze dane

W wyszukiwarce liczą się dane z prawdziwych wizyt, zbierane w raporcie CrUX (Chrome User Experience Report). Trafiają tam pomiary od użytkowników Chrome na komputerach i Androidzie, którzy mają włączone wysyłanie statystyk użytkowania i synchronizację historii. Chrome na iPhonie, inne przeglądarki i aplikacje z wbudowaną przeglądarką Androida danych nie dostarczają.

• 75. percentyl: wynik strony to wartość, którą osiągnęło albo poprawiło 75% wizyt. Google wybrał ten percentyl, bo pokazuje doświadczenie większości odwiedzających i nie zależy od pojedynczych skrajnych wizyt.
• Ostatnie 28 dni: Search Console i PageSpeed Insights pokazują dane z ostatnich 28 dni, więc efekt poprawki widać w raporcie dopiero po kilku tygodniach.
• Grupy adresów: Search Console łączy podobne podstrony w grupy, a status grupy wyznacza najsłabszy z trzech wskaźników.
• Za mały ruch to brak danych: do CrUX trafiają tylko strony publiczne i wystarczająco popularne, a Google nie ujawnia progu. Gdy podstrona ma za mało wizyt, PageSpeed Insights pokazuje dane dla całej domeny, a gdy i tego brakuje, nie pokazuje danych z ruchu wcale.

Laboratorium a prawdziwy ruch: skąd bierze się 100/100

PageSpeed Insights pokazuje dwa rodzaje wyników. Pierwszy to dane z prawdziwego ruchu (CrUX), o ile Google je ma. Drugi to test Lighthouse: jedno ładowanie strony w kontrolowanych warunkach, na emulowanym telefonie średniej klasy (Lighthouse 13 udaje Moto G Power z 2022 r.) w spowolnionej sieci komórkowej. Z tego testu powstaje wynik 0–100.

• Wynik 0–100 to średnia ważona pięciu pomiarów z laboratorium. W Lighthouse 13 największą wagę ma Total Blocking Time (30%), potem LCP i CLS (po 25%), a First Contentful Paint i Speed Index po 10%. Zielony kolor zaczyna się od 90 punktów.
• Test laboratoryjny nie mierzy INP. Podczas zwykłego ładowania nikt nie klika, więc INP ma w wyniku wagę zero. Jego laboratoryjnym przybliżeniem jest TBT, czyli czas, w którym przeglądarka była zbyt zajęta, żeby reagować. Dokumentacja web.dev zaznacza, że TBT jest rozsądnym przybliżeniem INP w laboratorium, ale sam w sobie INP nie zastępuje.
• Wynik potrafi się wahać. Według dokumentacji Lighthouse duża część zmienności nie wynika z samego narzędzia, tylko z warunków: testów A/B i reklam, zmian w trasowaniu ruchu w internecie, różnych urządzeń, rozszerzeń przeglądarki czy antywirusa.

Dlatego zielony wynik w PageSpeed Insights i czerwony raport w Search Console mogą być prawdziwe jednocześnie. Test laboratoryjny sprawdza jedno ładowanie na wzorcowym sprzęcie, a CrUX zbiera wizyty z telefonów Twoich klientów, także starszych i przy słabym zasięgu.

Przykład z tej strony: Lighthouse 13.5.0 (13.10.2026, 3 przebiegi) dał stronie głównej 100 punktów we wszystkich czterech kategoriach na emulowanym telefonie, z LCP 1,3 s i CLS 0, a na komputerze 100 punktów we wszystkich czterech kategoriach. To mówi, że kod i serwer są szybkie. Nie mówi jeszcze, jak strona działa u odwiedzających. To pokażą dopiero dane z prawdziwego ruchu, gdy Google zbierze ich wystarczająco dużo.

Ile szybkość znaczy dla pozycji w Google

Google odpowiada na to w dokumentacji wyszukiwarki trzema zdaniami, które warto znać:

• „Core Web Vitals są używane przez nasze systemy rankingowe”.
• „Dobre wyniki w raportach, takich jak raport Core Web Vitals w Search Console, czy w narzędziach innych firm nie gwarantują, że Twoje strony będą na szczycie wyników wyszukiwania Google”.
• „Wyszukiwarka Google zawsze stara się pokazać najbardziej trafne treści, nawet jeśli strona jest mniej wygodna w użyciu”.

Nie istnieje też jeden „wynik page experience”. Google pisze, że nie ma pojedynczego sygnału: systemy rankingowe biorą pod uwagę wiele sygnałów zgodnych z ogólnym doświadczeniem użytkownika. Google dodaje, że przy wielu zapytaniach pomocnych treści jest dużo i wtedy dobre doświadczenie użytkownika może pomóc w wynikach. Mój praktyczny wniosek: szybkość pomaga wygrać z równie dobrą treścią konkurencji, ale nie wyprzedzi treści lepszej.

• Mit: wynik 100/100 w PageSpeed Insights podnosi pozycję. Core Web Vitals to według Google wskaźniki rzeczywistego doświadczenia użytkowników. Wynik 0–100 pochodzi z jednego testu laboratoryjnego i nie jest jednym z nich.
• Mit: Google liczy jeden łączny wynik Core Web Vitals. Takiego wyniku nie ma. Każdy wskaźnik ma osobny próg, a strona jest dobra, gdy przejdzie wszystkie trzy.
• Mit: FID nadal się liczy. Od 12 marca 2024 r. jego miejsce zajął INP.
• Mit: wystarczy poprawić stronę główną. Search Console ocenia grupy podobnych podstron osobno, więc wolny szablon wpisu na blogu albo karty produktu ma własny status.

Jak sprawdzić i poprawić swoją stronę

1. 01

   Search Console

   Otwórz raport Core Web Vitals i zacznij od telefonów. Jeśli są dane, zobaczysz grupy adresów z problemem i wskaźnik, który go powoduje.

2. 02

   PageSpeed Insights

   Wpisz adres podstrony. Najpierw sprawdź, czy są dane z prawdziwego ruchu dla tej podstrony albo całej domeny. Dopiero potem czytaj diagnostykę z testu laboratoryjnego.

3. 03

   Prawdziwy telefon

   Otwórz stronę na starszym, niedrogim telefonie przy internecie komórkowym. Tak najszybciej zobaczysz to, co widzą Twoi klienci.

4. 04

   Poprawki

   Zacznij od wskaźnika, który jest najdalej od progu. Najczęstsze przyczyny według dokumentacji Google są niżej.

• LCP: główny obraz albo tekst musi być widoczny w samym HTML, a nie dociągany skryptem. Nie ładuj go leniwie (lazy loading), oznacz go fetchpriority="high", usuń blokujące style i skrypty z nagłówka strony, skróć czas odpowiedzi serwera i ogranicz przekierowania.
• CLS: podawaj wymiary (width i height) każdego obrazu i filmu, rezerwuj miejsce na reklamy, osadzenia i banery, nie wstawiaj nowych treści nad tym, co już widać, ładuj fonty tak, żeby ich podmiana nie przesuwała tekstu (np. font-display: optional), a ruch animuj przez transform zamiast top czy left.
• INP: dziel długie zadania JavaScriptu na krótsze i oddawaj przeglądarce sterowanie między nimi, nie przebudowuj dużych fragmentów strony przy każdym kliknięciu i trzymaj rozmiar DOM w ryzach.

Jak to wygląda na tej stronie

Tę stronę budowałem z myślą o tych trzech wskaźnikach. Konkretnie:

• Każda podstrona jest gotowym plikiem HTML wygenerowanym przy budowaniu, więc treść widać, zanim uruchomi się JavaScript.
• Style są wpisane w HTML, bez osobnego pliku, który blokowałby pierwsze wyświetlenie.
• Font jest jeden, przycięty do używanych znaków, ładowany z wyprzedzeniem i z font-display: optional, więc jego podmiana nie przesuwa tekstu.
• JavaScript aplikacji ładuje się dopiero po pierwszym wyświetleniu treści.
• Animacje nie zmieniają właściwości układu, takich jak top czy width, więc nie przesuwają treści.

Ten sam pomiar w Lighthouse robię przed oddaniem każdej strony. Jeśli chcesz, żeby Twoja strona powstała w ten sposób, zobacz tworzenie stron i cennik, a o kosztach piszę w poradniku ile kosztuje strona internetowa.

Przygotowane z pomocą narzędzi AI, sprawdzone i uzupełnione przez autora. Liczby i przepisy mają podane źródła.