W skrócie
- Core Web Vitals to trzy wskaźniki: LCP (wczytanie głównej treści), INP (reakcja na kliknięcia) i CLS (stabilność układu).
- Dobre wyniki to LCP do 2,5 s, INP do 200 ms i CLS do 0,1, mierzone na 75. percentylu wizyt prawdziwych użytkowników.
- Google ocenia stronę na podstawie danych od użytkowników; test laboratoryjny w PageSpeed Insights służy przede wszystkim do szukania przyczyn.
- Najczęstsze problemy to ciężkie obrazy, nadmiar skryptów i wtyczek, źle ładowane fonty, przesuwające się elementy i wolny serwer.
- Szybkość jest jednym z sygnałów rankingowych, ale nie zastąpi dobrej treści — najbardziej pomaga, gdy konkurencyjne strony są porównywalne.
Czym są Core Web Vitals i dlaczego Google je mierzy
Core Web Vitals, po polsku podstawowe wskaźniki internetowe, to trzy pomiary, którymi Google opisuje, jak strona zachowuje się z perspektywy użytkownika. Nie chodzi o abstrakcyjną „szybkość serwera”, tylko o konkretne odczucia: jak szybko widać najważniejszą treść, czy strona reaguje na kliknięcie bez zwłoki i czy elementy nie skaczą w trakcie wczytywania.
Wskaźniki są częścią szerszego zestawu sygnałów, które Google określa jako page experience, czyli wrażenia użytkownika na stronie. Zestaw zmieniał się z czasem: w marcu 2024 roku wskaźnik INP zastąpił wcześniejszy FID, bo lepiej oddaje responsywność strony przez całą wizytę, a nie tylko przy pierwszym kliknięciu. Jeśli w starszym raporcie zobaczysz FID, potraktuj go jako historię.
LCP, INP i CLS w prostych słowach — jakie wyniki są dobre
Każdy wskaźnik ma trzy przedziały: dobry, wymagający poprawy i słaby. Oto, co oznaczają i gdzie przebiegają granice:
- LCP (Largest Contentful Paint) — czas, po którym wyświetla się największy element widoczny na pierwszym ekranie, najczęściej duże zdjęcie, baner albo nagłówek. Dobry wynik to do 2,5 s, słaby — powyżej 4 s.
- INP (Interaction to Next Paint) — jak szybko strona pokazuje reakcję na działanie użytkownika: kliknięcie przycisku, rozwinięcie menu, wpisanie tekstu. Dobry wynik to do 200 ms, słaby — powyżej 500 ms.
- CLS (Cumulative Layout Shift) — miara nieoczekiwanych przesunięć układu, na przykład gdy tekst „ucieka” w dół, bo nad nim doładował się obrazek. Dobry wynik to do 0,1, słaby — powyżej 0,25.
Google bierze pod uwagę 75. percentyl wizyt prawdziwych użytkowników, osobno na telefonach i komputerach. W praktyce co najmniej trzy na cztery wizyty muszą zmieścić się w progu „dobry”. Twój szybki laptop na światłowodzie nie jest więc miarodajny — liczą się też starsze telefony i słaby zasięg Twoich klientów.
Dane od użytkowników a test w PageSpeed Insights — skąd różnice
Wyniki pochodzą z dwóch źródeł i łatwo je pomylić. Dane terenowe to pomiary od prawdziwych użytkowników przeglądarki Chrome, zbierane w raporcie CrUX (Chrome User Experience Report) z ostatnich 28 dni. Zobaczysz je w górnej części raportu PageSpeed Insights oraz w raporcie „Podstawowe wskaźniki internetowe” w Google Search Console, który grupuje podobne adresy i pokazuje, które wymagają poprawy. Jeśli problem dotyczy całej grupy, na przykład wszystkich kart produktów albo wpisów na blogu, przyczyna zwykle leży w szablonie, a jedna poprawka naprawia wiele adresów naraz.
Dane laboratoryjne to pojedynczy test wykonany przez narzędzie Lighthouse — w PageSpeed Insights symuluje ono przeciętny telefon i wolniejsze połączenie. Z niego pochodzi znana ocena od 0 do 100. Test nie klika w stronę, więc zamiast INP pokazuje pokrewny wskaźnik TBT (Total Blocking Time), który mówi, jak długo przeglądarka była zablokowana przez skrypty.
Różnice między źródłami są normalne. Prawdziwi użytkownicy mają różne urządzenia i łącza, część ma już stronę w pamięci przeglądarki, klikają w różne elementy, a czat czy skrypty reklamowe ładują się u nich w innym momencie. Mniej popularne strony mogą w ogóle nie mieć danych terenowych, bo do CrUX trafia tylko ruch o wystarczającej skali. Raport najlepiej czytać w takiej kolejności:
- Sprawdź najpierw dane terenowe — to one odpowiadają za ocenę strony w Google.
- Jeśli ich brak, oprzyj się na teście laboratoryjnym, ale traktuj go jako przybliżenie.
- W diagnostyce zobacz, który element jest elementem LCP i co opóźnia jego wczytanie.
- Po wdrożeniu poprawek daj danym terenowym czas — obejmują 28 dni, więc zmieniają się stopniowo.
Nie goń za wynikiem 100/100 za wszelką cenę. Ocena Lighthouse to narzędzie diagnostyczne, a nie cel sam w sobie: strona z oceną 85 i dobrymi danymi od użytkowników jest w lepszej sytuacji niż „setka” w laboratorium przy słabych pomiarach terenowych.
Jak poprawić LCP: obrazy, fonty i serwer
Najczęstszą przyczyną słabego LCP jest ogromne zdjęcie na pierwszym ekranie: plik prosto z aparatu, kilka razy większy, niż potrzebuje ekran telefonu. Zaraz za nim jest wolny serwer, przez który przeglądarka długo czeka na pierwszy fragment strony, zanim w ogóle zacznie cokolwiek wyświetlać.
Zacznij od sprawdzenia, co jest elementem LCP na Twojej stronie — PageSpeed Insights wskazuje go w diagnostyce. Jeśli to tekst nagłówka, winne są zwykle fonty albo serwer; jeśli zdjęcie, najwięcej da jego odchudzenie i wcześniejsze wczytanie. Typowe poprawki wyglądają tak:
- zapisuj zdjęcia w formatach WebP lub AVIF i w wymiarach dopasowanych do miejsca, w którym się wyświetlają — osobno dla telefonu i komputera,
- stosuj leniwe ładowanie (lazy loading) dla obrazów poniżej pierwszego ekranu, ale nigdy dla głównego zdjęcia u góry strony — ono ma wczytać się jak najwcześniej,
- ogranicz liczbę fontów i ich odmian, hostuj je razem ze stroną i pozwól wyświetlić tekst fontem zastępczym, zanim wczyta się właściwy,
- zadbaj o wydajny hosting i pamięć podręczną (cache), żeby serwer nie budował strony od zera przy każdej wizycie,
- rozważ CDN, czyli sieć serwerów dostarczających pliki z miejsca bliższego użytkownikowi.
Uważaj na slidery z kilkoma dużymi zdjęciami w nagłówku. Zwykle spowalniają start strony, a pierwsze wrażenie i tak robi pierwszy slajd. Jedno dobre, lekkie zdjęcie z jasnym nagłówkiem prawie zawsze wypada lepiej.
Strona działa wolno albo znika z Google?
Znajdziemy przyczynę — od szybkości i indeksowania po przekierowania — i naprawimy ją bez przestojów w działaniu strony.
Jak poprawić INP: mniej skryptów i wtyczek
Słaby INP oznacza, że użytkownik klika, a strona przez chwilę „myśli”, zanim cokolwiek się zmieni. Winowajcą jest prawie zawsze JavaScript — zbyt dużo kodu wykonywanego naraz, który blokuje przeglądarkę. Na stronach firmowych często nie jest to kod samej strony, tylko dodatki: widżety czatu, piksele reklamowe, narzędzia analityczne, mapy, osadzone filmy i motywy obciążone wieloma wtyczkami.
Zanim zaczniesz optymalizować, zrób inwentaryzację. Wypisz wszystkie skrypty i wtyczki działające na stronie i przy każdym zadaj pytanie: kto z tego korzysta i co by się stało, gdyby tego nie było? Często okazuje się, że część to pozostałości po dawnych kampaniach i testach.
- usuń wtyczki i skrypty, z których nikt już nie korzysta,
- ładuj dodatki zewnętrzne z opóźnieniem lub dopiero po interakcji — czat po kliknięciu ikony, mapę po przewinięciu do kontaktu,
- zamiast osadzonego filmu pokazuj miniaturę, a odtwarzacz wczytuj dopiero po kliknięciu,
- trzymaj tagi marketingowe w jednym miejscu, żeby było wiadomo, co i dlaczego się ładuje,
- przy stronach na gotowych szablonach rozważ lżejszy motyw zamiast dokładania kolejnych wtyczek „przyspieszających”.
Jeśli problemy wynikają z samej konstrukcji strony, kolejne łatki niewiele dadzą i rozsądniejsza bywa przebudowa. Zalety i ograniczenia obu dróg porównujemy w artykule WordPress czy strona dedykowana.
Jak poprawić CLS: koniec ze „skaczącą” stroną
Znasz to uczucie: chcesz kliknąć link, a w ostatniej chwili treść przesuwa się w dół i trafiasz w coś zupełnie innego. To właśnie mierzy CLS. Przesunięcia irytują, a na telefonie potrafią skończyć się kliknięciem w przycisk, którego użytkownik wcale nie chciał nacisnąć.
CLS jest zwykle najłatwiejszy do poprawienia z całej trójki, bo przyczyny widać gołym okiem. Wczytaj stronę kilka razy na telefonie, najlepiej przy słabszym zasięgu, i obserwuj, co się przesuwa. Najczęściej pomaga:
- podawanie wymiarów wszystkich obrazów i filmów, żeby przeglądarka zarezerwowała dla nich miejsce, zanim się wczytają,
- stała przestrzeń zarezerwowana na reklamy, banery i elementy osadzane z innych serwisów,
- wyświetlanie banera cookies i pop-upów jako warstwy nad treścią, zamiast wstawiania ich w układ i spychania wszystkiego w dół,
- rezygnacja z doklejania elementów nad treścią, którą użytkownik już czyta, na przykład paska promocji pojawiającego się po kilku sekundach,
- font zastępczy o proporcjach zbliżonych do docelowego, żeby podmiana kroju nie zmieniała długości wierszy.
Czy szybkość strony wpływa na pozycje w Google?
Tak, ale nie tak mocno, jak sugerują niektóre oferty „przyspieszania pod SEO”. Google potwierdza, że Core Web Vitals są wykorzystywane przez jego systemy rankingowe, a jednocześnie podkreśla, że najważniejsza jest trafna i przydatna treść. Wolniejsza strona z najlepszą odpowiedzią na pytanie użytkownika może wyprzedzić szybką stronę o niczym.
Szybkość zaczyna ważyć więcej, gdy kilka stron odpowiada na zapytanie podobnie dobrze — a w konkurencyjnych branżach zdarza się to często. Wtedy lepsze wrażenia użytkownika mogą przechylić szalę. Dlatego Core Web Vitals warto traktować jako jeden z punktów szerszej listy kontrolnej, którą opisujemy w artykule audyt SEO — checklista.
Często ważniejszy od samego rankingu jest wpływ na ludzi. Gdy strona długo się wczytuje, część odwiedzających wraca do wyników i wybiera konkurencję, zanim zobaczy ofertę. Strona reagująca z opóźnieniem zniechęca do wypełniania formularzy, a w sklepie utrudnia przejście przez koszyk. Na tę samą wolną stronę trafia też ruch, za który płacisz w reklamach.
Przykład: animacje 3D i wynik 99–100 w PageSpeed Insights
Efektowna strona nie musi być wolna. Nasza własna strona, nextpagestudio.pl, ma rozbudowane animacje 3D w technologii WebGL, a w październiku 2026 roku uzyskała w PageSpeed Insights wynik 99–100/100 w teście na telefonie.
Całą pracę wykonuje kolejność ładowania. Najpierw wczytuje się treść: tekst, nagłówki, przyciski i lekkie grafiki, więc użytkownik od razu widzi ofertę i może przejść dalej. Ciężka scena 3D ładuje się dopiero potem i tylko na urządzeniach ze sprzętową akceleracją grafiki. Tam, gdzie jej nie ma — na słabszym sprzęcie, ale też w środowisku testowym Lighthouse — scena w ogóle się nie wczytuje, więc niczego nie blokuje.
Tę samą zasadę stosujemy w projektach dla klientów, zarówno przy klasycznych stronach firmowych, jak i przy stronach 3D i WebGL. Szybkość planujemy od pierwszego szkicu, bo dokładanie jej na końcu zawsze kosztuje więcej niż zaprojektowanie lekkiej strony od początku.