Core Web Vitals 2026. LCP, CLS, INP w praktyce dla małej firmy

Część przewodnika: SEO lokalne 2026, kompletny przewodnik dla małej firmy →
Ten artykuł rozwija jeden z wątków pełnego przewodnika.

W skrócie: Core Web Vitals (LCP, INP, CLS) to ranking factor od 2021. W 2026 strona z LCP > 2,5 s nie pojawia się w top 10 organicznych dla konkurencyjnych zapytań.

• Cele 2026: LCP < 2,5 s, INP < 200 ms, CLS < 0,1
• Pomiar: PageSpeed Insights (lab data) + Search Console (CrUX field data)
• Statyczna HTML: out-of-the-box w green. WordPress wymaga optymalizacji.

Core Web Vitals to trzy liczby, którymi Google mierzy, jak Twoja strona zachowuje się w rękach prawdziwego gościa. Nie chodzi o to, czy wygląda ładnie na Twoim monitorze. Chodzi o to, jak szybko się pokazuje, czy nie ucieka spod palca i czy nie każe czekać po kliknięciu. Google zrobił z tego oficjalny czynnik rankingowy w 2021 roku, przy okazji Page Experience Update, i od tamtej pory strona z czerwonymi wynikami ma pod górkę, a strona z zielonymi ma jeden problem mniej. W 2026 nic się w tej zasadzie nie zmieniło poza jedną rzeczą, o której za chwilę: jedna z metryk jest nowsza, niż część poradników w sieci przyznaje.

Co właściwie mierzą te trzy metryki

Zacznę od tego, że nazwy brzmią groźniej, niż są. Za każdym skrótem stoi jedno proste pytanie o to, jak gość odbiera Twoją stronę.

LCP, czyli Largest Contentful Paint, mierzy, po ilu sekundach na ekranie pojawia się największy widoczny element. Zwykle to zdjęcie w nagłówku, baner albo duży blok tekstu na starcie. Dla gościa LCP to po prostu moment, w którym strona wygląda na załadowaną, w którym wie, że trafił tam, gdzie chciał, a nie na biały ekran. Jeśli ten moment przychodzi po czterech sekundach, spora część ludzi zdąży już wrócić do wyników wyszukiwania.

INP, czyli Interaction to Next Paint, mierzy, jak szybko strona reaguje na to, co gość robi. Kliknięcie w przycisk, rozwinięcie menu, wpisanie czegoś w pole. Chodzi o opóźnienie między akcją a widoczną odpowiedzią strony. Jeśli gość klika „dodaj do koszyka” i przez pół sekundy nic się nie dzieje, klika drugi raz, bo myśli, że nie trafił. Właśnie to opóźnienie INP wyłapuje. Tu ważna sprawa, bo krąży na ten temat sporo starych treści: INP zastąpił dawną metrykę FID w marcu 2024. FID już nie jest czynnikiem, którym Google ocenia strony, więc jeśli w jakimś poradniku widzisz go w czasie teraźniejszym, ten poradnik jest po prostu nieaktualny.

CLS, czyli Cumulative Layout Shift, mierzy, czy strona „skacze” w trakcie ładowania. Znasz to uczucie: chcesz kliknąć w link, a w ostatniej chwili doładowuje się reklama albo baner, wszystko przeskakuje w dół i klikasz w coś zupełnie innego. CLS liczy sumę takich przeskoków. Im bliżej zera, tym stabilniej strona się układa i tym mniej gość klika w rzeczy, których nie chciał.

To wszystko. Trzy pytania: jak szybko widać stronę, jak szybko odpowiada i czy nie ucieka spod palca.

Dlaczego to się w ogóle opłaca poprawiać

