Core Web Vitals — dlaczego wynik w PageSpeed mierzy co innego

Większość usług sprzedawanych pod hasłem optymalizacja strony internetowej sprowadza się do jednego celu: zielonego wyniku powyżej 90 punktów w popularnych narzędziach audytowych. Właściciele firm gonią za idealną oceną, wierząc, że przełoży się ona na pozycje w wyszukiwarce. Tymczasem z perspektywy Google szybkość ładowania strony nie jest pojedynczą liczbą od 0 do 100. Wynik, który widzicie w większości testerów, to wyłącznie ocena laboratoryjna. Żeby zrozumieć, co faktycznie wpływa na widoczność serwisu, trzeba oddzielić symulację od twardych metryk używanych przez algorytm — czyli od wskaźników Core Web Vitals.

Wynik Lighthouse kontra Core Web Vitals

Kiedy uruchamiacie test szybkości strony w przeglądarce, pod maską działa silnik Lighthouse. Warto przyjrzeć się, z czego składa się jego ostateczna ocena. W wersji Lighthouse 13, która nie wprowadziła zmian w modelu oceniania, wagi rozkładają się według oficjalnej dokumentacji tak:

• First Contentful Paint (FCP): 10%
• Speed Index: 10%
• Largest Contentful Paint (LCP): 25%
• Total Blocking Time (TBT): 30%
• Cumulative Layout Shift (CLS): 25%

Największą wagę w wyniku laboratoryjnym — aż 30% — ma TBT. Problem polega na tym, że TBT nie jest metryką Core Web Vitals i algorytm rankingowy z niego nie korzysta. Z kolei Interaction to Next Paint, które jest pełnoprawną metryką rankingową, w ogóle nie występuje w wyniku Lighthouse.

Powód tej nieobecności jest prozaiczny i wart zapamiętania, bo tłumaczy całą resztę artykułu: w laboratorium nikt nie klika. Lighthouse wczytuje stronę i mierzy, co się dzieje samo z siebie. INP mierzy reakcję na działanie użytkownika, a skoro użytkownika nie ma, nie ma czego zmierzyć. TBT jest laboratoryjnym przybliżeniem tego samego problemu — sprawdza, jak długo główny wątek przeglądarki był zajęty i nie mógłby odpowiedzieć, gdyby ktoś kliknął.

Dwie pozostałe pozycje z tej listy warto znać z nazwy, bo pojawiają się w każdym raporcie. First Contentful Paint to moment, w którym na ekranie pojawia się cokolwiek — pierwszy tekst albo pierwsza grafika. Speed Index opisuje, jak szybko wypełnia się widoczny obszar strony. Obie są sensownymi miarami wrażenia „coś się dzieje", obie są laboratoryjne i żadna nie jest Core Web Vital.

Skutek praktyczny: kto inwestuje w dobicie do 90 punktów, optymalizuje pod wskaźnik wykluczony z rankingu i nie mierzy tego, który w nim jest. To nie znaczy, że wynik Lighthouse jest bezużyteczny — jest dobrym narzędziem diagnostycznym i za chwilę pokażemy, kiedy bywa jedynym, jakie macie. Znaczy tylko tyle, że nie jest ocenianiem, którego dokonuje wyszukiwarka.

Trzy metryki i trzy progi

Wyszukiwarka nie ocenia serwisu średnią ważoną z laboratorium, lecz mierzy prędkość strony internetowej przez pryzmat konkretnych doświadczeń użytkownika. Zgodnie z wytycznymi web.dev strona spełnia standard Core Web Vitals, gdy mieści się w trzech progach:

• Largest Contentful Paint (LCP): ≤ 2,5 s — czas renderowania największego bloku tekstowego lub graficznego widocznego bez przewijania.
• Interaction to Next Paint (INP): ≤ 200 ms — wskaźnik, który w marcu 2024 zastąpił FID. Przeglądarka obserwuje wszystkie interakcje podczas wizyty i raportuje jedną wartość, bliską najgorszej z nich — nie sumę i nie średnią. Na stronach z wieloma interakcjami pojedyncze skrajne przypadki są odrzucane, żeby jedno przypadkowe zacięcie nie przesądzało o ocenie.
• Cumulative Layout Shift (CLS): ≤ 0,1 — stabilność wizualna. Wyłapuje nieoczekiwane przesunięcia układu, na przykład gdy tekst „ucieka" spod palca, bo doładował się baner.

