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 techniczną część przewodnika: pomiar, interpretację i poprawę jakości działania strony.

Core Web Vitals nie są konkursem na najładniejszą setkę w PageSpeed Insights. To trzy wskaźniki opisujące realne doświadczenie: kiedy pojawia się główna treść, jak szybko strona odpowiada na działanie i czy układ nie przesuwa się bez ostrzeżenia. Dla właściciela firmy sens jest prosty: osoba wchodząca z telefonu ma szybko zobaczyć ofertę, bez irytacji otworzyć menu i nie kliknąć przypadkiem w przesunięty przycisk.

Google wykorzystuje Core Web Vitals w swoich systemach rankingowych, ale wyraźnie zaznacza, że trafność treści pozostaje ważniejsza. Dobry wynik techniczny nie daje prawa do TOP 3. Usuwa za to część tarcia, które szkodzi zarówno użytkownikowi, jak i skuteczności strony.

Aktualne progi LCP, INP i CLS

Progi są takie same niezależnie od branży. Ocenę wykonuje się na 75. percentylu wizyt, osobno dla urządzeń mobilnych i komputerów. W praktyce dobry LCP na poziomie 2,5 s oznacza, że co najmniej 75% zarejestrowanych wizyt osiągnęło wynik 2,5 s lub lepszy. Pozostałe 25% mogło działać wolniej, dlatego sama zielona etykieta nie oznacza, że każdy klient miał idealne warunki.

Metryka	Dobry wynik	Wymaga poprawy	Słaby wynik
LCP	≤ 2,5 s	> 2,5 s i ≤ 4 s	> 4 s
INP	≤ 200 ms	> 200 ms i ≤ 500 ms	> 500 ms
CLS	≤ 0,1	> 0,1 i ≤ 0,25	> 0,25

Google opisuje progi i sposób oceny w oficjalnym przewodniku Web Vitals. Aby cała ocena Core Web Vitals była dobra, wszystkie trzy metryki muszą znaleźć się w zielonym zakresie. Nie wystarczy świetne LCP, jeśli formularz reaguje z opóźnieniem albo baner przesuwa treść.

Co dokładnie mierzy LCP

Largest Contentful Paint określa czas renderowania największego obrazu, bloku tekstu lub innego kwalifikującego się elementu widocznego w początkowym obszarze ekranu. Najczęściej jest nim zdjęcie hero, nagłówek albo duża grafika. Element LCP może się zmieniać w trakcie ładowania, zanim użytkownik wykona pierwszą interakcję lub opuści stronę.

Wysoki LCP nie mówi jeszcze, co zawiniło. Na wynik składają się cztery odcinki:

1. czas odpowiedzi serwera (TTFB),
2. opóźnienie przed rozpoczęciem pobierania zasobu,
3. czas pobierania zasobu,
4. opóźnienie między pobraniem a wyrenderowaniem elementu.

To ważne rozróżnienie. Kompresowanie obrazu nie pomoże wiele, jeśli przeglądarka odkrywa go późno, bo adres jest ukryty w skrypcie. Z kolei zmiana hostingu nie naprawi opóźnienia wywołanego ciężkim CSS-em. Punkt wyjścia stanowi identyfikacja konkretnego elementu i fazy, która zabiera najwięcej czasu. Szczegółową definicję podaje dokumentacja Largest Contentful Paint.

Co dokładnie mierzy INP

Interaction to Next Paint ocenia responsywność strony w czasie całej wizyty. Obejmuje kliknięcia myszą, dotknięcia ekranu oraz obsługę klawiatury. Mierzy czas od działania użytkownika do następnego wyrenderowanego obrazu i bierze pod uwagę niemal najwolniejszą interakcję, zależnie od liczby interakcji w trakcie wizyty.