Są dwa powody i oba są konkretne. Pierwszy to ranking. Google potwierdził, że Core Web Vitals wpływają na pozycję w wynikach. Przy zapytaniach, o które bije się dziesięć podobnych firm, wolna strona przegrywa z szybką, jeśli reszta jest zbliżona. To nie jest jedyny czynnik i nie wygra sam z lepszą treścią czy silniejszym profilem linków, ale bywa tym języczkiem u wagi, który decyduje, kto jest wyżej.

Drugi powód jest ważniejszy, bo działa niezależnie od Google. Wolna strona traci gości, zanim ktokolwiek zdąży cokolwiek na niej przeczytać. Człowiek, który wchodzi z telefonu, w autobusie, na słabym zasięgu, nie czeka pięciu sekund na Twój nagłówek. Wraca do wyszukiwarki i klika w kolejny wynik, czyli w konkurencję. Możesz mieć najlepszą ofertę w mieście, ale jeśli gość jej nie zobaczy, bo strona się nie załadowała, to tak, jakby jej nie było. Poprawa szybkości to nie zabawa w liczby dla samego Google. To po prostu mniej ludzi, którzy odbijają się od drzwi.

Progi, które warto znać

Google podał konkretne wartości i to nie jest tajemnica ani moja interpretacja, tylko publiczne liczby, które sam ustala. Dla LCP wynik poniżej 2,5 sekundy jest dobry, między 2,5 a 4 sekundami wymaga poprawy, a powyżej 4 sekund jest słaby. Dla INP dobry wynik to poniżej 200 milisekund, między 200 a 500 milisekund jest do poprawy, a powyżej 500 milisekund słaby. Dla CLS dobrze jest poniżej 0,1, między 0,1 a 0,25 do poprawy, a powyżej 0,25 słabo.

Cel jest jeden: wszystkie trzy w zielonym, mierzone na wersji mobilnej. To ostatnie zaskakuje wielu właścicieli, bo Google ocenia stronę tak, jak widzi ją telefon, nie tak, jak wygląda na Twoim dużym monitorze z szybkim łączem. Jeśli sprawdzasz tylko na komputerze, patrzysz na inny świat niż ten, po którym Google Cię ocenia.

Jak sprawdzić to u siebie

Najprościej wejść na PageSpeed Insights, wkleić adres strony i poczekać kilkanaście sekund. Dostaniesz wynik z podziałem na dwa rodzaje danych i ta różnica jest istotna. Field data to rzeczywiste pomiary z przeglądarek prawdziwych ludzi, którzy Twoją stronę odwiedzili, zbierane przez Chrome. To właśnie te liczby liczą się w rankingu. Lab data to test syntetyczny robiony na jednej symulowanej maszynie, pomocniczy do diagnozy, ale nie to, czym Google ocenia. Jeśli field i lab się rozjeżdżają, wierz field, bo to jest głos Twoich gości, a nie jednego testu.

Drugie miejsce to Search Console, w którym sekcja Core Web Vitals pokazuje, które adresy Twojej strony mają problem, na podstawie danych z ostatnich kilku tygodni. Trzecie to wtyczka Web Vitals do Chrome, która pokazuje wyniki na żywo dla każdej strony, którą akurat oglądasz, przydatna, gdy chcesz szybko coś podejrzeć bez wchodzenia w narzędzia.

Jeśli chcesz mieć te pomiary zebrane po polsku, w jednym miejscu, z gotową listą poprawek ustawionych od najważniejszej, opisałem darmowe narzędzia i to, jak czytać ich wyniki, w osobnym wpisie o darmowym audycie strony. Sam też udostępniam narzędzie audytu, które pod spodem korzysta z tego samego oficjalnego silnika Google, tylko podaje wszystko na jednym ekranie, bez logowania i bez podawania maila.

Co najczęściej psuje wyniki