Progi nie dotyczą pojedynczego testu. Żeby zdać, strona musi utrzymywać te wyniki na 75. percentylu wizyt — czyli co najmniej 75 na 100 realnych odwiedzin musi mieścić się pod progiem. I jedno doprecyzowanie, o które łatwo się potknąć: percentyl liczony jest osobno dla urządzeń mobilnych i osobno dla komputerów. Strona potrafi zdawać na desktopie i oblewać na telefonach, i to jest typowa sytuacja, a nie wyjątek.

Laboratorium kontra teren

Rozziew między wysoką oceną po wdrożeniu wtyczki przyspieszającej a brakiem realnych efektów bierze się ze sposobu pozyskiwania danych. Lighthouse to środowisko laboratoryjne. Symuluje jedno wczytanie z jednego serwera testowego, nakładając z góry określone ograniczenia przepustowości — dzięki temu wyniki są powtarzalne, ale oderwane od rzeczywistości.

Google do oceny wykorzystuje Chrome User Experience Report (CrUX) — zestawienie anonimowych danych od prawdziwych użytkowników Chrome. CrUX uwzględnia surowe warunki: telefony sprzed pięciu lat, chwilowe utraty zasięgu w komunikacji miejskiej, zatłoczone sieci Wi-Fi, wolne łącza. W terenie nie liczy się to, jak strona ładuje się u programisty na światłowodzie, tylko jak zachowuje się u Waszych klientów.

Warto też wiedzieć, jak te dane są liczone, bo to przesądza o harmonogramie każdej poprawki. Według dokumentacji CrUX API CrUX podaje 28-dniową średnią kroczącą, aktualizowaną codziennie około 4:00 UTC, przy czym zbiór jest około dwóch dni za bieżącą datą, bo czeka na komplet danych i na ich przetworzenie.

Praktyczny skutek jest taki, że poprawka wdrożona w poniedziałek nie pojawi się w raporcie we wtorek, a kiedy zacznie się pojawiać, będzie rozcieńczona trzema tygodniami starych pomiarów. Pełny obraz po zmianie widać dopiero po około czterech tygodniach. Kto ocenia skuteczność wdrożenia po trzech dniach, ocenia głównie szum. Licząc te dwa dni opóźnienia i zakładając równy ruch każdego dnia: tydzień po wdrożeniu wizyty po poprawce stanowią 18% danych w raporcie, połowę — po 16 dniach, a całość — dopiero po 30.

Stąd praktyczny wniosek do rozmów z wykonawcą: zrzut ekranu z zielonym wynikiem nie jest dowodem, że coś się poprawiło. Jest dowodem, że w jednym symulowanym wczytaniu strona zachowała się dobrze. Dowodem są dane terenowe, zebrane po wdrożeniu przez kilka tygodni — o ile w ogóle je macie.

Dlaczego Wasza strona może nie mieć danych terenowych

To jest część, której brakuje w większości polskich poradników, a która dla mniejszej firmy jest najważniejsza.

Żeby adres trafił do CrUX, musi spełnić dwa warunki: być publicznie dostępny i dostatecznie popularny. Dokumentacja Chrome formułuje drugi warunek wprost: strona jest dostatecznie popularna, jeśli ma minimalną liczbę odwiedzających, przy czym „dokładna liczba nie jest ujawniana" — została dobrana tak, żeby próbka miała sens statystyczny. Adresy i domeny, które progu nie przekraczają, nie znajdują się w zbiorze CrUX.

Nie ma tu półśrodków. Nie dostajecie gorszych danych ani danych z zastrzeżeniem — nie dostajecie żadnych. Strona firmowa z kilkuset wizytami miesięcznie zwykle w CrUX nie istnieje, a otwarcie PageSpeed Insights dla takiego adresu pokaże wyłącznie sekcję laboratoryjną, bez sekcji z danymi rzeczywistymi.