INP nie jest więc „czasem pierwszego kliknięcia”. Menu może otworzyć się szybko, a późniejsze filtrowanie listy może zablokować główny wątek na sekundę — i to ta gorsza interakcja ujawni problem. Najczęstsze źródła to długie zadania JavaScript, rozbudowane funkcje obsługi zdarzeń, zbyt duży DOM, wymuszane synchronicznie przeliczenia układu i skrypty zewnętrzne.

W marcu 2024 roku INP zastąpił FID jako Core Web Vital. Jeśli starszy raport nadal stawia FID wśród trzech głównych metryk, nie opisuje obecnego sposobu oceny. Aktualną metodę wyjaśnia dokumentacja Interaction to Next Paint.

Co dokładnie mierzy CLS

Cumulative Layout Shift opisuje nieoczekiwane przesunięcia elementów podczas wizyty. Wbrew nazwie nie jest prostą sumą wszystkich ruchów od otwarcia do zamknięcia strony. Wynik opiera się na największej serii przesunięć w oknie trwającym maksymalnie pięć sekund i kończącym się po sekundzie bez kolejnego przesunięcia.

Przesunięcie wywołane bezpośrednio działaniem użytkownika, na przykład rozwinięciem sekcji po kliknięciu, może zostać potraktowane inaczej niż baner, który nagle wpada nad czytany akapit. CLS ma wychwytywać sytuacje, w których układ zaskakuje człowieka, a nie każdą celową animację. Szczegóły obliczenia opisuje materiał Cumulative Layout Shift.

CrUX i Lighthouse odpowiadają na różne pytania

W PageSpeed Insights obok siebie mogą pojawić się dwa zestawy danych. Nie należy ich mieszać.

Źródło	Co pokazuje	Do czego go użyć
CrUX, czyli dane terenowe	Zagregowane wizyty kwalifikujących się użytkowników Chrome z kroczącego okresu 28 dni	Ocena rzeczywistego doświadczenia i monitorowanie trendu
Lighthouse, czyli dane laboratoryjne	Pojedynczy test syntetyczny w kontrolowanych warunkach	Diagnoza konkretnej wersji strony i porównanie przed/po
Własny RUM	Pomiary z wizyt na stronie, jeśli wdrożysz odpowiedni skrypt	Szybsze wykrywanie regresji według podstrony, urządzenia lub wersji

PageSpeed Insights może pokazać dane CrUX oraz raport Lighthouse, ale brak danych terenowych nie oznacza wyniku zero. Często oznacza po prostu, że próbka wizyt jest za mała. Oficjalny opis narzędzia rozdziela dane terenowe od laboratoryjnych.

Lighthouse symuluje ładowanie strony. Nie obserwuje całej prawdziwej wizyty, dlatego standardowy raport ładowania nie dostarcza terenowego INP. W laboratorium warto użyć TBT jako sygnału problemów z blokowaniem głównego wątku, a konkretną interakcję zbadać w DevTools, rozszerzeniu Web Vitals lub własnym RUM. Wynik Performance jest ważoną kombinacją metryk laboratoryjnych, co dokumentuje metoda punktacji Lighthouse.

Dane dla adresu URL a dane dla całej domeny

Przed wyciągnięciem wniosku sprawdź etykietę nad wynikiem. CrUX może prezentować:

• URL — dane dla dokładnie badanego adresu,
• origin — zbiorcze dane dla protokołu, hosta i portu, zwykle całej domeny HTTPS.

Jeśli podstrona ma za mało kwalifikującego się ruchu, PageSpeed Insights może przełączyć się na dane origin. Wtedy słaby wynik nie dowodzi, że akurat badany artykuł jest wolny; problem może pochodzić z popularnego formularza albo innego szablonu. Zielony origin również nie zwalnia z testu konkretnej podstrony. Metodologia CrUX opisuje 28-dniową agregację, kryteria danych i różnicę poziomów.

