Szybkość strony - co to jest i jak ją mierzyć (Core Web Vitals)?
Szybkość strony to czas jej wczytywania i reakcji na kliknięcia, mierzony metrykami LCP, INP i CLS w PageSpeed Insights i Search Console.
Jako konsultant SEO, Paweł Wołoszyn, szybkość strony sprawdzam u klientów na dwóch poziomach naraz: co pokazuje Search Console na realnym ruchu i co pokazuje Lighthouse na konkretnym adresie, który akurat naprawiamy. Najczęstszy błąd, jaki widzę, to gonienie za zieloną kropką w jednym narzędziu bez sprawdzenia, czy poprawa w ogóle przekłada się na dane terenowe, bo lokalny test na szybkim laptopie i biurowym internecie nie powie nic o użytkowniku na słabszym telefonie i wolniejszym łączu. Szybkość strony to też nie jest jednorazowy audyt, tylko coś, co trzeba pilnować po każdym większym wdrożeniu: nowy skrypt analityczny, zmiana motywu albo nieprzemyślana reklama potrafią cofnąć wynik LCP czy INP w kilka minut. I nie jest to gwarancja wyższej pozycji sama w sobie, o czym Google mówi wprost, tylko jeden z elementów, który wspiera dobrą treść, a nie ją zastępuje. W praktyce u klientów zaczynam od wskazania, który wskaźnik realnie boli najbardziej i jaka jego przyczyna leży po stronie frontendu, a jaka po stronie hostingu, i pomagam to wdrożyć krok po kroku, zamiast zlecać jednorazową optymalizację i liczyć, że efekt się utrzyma.
Szybkość strony - co to jest i jak ją mierzyć (Core Web Vitals)?
Szybkość strony to czas, w jakim przeglądarka wczytuje i renderuje treść widoczną dla użytkownika, mierzony dziś głównie trzema wskaźnikami Core Web Vitals: LCP, INP i CLS.
Co to jest szybkość strony?
Szybkość strony (ang. page speed, site speed) nie jest jedną liczbą, tylko zbiorem pomiarów opisujących różne momenty wizyty: jak szybko pojawia się główna treść, jak szybko strona reaguje na kliknięcie i czy elementy nie „skaczą” podczas wczytywania. Google formalizuje to podejście w programie Core Web Vitals, zestawie metryk mierzących wydajność ładowania, interaktywność i stabilność wizualną strony. Wcześniej mówiło się po prostu o „czasie ładowania” liczonym w sekundach do zdarzenia onload, czyli pełnego załadowania wszystkich zasobów, ale taka metryka słabo odzwierciedla realne odczucia użytkownika. Strona może wyglądać na gotową na długo przed onload albo, odwrotnie, pozostawać nieresponsywna mimo w pełni załadowanej treści. Dlatego obecny standard patrzy na kilka punktów w cyklu życia strony naraz, a nie na jeden moment startu czy końca.
Jak mierzy się szybkość strony: Core Web Vitals (LCP, INP, CLS)
Web.dev, oficjalny serwis Google poświęcony wydajności stron, definiuje trzy metryki jako rdzeń pomiaru i każdą z nich każe oceniać na poziomie 75. percentyla wizyt, osobno dla urządzeń mobilnych i desktopowych.
LCP, czyli czas do wyrenderowania głównej treści
Largest Contentful Paint mierzy czas wyrenderowania największego widocznego elementu w obszarze ekranu, najczęściej dużego zdjęcia, nagłówka tekstowego albo bloku wideo, licząc od chwili, gdy użytkownik trafia na stronę. Dobry wynik to 2,5 sekundy lub mniej, a wynik powyżej 4 sekund Google klasyfikuje jako słaby.
INP, czyli responsywność na kliknięcia i dotknięcia
Interaction to Next Paint sprawdza opóźnienie między każdą interakcją użytkownika, czyli kliknięciem, dotknięciem ekranu albo wciśnięciem klawisza, a wyrenderowaniem kolejnej klatki w odpowiedzi na tę interakcję, a potem raportuje wartość, poniżej której mieściła się niemal cała sesja. Dobry wynik to 200 milisekund lub mniej. Metryka celowo pomija przewijanie, najechanie kursorem i powiększanie widoku, bo skupia się wyłącznie na realnych interakcjach z elementami strony.
CLS, czyli stabilność układu strony
Cumulative Layout Shift sumuje nieoczekiwane przesunięcia widocznych elementów w trakcie życia strony, grupując je w tzw. okna sesji (przesunięcia bliżej siebie niż sekunda, maksymalnie pięć sekund łącznie) i raportując wynik najgorszego takiego okna. Dobry wynik to 0,1 lub mniej.
| Metryka | Co mierzy | Dobry wynik | Wymaga poprawy | Słaby wynik |
|---|---|---|---|---|
| LCP | Czas wyrenderowania największego elementu w widocznym obszarze | do 2,5 s | 2,5–4,0 s | powyżej 4,0 s |
| INP | Opóźnienie odpowiedzi na kliknięcia, dotknięcia i klawisze | do 200 ms | 200–500 ms | powyżej 500 ms |
| CLS | Suma nieoczekiwanych przesunięć elementów na stronie | do 0,1 | 0,1–0,25 | powyżej 0,25 |
Jakimi narzędziami zmierzyć szybkość strony
Cztery narzędzia Google pokrywają razem cały pomiar, od szybkiego testu jednego adresu po monitoring całej domeny rozłożony w czasie.
PageSpeed Insights
PageSpeed Insights to darmowe narzędzie Google raportujące wynik dla pojedynczego adresu URL na urządzeniach mobilnych i desktopowych naraz. Łączy dwa źródła danych: terenowe z ostatnich 28 dni z bazy CrUX oraz laboratoryjne wygenerowane na miejscu przez Lighthouse, a do tego dokłada listę konkretnych sugestii poprawy posortowaną według potencjalnego wpływu.
Chrome UX Report (CrUX)
Chrome UX Report to publiczny zbiór danych Google, zbierający realne pomiary wydajności od użytkowników przeglądarki Chrome. To właśnie z CrUX pochodzą wszystkie dane terenowe pokazywane w PageSpeed Insights i w Search Console, a strona musi mieć wystarczający, statystycznie znaczący ruch, żeby w ogóle trafić do zbioru.
Lighthouse
Lighthouse to otwarty silnik audytujący, który symuluje wczytanie strony w kontrolowanych warunkach, na emulowanym telefonie średniej klasy albo na desktopie, i ocenia wydajność, dostępność, SEO oraz dobre praktyki. Działa jako panel w Chrome DevTools, jako komenda w terminalu i jako silnik pracujący pod maską PageSpeed Insights.
Raport Podstawowe wskaźniki internetowe w Search Console
Search Console grupuje zaindeksowane adresy według statusu „Dobra”, „Wymaga poprawy” i „Słaba” na podstawie danych terenowych z CrUX, osobno dla urządzeń mobilnych i desktopowych. Status całej grupy adresów wyznacza jej najgorsza metryka, więc jeden problematyczny wskaźnik potrafi zepsuć ocenę wielu URL-i naraz, nawet jeśli pozostałe metryki wypadają dobrze.
Dane laboratoryjne a dane terenowe: na czym polega różnica
Lighthouse i CrUX odpowiadają na różne pytania i dlatego PageSpeed Insights pokazuje oba źródła naraz, jedno obok drugiego. Dane laboratoryjne powstają z jednego, kontrolowanego przebiegu testu i nadają się do debugowania: zmieniasz coś na stronie, odpalasz test ponownie i od razu widzisz, czy konkretna zmiana poprawiła wynik. Dane terenowe zbierają tysiące realnych wizyt na różnym sprzęcie i w różnych warunkach sieciowych, więc pokazują to, czego faktycznie doświadczają odwiedzający, ale nie da się ich odświeżyć na żądanie, bo agregują ruch z ostatnich 28 dni.
| Cecha | Dane laboratoryjne (Lighthouse) | Dane terenowe (CrUX) |
|---|---|---|
| Źródło pomiaru | Symulowane wczytanie na jednym urządzeniu testowym | Realne wizyty użytkowników przeglądarki Chrome |
| Dostępność | Natychmiast, dla każdego adresu, nawet jeszcze niepublicznego | Tylko dla stron z wystarczającym ruchem, z ostatnich 28 dni |
| Pomiar INP | Niemożliwy, wymaga prawdziwych interakcji użytkownika | Mierzony w pełni |
| Zastosowanie | Debugowanie konkretnej przyczyny problemu przed wdrożeniem | Ocena realnego doświadczenia i raport w Search Console |
Czy szybkość strony wpływa na pozycję w Google?
Google od lat powtarza to samo zastrzeżenie: Podstawowe wskaźniki internetowe to jeden z wielu sygnałów rankingowych, nie samodzielny przełącznik pozycji. W oficjalnej dokumentacji Google pisze wprost, że dobry wynik w raporcie Core Web Vitals „nie gwarantuje”, że strona znajdzie się na szczycie wyników wyszukiwania, bo na doświadczenie strony składa się więcej elementów niż same metryki szybkości. Google zaznacza też, że wyszukiwarka zawsze najpierw stara się pokazać najbardziej trafną treść, nawet jeśli jej strona ładuje się wolniej niż strona konkurenta. Innymi słowy, treść, która najlepiej odpowiada na zapytanie, wygrywa z lepiej zoptymalizowaną, ale słabszą merytorycznie stroną. Znaczenie szybkości rośnie tam, gdzie kilka stron oferuje porównywalnie dobrą treść, bo wtedy SEO rozstrzyga się na poziomie doświadczenia: kto szybciej pokaże treść i szybciej zareaguje na kliknięcie, temu łatwiej utrzymać uwagę i nie stracić odwiedzającego jeszcze przed przeczytaniem strony. Google wdrażał Core Web Vitals jako sygnał rankingowy etapami: dla urządzeń mobilnych między czerwcem a sierpniem 2021 roku, a dla desktopu od lutego do końca marca 2022 roku, jako część szerszego sygnału page experience.
Najczęstsze przyczyny wolnej strony i jak je naprawić
Cztery obszary odpowiadają w praktyce za większość problemów z szybkością strony.
Obrazy. Zbyt duże, nieskompresowane pliki i brak nowoczesnych formatów to najczęstsza przyczyna słabego LCP, gdy głównym elementem strony jest zdjęcie. Naprawa: kompresja, format WebP albo AVIF zamiast JPEG, wersje dopasowane rozmiarem do faktycznej szerokości wyświetlania i długie przechowywanie w przeglądarce dzięki odpowiednim nagłówkom cache.
JavaScript. Duże, synchroniczne skrypty w <head> blokują renderowanie strony, a długie zadania wykonywane na głównym wątku blokują reakcję na kliknięcia, co bezpośrednio pogarsza INP. Naprawa: atrybuty async albo defer przy skryptach niekrytycznych, dzielenie długich zadań na mniejsze fragmenty i ograniczenie liczby zewnętrznych widgetów ładowanych od razu przy starcie strony.
Hosting. Wolna odpowiedź serwera, czyli długi czas do pierwszego bajtu, opóźnia start wszystkiego, co dzieje się na stronie, łącznie z LCP, bo przeglądarka nie ma jeszcze czego renderować. Naprawa: szybszy hosting, sieć CDN skracająca dystans do użytkownika, pliki cache po stronie serwera i ograniczenie przekierowań na ścieżce do strony. Przy aplikacjach renderowanych po stronie klienta pomaga też renderowanie po stronie serwera, bo przeglądarka dostaje gotowy HTML zamiast pustej strony czekającej na wykonanie skryptu.
Fonty. Niestandardowe fonty webowe potrafią przesuwać tekst po doładowaniu, co pogarsza CLS, albo opóźniać pojawienie się treści, jeśli przeglądarka czeka na plik czcionki zamiast od razu pokazać font zastępczy. Naprawa: format WOFF2, ograniczenie liczby wariantów fontu, font-display: optional albo swap z dopasowanym size-adjust, a przy fontach od zewnętrznego dostawcy dodatkowo preconnect do jego domeny.
INP zamiast FID: co się zmieniło w marcu 2024
Do marca 2024 trzecią metryką Core Web Vitals był First Input Delay (FID), mierzący opóźnienie odpowiedzi wyłącznie na pierwszą interakcję użytkownika ze stroną. 12 marca 2024 roku Google oficjalnie zastąpił FID metryką INP, uznając ją za stabilny Core Web Vital. Zmianę zapowiedziano już w maju 2023 roku, a samo INP jako eksperymentalna metryka było dostępne w Chrome od maja 2022 roku, więc twórcy stron mieli prawie dwa lata na przygotowanie. Różnica jest praktyczna, nie kosmetyczna: FID sprawdzał tylko pierwsze kliknięcie, więc strona mogła wypaść w tej metryce świetnie i mimo to zawieszać się przy każdej kolejnej interakcji. INP ocenia responsywność całej sesji, dlatego bywa surowsze, zwłaszcza dla stron z dużą ilością JavaScriptu doładowywanego stopniowo już po pierwszym wczytaniu. Częsty błąd to wciąż szukanie danych FID w narzędziach albo w starszych poradnikach: raport dla FID zniknął z Search Console od razu po zmianie, a PageSpeed Insights i pozostałe narzędzia trzymały go jeszcze przez około pół roku jako okres przejściowy dla deweloperów.
Źródła
- Core Web Vitals – web.dev – https://web.dev/articles/vitals
- Interaction to Next Paint (INP) – web.dev – https://web.dev/articles/inp
- Largest Contentful Paint (LCP) – web.dev – https://web.dev/articles/lcp
- Cumulative Layout Shift (CLS) – web.dev – https://web.dev/articles/cls
- INP is now officially a Core Web Vital – web.dev – https://web.dev/blog/inp-cwv-march-12
- About PageSpeed Insights – Google for Developers – https://developers.google.com/speed/docs/insights/v5/about
- Chrome UX Report (CrUX) – Chrome for Developers – https://developer.chrome.com/docs/crux/about
- Understand the Core Web Vitals report – Google Search Console Help – https://support.google.com/webmasters/answer/9205520
- Understanding page experience in Google Search results – Google Search Central – https://developers.google.com/search/docs/appearance/page-experience
- Timeline for bringing page experience ranking to desktop – Google Search Central – https://developers.google.com/search/blog/2021/11/bringing-page-experience-to-desktop
- Optimize Largest Contentful Paint – web.dev – https://web.dev/articles/optimize-lcp
- Core Web Vitals – Wikipedia (pl) – https://pl.wikipedia.org/wiki/Core_Web_Vitals
Najczęściej zadawane pytania (FAQ)
Jakie są dobre wartości LCP, INP i CLS?
Dobry wynik LCP to 2,5 sekundy lub mniej, dobry INP to 200 milisekund lub mniej, a dobry CLS to 0,1 lub mniej. Google mierzy każdą z tych wartości na poziomie 75. percentyla wizyt, osobno dla urządzeń mobilnych i desktopowych, więc pojedyncza szybka wizyta nie wystarczy do dobrej oceny całej strony.
Czym różni się PageSpeed Insights od raportu w Search Console?
PageSpeed Insights testuje jeden podany adres URL na żądanie i pokazuje zarówno dane terenowe z ostatnich 28 dni, jak i dane laboratoryjne z Lighthouse wraz z konkretnymi sugestiami poprawy. Search Console pokazuje zbiorczy status wszystkich zaindeksowanych adresów Twojej domeny na podstawie samych danych terenowych z CrUX, bez wskazywania technicznej przyczyny problemu.
Czy szybkość strony wpływa na pozycję w Google?
Tak, ale jako jeden z wielu sygnałów rankingowych, nie jako samodzielny przełącznik pozycji. Google wprost zastrzega, że dobry wynik w Core Web Vitals nie gwarantuje wysokiej pozycji, bo wyszukiwarka zawsze najpierw stawia na najbardziej trafną treść, nawet jeśli ładuje się wolniej niż treść konkurencji.
Co zastąpiło metrykę FID i kiedy?
Metrykę FID zastąpiło INP, oficjalnie od 12 marca 2024 roku. FID mierzył opóźnienie odpowiedzi tylko na pierwszą interakcję z użytkownikiem, a INP ocenia responsywność całej sesji, dlatego bywa surowsze dla stron, które zawieszają się przy kolejnych kliknięciach, a nie przy pierwszym.
Jak sprawdzić szybkość swojej strony za darmo?
Najprościej wejść na pagespeed.web.dev, wkleić adres strony i poczekać na wynik z podziałem na urządzenia mobilne i desktopowe. Narzędzie pokazuje jednocześnie wynik terenowy z realnych wizyt oraz wynik laboratoryjny z Lighthouse, a pod spodem listę konkretnych rekomendacji do poprawy.
Dlaczego moja strona jest wolna mimo szybkiego hostingu?
Sam szybki hosting rozwiązuje tylko część problemu, bo o odczuwanej szybkości decydują też inne czynniki: ciężkie, nieskompresowane obrazy, blokujący renderowanie JavaScript, długie zadania na głównym wątku pogarszające responsywność kliknięć oraz fonty webowe przesuwające układ strony po doładowaniu. Dobry hosting przyspiesza czas do pierwszego bajtu, ale nie naprawi za Ciebie tych elementów po stronie frontendu.