W skrócie: Core Web Vitals to trzy wskaźniki Google: LCP (jak szybko pojawia się główna treść, dobrze do 2,5 s), INP (jak szybko strona reaguje na kliknięcia, dobrze do 200 ms) i CLS (czy układ nie skacze, dobrze do 0,1). Liczy się wynik prawdziwych użytkowników dla 75% wizyt, osobno na telefonie i komputerze. Najczęściej pomagają: lżejsze obrazy, mniej skryptów zewnętrznych i stałe miejsce na obrazy oraz banery.
Po co małej firmie szybka strona?
Klient szuka mechanika na telefonie, stojąc przy zepsutym aucie. Jeśli strona ładuje się kilka sekund, a przycisk „Zadzwoń” przeskakuje mu pod palcem, wraca do wyników i dzwoni do konkurencji.
Google pisze w dokumentacji Search Central, że zdecydowanie zaleca osiągnięcie dobrych wyników Core Web Vitals dla sukcesu w wyszukiwarce i ogólnie dobrego doświadczenia użytkownika. Nie podaje jednak, jak dużą wagę mają te wskaźniki w rankingu. Trafność treści nadal liczy się bardziej. Szybkość traktuj więc przede wszystkim jako sposób na to, żeby odwiedzający nie uciekali.
Trzy wskaźniki i ich progi
| Wskaźnik | Co mierzy | Dobrze | Słabo |
|---|---|---|---|
| LCP (Largest Contentful Paint) | czas do wyświetlenia największego elementu, np. zdjęcia w nagłówku | do 2,5 s | powyżej 4 s |
| INP (Interaction to Next Paint) | czas reakcji strony na kliknięcie, dotknięcie, klawisz | do 200 ms | powyżej 500 ms |
| CLS (Cumulative Layout Shift) | jak bardzo przesuwa się układ podczas ładowania | do 0,1 | powyżej 0,25 |
Według web.dev strona przechodzi ocenę, gdy wszystkie trzy wskaźniki są dobre dla 75. percentyla wizyt, liczonego osobno dla telefonów i komputerów. Oznacza to, że co najmniej trzy na cztery wizyty muszą mieścić się w progu.
INP zastąpił w 2024 roku wcześniejszy wskaźnik FID. Mierzy tylko kliknięcia, dotknięcia i klawiaturę, nie przewijanie.
Jak sprawdzić swoją stronę?
Wejdź na pagespeed.web.dev, wpisz adres strony i poczekaj na wynik. Raport ma dwie części, które łatwo pomylić.
Dane z pola: prawdziwi użytkownicy
Górna część raportu to dane z raportu Chrome User Experience (CrUX): pomiary od prawdziwych użytkowników przeglądarki Chrome z ostatnich 28 dni. To one decydują o ocenie Core Web Vitals.
Mała strona często nie ma wystarczająco dużo danych. Wtedy PageSpeed Insights pokazuje wynik dla całej domeny, a jeśli i tego brakuje, nie pokazuje danych z pola wcale. To normalne przy nowych stronach i stronach z niewielkim ruchem.
Dane laboratoryjne: symulacja
Dolna część raportu to wynik narzędzia Lighthouse, który ładuje stronę w symulowanych warunkach: dla telefonu jest to telefon średniej klasy na sieci komórkowej. Stąd liczba od 0 do 100.
Według dokumentacji PageSpeed Insights dane laboratoryjne przydają się do szukania przyczyn problemów, ale mogą nie oddawać realnych warunków. Wynik 100 w laboratorium nie gwarantuje dobrych danych z pola i odwrotnie.
Jak czytać raport w praktyce
- Najpierw sprawdź zakładkę Telefon. Większość klientów lokalnych firm przychodzi z telefonu.
- Jeśli są dane z pola, patrz na nie i na trzy wskaźniki, nie na liczbę od 0 do 100.
- Jeśli danych z pola nie ma, korzystaj z laboratorium, ale traktuj je jako wskazówkę.
- Zjedź do sekcji diagnostyki. Tam są konkretne przyczyny: zbyt duże obrazy, blokujące skrypty, brak wymiarów obrazów.
- Sprawdź nie tylko stronę główną, ale też najważniejsze podstrony usług i kontakt.
Co zwykle poprawia LCP?
LCP to najczęściej zdjęcie albo duży nagłówek na górze strony. Według web.dev do LCP wlicza się też czas połączenia, przekierowań i odpowiedzi serwera. Na stronach małych firm zwykle pomagają:
- lżejsze zdjęcie w nagłówku: format WebP lub AVIF, rozmiar dopasowany do ekranu, a nie zdjęcie prosto z aparatu,
- brak leniwego ładowania dla głównego zdjęcia: obraz widoczny od razu ma się ładować od razu,
- szybszy serwer i pamięć podręczna strony: gotowe strony podawane z cache zamiast generowane przy każdej wizycie,
- mniej przekierowań: jeden adres strony, bez łańcucha http → https → www → bez www,
- lekki motyw zamiast ciężkiego kreatora: mniej kodu do pobrania przed pokazaniem treści.
Co zwykle poprawia CLS?
Web.dev wymienia jako typowe przyczyny przesunięć układu: obrazy i filmy bez znanych wymiarów, czcionki, które po załadowaniu mają inny rozmiar niż zastępcze, oraz reklamy i widżety, które same zmieniają rozmiar. W praktyce:
- podaj wymiary obrazów w kodzie, żeby przeglądarka zarezerwowała miejsce,
- zarezerwuj miejsce na mapę, film i widżet opinii,
- baner cookies nakładaj na stronę, zamiast wpychać go nad treść; więcej w tekście Cookies i zgody na stronie małej firmy,
- animuj przez transform, a nie przez zmianę wysokości czy pozycji elementu; tak zaleca web.dev.
Co zwykle poprawia INP?
INP pogarszają długie zadania w JavaScripcie, które blokują przeglądarkę, gdy użytkownik klika. Na stronach firm winowajcami bywają:
- czaty i widżety ładowane z zewnętrznych serwerów,
- kilka narzędzi analitycznych i pikseli reklamowych naraz,
- ciężkie kreatory stron z dużą ilością skryptów,
- suwaki i animacje na stronie głównej.
Najprostsza poprawka to usunięcie tego, czego nie potrzebujesz. Każdy skrypt zewnętrzny warto sprawdzić pytaniem: czy ktoś w firmie patrzy na dane z tego narzędzia?
Obrazy: ściąga dla właściciela firmy
Na stronach małych firm największym ciężarem są zwykle zdjęcia. Kilka zasad, które możesz stosować sam, dodając zdjęcia do strony:
- zmniejsz zdjęcie przed wgraniem: zdjęcie z telefonu ma często kilka tysięcy pikseli szerokości i kilka megabajtów; na stronę wystarczy szerokość około 1600–2000 pikseli dla zdjęcia na całą szerokość i mniej dla zdjęć w treści,
- wybierz nowoczesny format: WebP albo AVIF ważą zwykle wyraźnie mniej niż JPG przy podobnej jakości; wiele hostingów i wtyczek konwertuje je automatycznie,
- nie wrzucaj zdjęć do suwaka na górze strony: suwak z pięcioma dużymi zdjęciami to pięć razy więcej danych do pobrania, a klient i tak zwykle widzi tylko pierwsze,
- opisz zdjęcie: tekst alternatywny nie przyspiesza strony, ale pomaga osobom niewidomym i wyszukiwarce zrozumieć, co jest na zdjęciu.
Jedna zasada dla wykonawcy: obrazy niżej na stronie powinny ładować się dopiero przy przewijaniu, a główne zdjęcie na górze od razu.
WordPress, kreator czy strona statyczna a szybkość
Technologia strony ma wpływ na wynik. Strona statyczna jest zwykle najszybsza, WordPress z lekkim motywem może być bardzo szybki, a kreatory i ciężkie motywy z wieloma funkcjami zwykle wymagają więcej pracy. Porównanie opisujemy w tekście WordPress, kreator czy strona statyczna.
Jak często sprawdzać?
Dane z pola zbierane są z 28 dni, więc efekt poprawek zobaczysz w raporcie dopiero po kilku tygodniach. Praktyczny rytm:
- po każdej większej zmianie na stronie: szybki test laboratoryjny,
- raz w miesiącu: dane z pola dla strony głównej i najważniejszych podstron,
- po dodaniu nowego narzędzia (czat, piksel, widżet): test przed i po.
Jeśli masz Google Search Console, raport Core Web Vitals pokaże grupy adresów z problemami bez ręcznego sprawdzania każdej podstrony.
Szybkość to też kwestia utrzymania: aktualizacje, cache, porządek we wtyczkach. Koszt takiej pracy w skali kilku lat liczymy w tekście Ile kosztuje strona firmowa przez 3 lata.
Strona wolna na telefonie?
Przyspieszenie strony kosztuje 690 zł netto, a szybki audyt pokaże, od czego zacząć. Zobacz cennik.
Źródła
- Google, Web Vitals (web.dev), web.dev/articles/vitals, dostęp 2.11.2026
- Google, Interaction to Next Paint (web.dev), web.dev/articles/inp, dostęp 2.11.2026
- Google, Largest Contentful Paint (web.dev), web.dev/articles/lcp, dostęp 2.11.2026
- Google, Cumulative Layout Shift (web.dev), web.dev/articles/cls, dostęp 2.11.2026
- Google, About PageSpeed Insights, developers.google.com/speed/docs/insights/v5/about, dostęp 2.11.2026
- Google Search Central, Understanding Core Web Vitals and Google search results, developers.google.com/search/docs/appearance/core-web-vitals, dostęp 2.11.2026