Raport Core Web Vitals w Search Console pomaga ocenić skalę problemu, ale grupuje podobne adresy na podstawie danych CrUX. Nie jest precyzyjnym debuggerem każdego URL-a. Użyj go do znalezienia grupy wymagającej uwagi, a potem sprawdź reprezentatywne strony z tej grupy. Jeśli potrzebujesz szerszego punktu startu, przejdź przez bezpłatne narzędzia do audytu strony albo uruchom nasz audyt strony.

Czy Core Web Vitals wpływają na ranking

Tak, Google potwierdza ich wykorzystanie w systemach rankingowych. Nie oznacza to jednak prostego przelicznika „0,2 sekundy szybciej = dwie pozycje wyżej”. Google nie opisuje Core Web Vitals jako jednego samodzielnego sygnału Page Experience i nie obiecuje wzrostu po przekroczeniu zielonego progu.

Najpierw strona musi odpowiadać na intencję użytkownika. Potem liczą się jakość treści, jej wiarygodność, dostępność i całe doświadczenie. Technicznie świetna, ale pusta podstrona nie wyprzedzi użytecznego materiału tylko dlatego, że Lighthouse pokazał 100. Jeśli porządkujesz większy proces pozyskiwania klientów, zacznij od strategii pozycjonowania w Google, a Core Web Vitals potraktuj jako jeden z elementów jakości.

Biznesowy efekt bywa bardziej bezpośredni niż SEO. Krótsze czekanie, stabilny formularz i sprawne menu zmniejszają liczbę porzuceń. Dlatego po wdrożeniu warto obserwować nie tylko metryki techniczne, lecz także wysłania formularzy, kliknięcia telefonu i przejścia do oferty.

Diagnostyka krok po kroku

Nie zaczynaj od instalowania przypadkowej wtyczki „do szybkości”. Najpierw ustal, co i gdzie jest wolne.

1. Wybierz reprezentatywne szablony. Sprawdź stronę główną, ważną usługę, popularny wpis i stronę z formularzem. Jeden URL nie opisuje całego serwisu.
2. Zapisz dane terenowe. Zanotuj datę, urządzenie, poziom URL lub origin oraz wartości LCP, INP i CLS z 28-dniowego okna.
3. Wykonaj 3–5 testów Lighthouse. Użyj tych samych warunków i porównuj medianę, nie najlepszy pojedynczy przebieg. Ruch sieciowy i obciążenie komputera wprowadzają wahania.
4. Znajdź winny element lub interakcję. Dla LCP nazwij element i najdłuższą fazę. Dla INP nagraj powolne działanie. Dla CLS odtwórz przesunięcie, zamiast zgadywać na podstawie samej liczby.
5. Wdróż jedną grupę zmian. Oddziel poprawki obrazów od dużej przebudowy JavaScriptu. Dzięki temu wiadomo, co przyniosło efekt, a co spowodowało regresję.
6. Powtórz pomiar. Laboratorium pokaże zmianę od razu. CrUX będzie reagował stopniowo, ponieważ każdego dnia przesuwa 28-dniowe okno wizyt.

Jeżeli sama strona długo się otwiera i nie wiesz, czy problemem jest serwer, obraz czy kod, pomocna będzie osobna instrukcja: dlaczego strona ładuje się wolno.

Jak poprawić LCP

Najpierw wskaż element LCP w raporcie. Dopiero potem dobierz naprawę do najwolniejszej fazy.

• Wysoki TTFB: sprawdź cache, wydajność aplikacji i bazy danych, lokalizację serwera oraz CDN. Sam lepszy format obrazu nie skróci oczekiwania na HTML.
• Późne odkrycie zasobu: umieść ważny obraz w HTML, rozważ preload i fetchpriority="high". Obrazu LCP nie ładuj przez loading="lazy".
• Długie pobieranie: użyj właściwego rozmiaru, srcset, kompresji i nowoczesnego formatu. Nie wysyłaj telefonu zdjęcia 4000 px, jeśli wyświetla je w szerokości 720 px.
• Opóźniony render: ogranicz blokujący CSS i JavaScript, uporządkuj ładowanie fontów i nie ukrywaj gotowej treści do zakończenia animacji.