Co z tego wynika praktycznie:

• Nie da się sprawdzić, czy Wasza strona „zdaje" Core Web Vitals, jeśli nie ma danych terenowych. Można tylko szacować na podstawie laboratorium.
• Wynik laboratoryjny staje się wtedy jedynym narzędziem, jakie macie — i wtedy warto go używać, pamiętając, czym jest. To argument za Lighthouse, nie przeciw niemu.
• Własny pomiar u realnych użytkowników jest możliwy i nie wymaga zgody Google: dane Core Web Vitals można zbierać z przeglądarek własnych odwiedzających. To standardowa funkcja, którą wykonawca włącza raz. Nie należy jej mylić z monitoringiem dostępności: tamten mówi, czy coś właśnie się zepsuło, ten — jak strona wypada dla użytkowników w ostatnich tygodniach; różnicę opisujemy przy monitoringu strony.
• Nie wyciągajcie wniosków z braku danych. Brak sekcji terenowej w PageSpeed nie znaczy, że strona jest wolna ani że Google ją karze. Znaczy, że ruch jest za mały, żeby Google miał co uśrednić.

Gdzie naprawdę idzie czas w LCP

Załóżmy, że LCP wychodzi za długie. Pytanie brzmi: za co zapłacić, żeby je skrócić. Dokumentacja web.dev rozbija ten czas na cztery fazy i podaje, jaki udział powinna mieć każda z nich.

• Time to First Byte — około 40%. Czas od kliknięcia w link do pierwszego bajtu odpowiedzi. To serwer: gdzie stoi, jak jest obciążony, czy odpowiedź jest buforowana.
• Opóźnienie startu zasobu — poniżej 10%. Od pierwszego bajtu do chwili, gdy przeglądarka zaczyna pobierać największy element.
• Pobieranie zasobu — około 40%. Samo ładowanie tego elementu. Przy stronie firmowej to prawie zawsze zdjęcie.
• Opóźnienie wyrenderowania — poniżej 10%. Od pobrania elementu do jego pojawienia się na ekranie.

Osiemdziesiąt procent budżetu to serwer i jeden obrazek. To dwie decyzje, z których żadna nie jest decyzją programistyczną: pierwsza jest zakupowa (gdzie kupujecie hosting i ile on kosztuje), druga redakcyjna (jakie zdjęcie wrzucacie na górę strony i w jakim rozmiarze). Wtyczka z napisem „optymalizacja" nie dotyka ani jednej, ani drugiej.

Żeby wiedzieć, o którym elemencie mowa, nie trzeba zgadywać. Narzędzia audytowe wskazują go wprost — w raporcie pojawia się pozycja z nazwą elementu uznanego za największy. W praktyce przy stronie firmowej jest to zdjęcie w nagłówku, rzadziej blok tekstu z dużym nagłówkiem. I tu bywa pierwsza niespodzianka: elementem LCP okazuje się często coś, czego nikt nie planował — tło sekcji powitalnej albo grafika, która na telefonie zajmuje pół ekranu, choć na komputerze jest ozdobnikiem z boku.

Dwie fazy „opóźnieniowe" mają być resztą. Jeśli któraś urosła, to sygnał diagnostyczny, a nie powód do zakupu mocniejszego serwera — coś blokuje start pobierania albo renderowanie. Wtedy sensownie jest sięgnąć po Lighthouse, bo to dokładnie ten typ problemu, który laboratorium pokazuje dobrze.

O tym, co przy wyborze serwera realnie wpływa na TTFB, piszemy osobno w tekście o hostingu i domenach.

INP: trzy fazy i dlaczego to nie jest FID

INP jest najmłodszą z trzech metryk i najczęściej mylnie opisywaną — zwykle jako „następca FID", co sugeruje drobną zmianę nazwy. To nie jest drobna zmiana.