Kiedy strona świeci na czerwono, przyczyna prawie zawsze siedzi w tych samych kilku miejscach. Najczęstsza to za ciężkie zdjęcia. Zdjęcie w nagłówku zapisane w pełnej rozdzielczości z aparatu potrafi ważyć kilka megabajtów i to ono zwykle jest tym „największym elementem”, na który czeka LCP. Telefon na słabym łączu ściąga taki plik długo, więc strona zawiesza się na starcie. Druga sprawa to skrypty, których jest za dużo. Każdy dodatek, licznik, czat, piksel reklamowy i wtyczka dokłada kod, który przeglądarka musi wykonać, zanim strona zacznie reagować. To zwykle właśnie tu psuje się INP, bo telefon dławi się przetwarzaniem, zamiast odpowiadać na kliknięcia.

Trzecia typowa przyczyna to wolny hosting. Zanim przeglądarka w ogóle zacznie coś rysować, serwer musi jej odesłać stronę, a jeśli serwer jest przeciążony albo tani, ten pierwszy krok trwa i trwa, i całe LCP przesuwa się w prawo, niezależnie od tego, jak lekka jest sama strona. Czwarta to brak wymiarów obrazów. Kiedy przeglądarka nie wie z góry, ile miejsca zajmie zdjęcie, rezerwuje zero, a gdy plik się doładuje, wpycha go w układ i wszystko poniżej przeskakuje. Tak rośnie CLS. Wystarczy, że obrazek ma podaną szerokość i wysokość, a przeglądarka od razu zostawia dla niego miejsce i nic nie skacze. Do tego dochodzą banery i reklamy wstawiane po załadowaniu bez zarezerwowanego miejsca oraz fonty, które doładowują się z opóźnieniem i przy podmianie przesuwają tekst.

Jak to realnie poprawić

Kolejność jest prosta i warto ją trzymać, bo największe zyski leżą na początku. Zacznij od zdjęć. Przeskaluj je do rozmiaru, w jakim naprawdę się wyświetlają, zapisz w nowoczesnym formacie w rodzaju WebP i podaj im wymiary w kodzie. Samo to często wyciąga LCP i CLS z czerwonego do zielonego, bo strona przestaje ściągać zbędne megabajty i przestaje skakać. Potem zajmij się skryptami. Przejrzyj, co naprawdę jest potrzebne, a co dokłada się z rozpędu, i wywal to, bez czego strona żyje. To, co zostaje, niech ładuje się z opóźnieniem, żeby nie blokowało pierwszego renderu. Mniej kodu do wykonania to lepszy INP.

Jeśli po tym wciąż jest wolno, spójrz na hosting. Tani, przeciążony serwer bywa sufitem, którego żadna optymalizacja obrazków nie przebije, bo problem leży poniżej strony, w tym, jak szybko serwer w ogóle odpowiada. Czasem najtańszą poprawą, jaką da się zrobić, jest przeniesienie na przyzwoity hosting albo zejście z ciężkiej platformy na coś lżejszego.

I tu dochodzimy do sedna, o którym w Lokal360 mówię wprost. Najłatwiej wygrać z Core Web Vitals, nie mając problemu, który trzeba naprawiać. Strona zbudowana jako statyczny HTML, bez bazy danych i bez ciężkiego silnika doklejanego pod spód, jest lekka od pierwszego dnia. Nie ma dziesięciu wtyczek walczących o czas procesora, nie ma motywu, który ładuje style na zapas. Przeglądarka dostaje gotową stronę i po prostu ją pokazuje. Dlatego takie strony bywają zielone bez żadnej optymalizacji, podczas gdy typowy WordPress z motywem i naręczem dodatków trzeba dopiero mozolnie odchudzać, żeby dobić do tych samych progów. To jeden z powodów, dla których część firm decyduje się na migrację z WordPressa na statyczny HTML: łatwiej zbudować szybko od razu, niż gonić szybkość na czymś, co z natury jest ciężkie.

Kiedy to nie jest Twój pierwszy problem