Największy plik nie zawsze jest elementem LCP, a usunięcie każdego kilobajta nie ma tej samej wartości. Priorytetem jest zasób potrzebny w pierwszym ekranie.

Jak poprawić INP

INP poprawia się przez skrócenie pracy wykonywanej między działaniem człowieka a następną klatką obrazu.

• nagraj powolne kliknięcie w panelu Performance i znajdź długie zadania,
• uprość funkcje obsługi zdarzeń i przetwarzaj tylko dane potrzebne do pierwszej odpowiedzi,
• dziel długą pracę na mniejsze fragmenty, aby przeglądarka mogła wyrenderować zmianę,
• ładuj kod tylko tam, gdzie jest potrzebny, i ogranicz skrypty reklamowe, czaty oraz trackery,
• unikaj naprzemiennego odczytu i zapisu wymiarów elementów, który wymusza kosztowne przeliczenia układu,
• zmniejsz nadmiernie rozbudowany DOM,
• przenieś obliczenia niezwiązane z DOM do Web Workera, jeśli rzeczywiście obciążają główny wątek,
• pokaż natychmiastowe potwierdzenie działania, na przykład stan ładowania przycisku.

Nie usuwaj analityki w ciemno. Sprawdź koszt konkretnego skryptu i jego wartość biznesową. Czasem wystarczy uruchomić narzędzie po zgodzie lub po pierwszej interakcji; czasem problemem jest własny kod formularza.

Jak poprawić CLS

W przypadku CLS najczęściej trzeba zarezerwować miejsce, zanim treść się pojawi.

• podawaj width i height albo aspect-ratio dla obrazów, filmów i ramek,
• rezerwuj stałe lub minimalne miejsce na mapy, reklamy, formularze i widgety,
• nie wstrzykuj banera nad czytany tekst, jeśli nie jest bezpośrednią odpowiedzią na działanie użytkownika,
• stabilizuj fonty: ładuj potrzebne kroje wcześnie i dobierz metrycznie zbliżony font zastępczy,
• animuj transform i opacity, zamiast właściwości zmieniających układ,
• przetestuj pasek zgody, czat oraz komunikaty walidacji na małym ekranie.

Sam font-display nie rozwiązuje automatycznie przesunięć. Jeśli krój zastępczy ma inne proporcje, tekst może zmienić liczbę wierszy po załadowaniu fontu. Potrzebny jest dobór fallbacku i test rzeczywistego układu.

Plan pomiaru przed i po wdrożeniu

Bez zapisu stanu początkowego łatwo ogłosić sukces na podstawie jednego szczęśliwego testu. Prosty arkusz może wyglądać tak:

Etap	Co zapisujesz	Kiedy
Przed zmianą	CrUX: URL/origin, mobile/desktop, data, LCP, INP, CLS	Przed wdrożeniem
Punkt laboratoryjny	Mediana 3–5 testów Lighthouse i wskazane problemy	Przed wdrożeniem
Kontrola techniczna	Te same testy, urządzenie, warunki i adres	Tuż po wdrożeniu
Kontrola użytkowników	Własny RUM i błędy w kluczowych interakcjach	Od chwili wdrożenia
Ocena terenowa	CrUX i raport Search Console	W kolejnych dniach i po pełnym 28-dniowym oknie
Efekt biznesowy	Konwersje, formularze, telefony, porzucenia	W porównywalnym okresie

Porównuj tę samą wersję adresu, bez różnic typu parametr kampanii, zalogowany panel czy włączone rozszerzenia. Jeśli zmieniłeś kilka rzeczy naraz, zanotuj je. Dzięki temu kolejna optymalizacja nie zaczyna się od zera.

WordPress i strona statyczna: platforma nie daje gwarancji