FID mierzył opóźnienie pierwszej interakcji: ile czasu minęło, zanim przeglądarka zaczęła obsługiwać pierwsze kliknięcie. Nie mierzył, ile trwała sama obsługa ani kiedy użytkownik zobaczył efekt. Strona mogła więc zdawać FID i jednocześnie reagować fatalnie — wystarczyło, że pierwsze kliknięcie było szybkie, a wszystkie następne mielone po sekundzie.

INP mierzy całą drogę, w trzech fazach:

• Opóźnienie wejścia — od kliknięcia do rozpoczęcia obsługi. To, co mierzył FID.
• Czas obsługi — jak długo wykonuje się kod odpowiadający za reakcję.
• Opóźnienie prezentacji — od zakończenia kodu do chwili, gdy zmiana jest widoczna na ekranie.

Dopiero suma tych trzech odcinków opisuje to, co użytkownik nazywa „strona się zacięła". Dla właściciela strony wniosek jest konkretny: INP psuje się od tego, co dokładacie — od skryptów śledzących, czatów, wtyczek, które przy każdym kliknięciu wykonują swoją porcję kodu. Rzadko psuje się od samego szablonu.

Dlatego INP i liczba zainstalowanych dodatków to w praktyce ta sama rozmowa co aktualizacje i to, co zostało do strony dołożone.

CLS — najtańsza do naprawienia

CLS jest jedyną z trzech metryk, którą zwykle da się naprawić bez wydawania pieniędzy na infrastrukturę, bo jej przyczyny są policzalne i powtarzalne:

• Obrazy bez podanych wymiarów. Przeglądarka nie wie, ile miejsca zarezerwować, więc rezerwuje zero i przesuwa wszystko, gdy zdjęcie dojdzie.
• Treści wstawiane nad istniejącymi — banery zgód, paski promocyjne, komunikaty doładowywane po starcie strony.
• Czcionki wymieniane po wczytaniu. Tekst pokazuje się w foncie zastępczym, a po chwili podmienia na docelowy o innej szerokości i cały akapit skacze.

Sam próg bywa mylący, bo 0,1 nie jest jednostką czasu ani odległości. To iloczyn dwóch ułamków: jaką część ekranu zajmuje przesuwający się element łącznie w starym i nowym położeniu oraz o jaki dystans się przesunął, liczony względem dłuższego boku ekranu. Liczy się najgorsza seria przesunięć — takich, które następują w odstępach poniżej sekundy, w oknie do 5 sekund — a nie suma z całej wizyty. Na przykładzie z dokumentacji Google: element zajmujący połowę ekranu telefonu zjeżdża o jedną czwartą jego wysokości, więc razem ze starym położeniem pokrywa 75% ekranu, a wynik tego jednego przesunięcia to 0,75 × 0,25 ≈ 0,19 — prawie dwa razy więcej niż cały próg (web.dev, „Cumulative Layout Shift (CLS)”). Do zapamiętania: na telefonie wystarczy, że połowa ekranu zjedzie o jedną piątą wysokości (0,7 × 0,2 = 0,14), żeby przekroczyć 0,1 jednym ruchem. Jeden baner zgód wjeżdżający nad treścią potrafi to zrobić w całości.

Każda z tych trzech rzeczy ma standardowe rozwiązanie po stronie wykonawcy i jest to praca na godziny, nie na tygodnie. Jeśli prace zleca się w ramach stałej obsługi strony, warto zapisać je jako osobne zadanie z pomiarem przed i po, a nie jako część „bieżących poprawek”. Jeśli macie ograniczony budżet na wydajność, CLS jest miejscem, gdzie stosunek efektu do kosztu jest najlepszy — a przy okazji to metryka, którą użytkownicy odczuwają najdotkliwiej, bo objawia się kliknięciem w niewłaściwy przycisk.

Co dobry wynik kupuje, a czego nie

Tu trzeba powiedzieć rzecz, której nie mówi branża sprzedająca optymalizację. Google formułuje to w dokumentacji dla webmasterów zaskakująco ostrożnie.

Po pierwsze: „There is no single signal" — nie istnieje jeden wskaźnik „page experience", który algorytm podstawia do wzoru. Systemy rankingowe patrzą na wiele sygnałów, a Core Web Vitals są jednym z nich.