Napiszę to uczciwie, bo inaczej wyszłaby ze mnie reklama, a nie porada. Core Web Vitals nie są magiczną dźwignią, która sama wywinduje Cię na szczyt. Jeśli Twoja strona ma trzech gości dziennie, bo nikt jej nie zna i nikt do niej nie linkuje, to przyspieszenie ładowania z trzech sekund do jednej nie sprawi, że nagle pojawią się klienci. Zielone metryki pomagają wtedy, gdy reszta układanki już jest: sensowna treść odpowiadająca na to, czego ludzie szukają, poukładane podstawy SEO, wizytówka w Google, jakieś opinie i naturalne linki z zewnątrz. Szybkość jest wtedy tym, co pozwala wyprzedzić równie dobrą konkurencję, a nie tym, co buduje pozycję od zera.

Odwróćmy to jednak. Jeśli robisz wszystko inne dobrze, piszesz, dbasz o profil w Google, zbierasz opinie, a strona i tak nie przebija się na górę, to wolne Core Web Vitals potrafią być tą kotwicą, która Cię ciągnie w dół. Wtedy warto się nimi zająć w pierwszej kolejności, bo poprawiasz coś, co realnie hamuje resztę Twojej pracy. Prosta zasada: zajmij się szybkością, gdy masz już z czym rankować i chcesz to wypchnąć wyżej, a nie po to, by naprawić stronę, której głównym problemem jest to, że nie ma na niej nic wartego szukania.

Często zadawane pytania

Co to są Core Web Vitals?

Trzy metryki Google mierzące UX strony: LCP (Largest Contentful Paint - kiedy ładuje się największy widoczny element), CLS (Cumulative Layout Shift - czy strona ‘skacze’) i INP (Interaction to Next Paint - jak szybko reaguje na kliknięcie). Razem składają się na ‘Page Experience’.

Jakie progi obowiązują w 2026?

LCP: dobry < 2.5s, do poprawy 2.5-4s, słaby > 4s. CLS: dobry < 0.1, do poprawy 0.1-0.25, słaby > 0.25. INP: dobry < 200ms, do poprawy 200-500ms, słaby > 500ms. Cel: wszystkie trzy w zielonym, mierzone na mobile (Google używa mobilnej wersji).

Jak zmierzyć Core Web Vitals?

1. PageSpeed Insights (pagespeed.web.dev) - lab data + field data z Chrome User Experience Report. 2) Search Console - sekcja ‘Core Web Vitals’ pokazuje strony z problemami. 3) Web Vitals Chrome extension. 4) DevTools Lighthouse. Field data (rzeczywiste pomiary użytkowników) jest tym, co Google używa do rankingu - nie lab data.

Co najczęściej psuje Core Web Vitals?

LCP: za duże obrazy, wolny hosting. CLS: brak wymiarów obrazów, banery wstawiane po załadowaniu, fonty bez font-display. INP: ciężki JavaScript, blokujące skrypty third-party (Analytics, ads, chat widgets). Strony statyczne mają wszystkie 3 zielone bez optymalizacji.

Od czego zacząć

Nie musisz od razu przepisywać całej strony. Zacznij od pomiaru, bo bez niego strzelasz na oślep. Wejdź na PageSpeed Insights albo na mój darmowy audyt, sprawdź stronę na wersji mobilnej i zobacz, która z trzech metryk świeci na czerwono. Potem idź po kolei: najpierw zdjęcia, potem skrypty, na końcu hosting. W większości przypadków sam ciężar obrazków i nadmiar dodatków odpowiada za większość problemu, więc uporządkowanie tych dwóch rzeczy daje najwięcej za najmniej pracy.

Jeśli po pomiarze zobaczysz, że problem siedzi głębiej niż w kilku obrazkach, że to platforma albo hosting ciągnie wszystko w dół, odezwij się. Zostaw numer, oddzwaniam w 24 godziny i mówię wprost, czy wystarczy kilka poprawek, czy taniej wyjdzie zbudować stronę tak, żeby była szybka od początku i nie trzeba było z nią później walczyć.