WordPress nie musi być wolny, a statyczny HTML nie musi być szybki. Lekki motyw, dobry cache i rozsądna liczba dodatków mogą zapewnić bardzo dobre wyniki. Z drugiej strony strona statyczna z wielkim filmem hero, czterema trackerami i ciężkim JavaScriptem może oblać każdą metrykę.

Architektura statyczna usuwa część ryzyka po stronie serwera i zwykle ułatwia dostarczenie prostego HTML-a. Nie daje jednak zielonych wyników „z pudełka”. Jeśli rozważasz technologiczną zmianę, porównaj WordPress i stronę statyczną pod kątem sposobu edycji, utrzymania i funkcji, a nie tylko jednego testu. Migracja z WordPressa do statycznej strony ma sens wtedy, gdy rozwiązuje szerszy problem kosztu lub złożoności — nie jako automatyczna recepta na Lighthouse 100.

Często zadawane pytania

Co to są Core Web Vitals?

Core Web Vitals to trzy metryki jakości korzystania ze strony: LCP opisuje szybkość wyświetlenia głównej treści, INP responsywność podczas interakcji, a CLS stabilność układu. Google zaleca ocenę 75. percentyla wizyt, osobno dla urządzeń mobilnych i komputerów.

Jakie progi Core Web Vitals obowiązują w 2026 roku?

Dobry wynik to LCP nie większy niż 2,5 s, INP nie większy niż 200 ms i CLS nie większy niż 0,1. Zakres wymagający poprawy wynosi odpowiednio: LCP powyżej 2,5 do 4 s, INP powyżej 200 do 500 ms i CLS powyżej 0,1 do 0,25. Powyżej górnej granicy wynik jest słaby.

Czy wynik 100 w Lighthouse oznacza zaliczone Core Web Vitals?

Nie. Lighthouse wykonuje syntetyczny test w określonych warunkach i pomaga znaleźć przyczyny problemów. Ocena Core Web Vitals opiera się na danych terenowych CrUX z rzeczywistych wizyt z ostatnich 28 dni, o ile dla adresu lub domeny jest ich wystarczająco dużo.

Dlaczego PageSpeed Insights pokazuje dane dla domeny zamiast adresu URL?

Dla konkretnego adresu może brakować wystarczającej liczby kwalifikujących się wizyt w CrUX. PageSpeed Insights może wtedy pokazać dane origin, czyli zbiorcze wyniki całej domeny. Nie dowodzą one, że badany adres ma dokładnie taki sam wynik.

Czy Core Web Vitals wpływają na pozycję w Google?

Google wykorzystuje Core Web Vitals w systemach rankingowych, ale trafność treści pozostaje najważniejsza. Dobre wyniki nie gwarantują wysokiej pozycji, a wynik Lighthouse 100 nie jest samodzielnym celem SEO.

Jak sprawdzić, czy poprawki rzeczywiście zadziałały?

Przed wdrożeniem zapisz dane CrUX i medianę z kilku testów Lighthouse w tych samych warunkach. Po zmianie powtórz testy laboratoryjne, obserwuj własne dane RUM, a następnie poczekaj, aż 28-dniowe okno CrUX stopniowo uwzględni nowe wizyty.

Co zrobić teraz

Wybierz trzy podstrony reprezentujące najważniejsze szablony i zapisz punkt wyjścia. Jeśli problem dotyczy jednej metryki, napraw ją według przyczyny, nie według ogólnej listy „przyspieszaczy”. Gdy kilka typów stron ma ten sam błąd, popraw komponent lub szablon raz, zamiast łatać każdy adres osobno.

Jeśli potrzebujesz pomocy w oddzieleniu problemu treści, serwera i kodu, zacznij od audytu. Dostaniesz listę zmian w kolejności wpływu, bez obietnic pozycji i bez gonienia za wynikiem 100 dla samego wyniku.