Po drugie, i ważniejsze: „Google Search always seeks to show the most relevant content, even if the page experience is sub-par". Trafność wygrywa. Strona wolna, ale odpowiadająca na pytanie, wyprzedzi stronę szybką i pustą. Dopiero gdy wartościowych odpowiedzi jest wiele — a dla większości zapytań komercyjnych jest — dobre doświadczenie zaczyna przeważać.

Po trzecie, wprost: dobre wyniki Core Web Vitals „doesn't guarantee that your pages will rank at the top".

Co z tego wynika dla decyzji o wydatku:

• Wydajność nie zastąpi treści. Jeśli strona nie odpowiada na pytania klientów, przyspieszenie jej sprawi, że szybciej nie odpowie.
• Wydajność rozstrzyga remisy. W konkurencyjnej niszy, gdzie kilkanaście stron mówi to samo, jest jednym z czynników różnicujących.
• Wydajność ma sens poza rankingiem. Strona, która stoi trzy sekundy na białym ekranie, traci część odwiedzających, zanim Google zdąży cokolwiek ocenić. To argument sam w sobie i nie wymaga powoływania się na algorytm.

Kolejność wydawania pieniędzy

Zbierając to, co wyżej, w kolejność, w której warto działać:

1. Sprawdźcie, czy w ogóle macie dane terenowe. Otwórzcie PageSpeed Insights dla swojego adresu. Jest sekcja z danymi rzeczywistymi — pracujecie na faktach. Nie ma — pracujecie na laboratorium i warto włączyć własny pomiar.
2. Zacznijcie od CLS. Najtańszy, najszybszy, najbardziej odczuwalny dla użytkownika.
3. Potem zdjęcia na górze strony. Około 40% budżetu LCP to pobranie największego elementu. Właściwy rozmiar i format bywają warte więcej niż zmiana hostingu.
4. Potem serwer. Jeśli TTFB zjada wyraźnie ponad 40% czasu, to jest rozmowa o tym, gdzie strona stoi — i wtedy zmiana hostingu naprawdę coś daje. Samą przeprowadzkę na nowy serwer, tak żeby niczego nie stracić w wyszukiwarce, rozkładamy przy migracji strony.
5. Na końcu policzcie, co dokładacie. INP psuje się od skryptów. Każdy czat, piksel i wtyczka mają swój koszt, płacony przy każdym kliknięciu użytkownika.
6. Mierzcie po zmianie, nie przed. Dane terenowe potrzebują kilku tygodni, żeby pokazać efekt. Zrzut ekranu z dnia wdrożenia nie jest pomiarem.

Jeśli zastanawiacie się, ile z tego powinno być stałą pozycją w budżecie, a ile jednorazowym wydatkiem — to osobna rozmowa o kosztach utrzymania strony i o tym, co obserwować na bieżąco.

Jak czytać ofertę na optymalizację

Skoro wynik punktowy nie jest tym, co ocenia wyszukiwarka, to zapis „doprowadzimy stronę do 90+ w PageSpeed" jest obietnicą dotyczącą symulacji, a nie stanu strony u Waszych klientów. Nie znaczy to, że oferta jest nieuczciwa — znaczy, że mierzy sukces w jednostce, która nie jest jednostką rankingu.

Poniżej cztery zapisy, które w ofertach pojawiają się najczęściej, i to, o co przy każdym warto dopytać.

Dobra oferta na wydajność ma trzy cechy. Zaczyna się od pomiaru wyjściowego, a nie od listy prac — bez tego nie da się później wykazać efektu. Nazywa metrykę, na którą celuje, zamiast mówić o „przyspieszeniu strony". I rozdziela to, co zmieni się od razu, od tego, co zobaczycie dopiero w danych terenowych po kilku tygodniach.

Jeśli Wasza strona nie ma danych terenowych, powiedzcie to wykonawcy na starcie. Uczciwa reakcja to propozycja włączenia własnego pomiaru przed rozpoczęciem prac — nie zapewnienie, że „i tak będzie szybciej".