Core Web Vitals — Jak Poprawić LCP, INP, CLS

Core Web Vitals to trzy liczby, które decydują, czy użytkownik zostanie na Twojej stronie, czy ucieknie po dwóch sekundach. LCP, INP i CLS mierzą realne doświadczenie ładowania, responsywności i stabilności — a Google używa ich jako czynnika rankingowego. W tym przewodniku pokazuję krok po kroku, jak zdiagnozować i poprawić każdą z tych metryk, bez owijania w teorię. To wiedza, którą wdrażam w każdej optymalizacji SEO — uporządkowana tak, byś wiedział, co naprawić najpierw i ile to da.

Czym są Core Web Vitals i jakie są progi

Core Web Vitals to trzy metryki, którymi Google sprowadza abstrakcyjne pojęcie „szybkości strony” do konkretnych, mierzalnych liczb. Każda opisuje inny moment frustracji użytkownika: jak długo czeka na treść, jak szybko strona reaguje na jego kliknięcie i czy układ nie „ucieka” mu spod palca. To nie są wskaźniki techniczne dla samej techniki — to bezpośrednie odwzorowanie tego, jak człowiek odbiera Twoją stronę przez pierwsze sekundy kontaktu.

LCP (Largest Contentful Paint) mierzy, jak szybko renderuje się największy widoczny element w obszarze ekranu — zwykle główny obraz, baner hero lub blok tekstu. To wskaźnik postrzeganej szybkości ładowania: użytkownik uznaje stronę za „gotową”, gdy zobaczy główną treść. Próg dobry to poniżej 2,5 sekundy, wymagający poprawy to 2,5–4 s, a słaby to wszystko powyżej 4 s.

INP (Interaction to Next Paint) zastąpił dawne FID i mierzy responsywność strony — opóźnienie między akcją użytkownika (kliknięcie, dotyk, wciśnięcie klawisza) a wizualną odpowiedzią interfejsu. INP bierze pod uwagę wszystkie interakcje w trakcie wizyty, nie tylko pierwszą, więc jest znacznie surowszy niż jego poprzednik. Próg dobry to poniżej 200 milisekund, a powyżej 500 ms strona sprawia wrażenie zawieszonej.

CLS (Cumulative Layout Shift) ocenia stabilność wizualną — sumuje nieoczekiwane przeskoki układu podczas ładowania. Klasyczny przykład: chcesz kliknąć przycisk, a w tym momencie doładowuje się reklama lub obraz bez zarezerwowanego miejsca i przycisk przeskakuje, przez co klikasz coś innego. Próg dobry to poniżej 0,1 (wartość bezwymiarowa), wymagający poprawy do 0,25, a powyżej tej granicy układ jest wyraźnie niestabilny.

Najważniejsza rzecz, którą trzeba zrozumieć o progach: Google ocenia 75. percentyl, nie średnią. Oznacza to, że trzy czwarte Twoich realnych użytkowników musi mieścić się w progu, by metryka została zaliczona jako „dobra”. Pojedynczy świetny wynik na Twoim szybkim laptopie i światłowodzie nic nie znaczy, jeśli większość odwiedzających korzysta ze średniej klasy telefonu na zatłoczonym LTE. To dlatego pomiar na realnym ruchu jest jedyną wiarygodną miarą — i dlaczego porządkowanie Core Web Vitals jest stałym elementem mojego audytu SEO.

Jak mierzyć Core Web Vitals — lab vs field

Najczęstszy błąd, jaki widzę, to mylenie danych laboratoryjnych z danymi z pola. To dwa różne światy, które mierzą co innego i służą do czego innego. Dane laboratoryjne (lab) to symulacja w kontrolowanym środowisku: stałe łącze, zdefiniowane urządzenie, pojedyncze załadowanie strony. Dane z pola (field) to anonimowe pomiary zbierane od realnych użytkowników przeglądarki Chrome, agregowane przez 28 dni w bazie CrUX (Chrome User Experience Report). Do oceny rankingu Google używa wyłącznie danych z pola.

PageSpeed Insights to narzędzie, od którego warto zacząć, bo pokazuje obie warstwy naraz. Na górze raportu znajdziesz dane z pola (jeśli strona ma wystarczający ruch w CrUX) — to werdykt, który liczy się dla SEO. Niżej raport Lighthouse z danymi laboratoryjnymi i listą konkretnych rekomendacji. Kluczowa zasada: pole mówi „czy masz problem”, laboratorium mówi „dlaczego”. Optymalizujesz, patrząc na lab, a weryfikujesz efekt, czekając na aktualizację field.

INP i CLS bywają niewidoczne w laboratorium, bo zależą od zachowania użytkownika — od tego, w co kliknie i jak długo zostanie. Dlatego do tych metryk szczególnie potrzebujesz danych z pola lub monitoringu w czasie rzeczywistym. Google Search Console ma osobny raport „Core Web Vitals” oparty na CrUX, który grupuje adresy w problematyczne wzorce — to świetny punkt startu, by zobaczyć skalę problemu na całym serwisie naraz, a nie tylko na jednej podstronie. Pełniejszy obraz technicznych pomiarów łączę zawsze z analizą indeksacji i crawl budżetu, bo wolny serwer psuje jedno i drugie.

Dlaczego wyniki wypadają słabo — najczęstsze przyczyny

Złe Core Web Vitals niemal zawsze sprowadzają się do kilku powtarzalnych winowajców. Po setkach przeanalizowanych stron mogę powiedzieć, że nie chodzi o egzotyczne błędy — chodzi o te same grzechy popełniane wciąż od nowa. Słaby LCP to zwykle nieoptymalizowany, gigantyczny obraz hero ładowany z lazy-loadingiem, wolna odpowiedź serwera lub render blokowany przez ciężki CSS i JavaScript wczytywany synchronicznie w sekcji head dokumentu.

Słaby INP to przede wszystkim nadmiar JavaScriptu wykonywanego na wątku głównym. Gdy przeglądarka jest zajęta przetwarzaniem skryptów, nie może zareagować na kliknięcie użytkownika — stąd opóźnienie. Najczęstsze źródła to ciężkie biblioteki frontendowe, długie zadania (long tasks) trwające ponad 50 ms oraz lawina skryptów firm trzecich, które konkurują o ten sam wątek. Im więcej kodu wykonuje się przy starcie, tym dłużej strona „nie słucha” użytkownika.

Wysoki CLS to klasycznie brak rezerwacji miejsca na elementy, które doładowują się asynchronicznie. Obrazy bez atrybutów width i height, reklamy wstawiane dynamicznie, banery cookie wskakujące na górę strony, czcionki webowe powodujące przerysowanie tekstu (efekt FOUT/FOIT) oraz treść wstrzykiwana przez skrypty po załadowaniu — każde z tych zjawisk przesuwa już widoczne elementy i nabija punkty CLS. Te przyczyny rozłożę teraz na czynniki pierwsze, metryka po metryce.

Optymalizacja LCP — obrazy, serwer, preload

LCP to suma trzech składników: czasu odpowiedzi serwera, czasu pobrania zasobu i czasu jego renderowania. Zanim zaczniesz cokolwiek poprawiać, sprawdź w PageSpeed, który element jest tym „largest contentful” i który z trzech składników dominuje — bez tego strzelasz na ślepo. Najczęściej winowajcą jest obraz, ale czasem to wolny backend albo czcionka blokująca render tekstu hero.

Pierwszy krok to optymalizacja obrazu LCP. Skonwertuj go do nowoczesnego formatu (WebP lub AVIF), podaj dokładne wymiary, dobierz właściwy rozmiar pod urządzenie przez atrybut srcset i — co kluczowe — nigdy nie ładuj obrazu LCP z lazy-loadingiem. Lazy-loading jest świetny dla zasobów poniżej zgięcia, ale zastosowany do głównego obrazu opóźnia jego pobranie i wprost rujnuje LCP. Zamiast tego dodaj dla niego preload, by przeglądarka zaczęła go pobierać natychmiast, z najwyższym priorytetem.

Drugi front to serwer i czas do pierwszego bajtu (TTFB). Jeśli serwer odpowiada wolno, żaden trik z obrazami nie pomoże, bo cały łańcuch startuje z opóźnieniem. Celuj w TTFB poniżej 600 ms. Pomaga tu: dobry hosting, cache po stronie serwera (treść generowana raz, serwowana wielokrotnie), CDN przybliżający zasoby do użytkownika geograficznie oraz eliminacja zbędnych zapytań do bazy danych. W sklepach internetowych ten obszar jest szczególnie wrażliwy — dlatego wydajność serwera to stały punkt mojego przewodnika po pozycjonowaniu sklepu.

Trzeci element to eliminacja zasobów blokujących render. CSS i JavaScript wczytywane synchronicznie w head zatrzymują wyświetlanie strony, dopóki się nie pobiorą i nie przetworzą. Rozwiązanie to: wydzielenie krytycznego CSS (tego potrzebnego do pierwszego ekranu) i wczytanie reszty asynchronicznie, odroczenie nieistotnego JavaScriptu atrybutami defer lub async oraz minimalizacja i kompresja wszystkich zasobów tekstowych. Każdy zaoszczędzony tu milisekundowy fragment przekłada się bezpośrednio na niższy LCP.

Optymalizacja INP — JavaScript i długie zadania

INP to metryka, która najtrudniej poddaje się prostym poprawkom, bo wymaga ograniczenia tego, co robi JavaScript. Sedno problemu jest jedno: wątek główny przeglądarki obsługuje zarówno wykonywanie skryptów, jak i reagowanie na interakcje użytkownika. Gdy skrypt zajmuje wątek na 300 ms, przez te 300 ms strona nie odpowie na żadne kliknięcie. Twoim celem jest skrócenie i rozproszenie tej pracy tak, by wątek był jak najczęściej wolny.

Pierwsza linia ataku to długie zadania — bloki kodu trwające ponad 50 ms. Każde takie zadanie to okno, w którym strona jest „głucha”. Rozwiązanie to dzielenie ciężkich operacji na mniejsze fragmenty (technika yielding — oddawanie kontroli do przeglądarki między fragmentami), przenoszenie obliczeniowo ciężkich zadań do web workerów (osobny wątek, nie blokuje interfejsu) oraz odraczanie pracy, która nie musi wykonać się natychmiast przy starcie. Im krótsze pojedyncze zadania, tym częściej strona może zareagować na użytkownika.

Druga linia to redukcja samej ilości JavaScriptu. Mniej kodu to mniej pracy dla wątku głównego — to brutalnie proste. Usuwaj nieużywane biblioteki i martwy kod (tree shaking), dziel paczki JS i ładuj je dopiero, gdy są potrzebne (code splitting, lazy loading komponentów), a interaktywność dla elementów drugorzędnych odraczaj do momentu, gdy użytkownik się do nich zbliży. Świadome zarządzanie hydratacją to temat blisko związany z renderowaniem, który rozwijam w przewodniku o JavaScript SEO i renderowaniu.

Trzecia linia to skrypty firm trzecich — najczęstszy zabójca INP, którego właściciele stron nie zauważają. Każdy widżet czatu, każdy piksel reklamowy, każdy menedżer tagów dokłada swoją porcję pracy na wątku głównym. Audytuj je bezlitośnie: ładuj asynchronicznie, opóźniaj ich start do pierwszej interakcji użytkownika i usuwaj wszystko, co nie przynosi mierzalnej wartości. Jedna nadmiarowa biblioteka analityczna potrafi sama zepsuć INP całego serwisu.

Optymalizacja CLS — wymiary i czcionki

CLS jest paradoksalnie najłatwiejszą metryką do naprawienia, bo jej przyczyny są mechaniczne i przewidywalne. Zasada nadrzędna brzmi: każdy element, który zajmie miejsce na stronie, musi mieć to miejsce zarezerwowane zanim się załaduje. Jeśli przeglądarka wie z góry, ile miejsca zajmie obraz, reklama czy ramka wideo, nie będzie musiała przesuwać sąsiednich elementów, gdy zasób w końcu dotrze.

Najczęstszy winowajca to obrazy i elementy osadzone bez podanych wymiarów. Zawsze deklaruj atrybuty width i height (lub odpowiednik w CSS rezerwujący proporcje) dla każdego obrazu, wideo, iframe i osadzonego widżetu. Przeglądarka policzy wtedy proporcje i zostawi puste miejsce o właściwym rozmiarze, zamiast „dopychać” treść w momencie ładowania. To jedna z tych poprawek, które kosztują kilka minut, a likwidują większość punktów CLS na typowej stronie.

Drugi częsty problem to czcionki webowe i efekt przerysowania tekstu. Gdy strona ładuje się z czcionką zastępczą, a potem podmienia ją na docelową, tekst może zmienić rozmiar i przesunąć cały układ (FOUT — Flash of Unstyled Text). Rozwiązanie to: użycie deskryptora font-display: swap z dopasowaną czcionką zastępczą o zbliżonych metrykach, preload kluczowych plików czcionek oraz, gdy to możliwe, ograniczenie liczby krojów i wariantów do niezbędnego minimum.

Trzecie źródło CLS to treści wstawiane dynamicznie nad już widocznym contentem. Banery cookie, paski powiadomień, reklamy doładowywane asynchronicznie czy komunikaty wskakujące na górę strony — wszystko, co pojawia się ponad tym, co użytkownik już widzi, spycha resztę w dół i nabija CLS. Dla takich elementów zawsze rezerwuj miejsce z góry albo umieszczaj je w sposób, który nie przesuwa istniejącej treści (np. nakładka zamiast wypychania układu).

Obrazy — WebP, AVIF i lazy-loading w praktyce

Obrazy to zwykle najcięższy element strony i najprostsze źródło dużych zysków wydajnościowych. Większość serwisów, które audytuję, serwuje obrazy w przestarzałym formacie JPG lub PNG, w rozdzielczości znacznie większej niż potrzebna, bez kompresji. Sama konwersja biblioteki obrazów do nowoczesnych formatów potrafi obciąć wagę strony o połowę i wprost przełożyć się na lepsze LCP.

WebP i AVIF to dziś standard, który powinieneś przyjąć. WebP daje typowo 25–35% mniejszą wagę niż JPG przy zachowaniu jakości i jest wspierany praktycznie wszędzie. AVIF idzie jeszcze dalej — bywa o 50% lżejszy — ale wymaga sprawdzenia wsparcia i fallbacku. Praktyka, którą stosuję: serwuj AVIF z fallbackiem do WebP i dalej do JPG przez element picture, dzięki czemu każda przeglądarka dostaje najlżejszy format, jaki obsługuje.

Lazy-loading to potężne narzędzie, ale tylko wtedy, gdy używasz go z głową. Reguła jest prosta i wynika wprost z mechaniki LCP: obrazy poniżej zgięcia (poza pierwszym ekranem) ładuj leniwie atrybutem loading="lazy", a obrazy w pierwszym ekranie — zwłaszcza ten będący elementem LCP — ładuj zawsze od razu, najlepiej z preloadem. Globalne „lazy na wszystkim”, które wciąż widuję we wtyczkach optymalizacyjnych, to najczęstsza przyczyna paradoksalnie gorszego LCP po „optymalizacji”. Mądry dobór tego, co leniwe, a co priorytetowe, to fundament szybkiej strony.

Skrypty firm trzecich, hosting i cache

Skrypty zewnętrzne to obszar, w którym najłatwiej stracić kontrolę nad wydajnością. Każdy dział marketingu chce dołożyć swój piksel, swoje narzędzie do nagrywania sesji, swój czat i swój widżet opinii — a każdy z nich pobiera własny kod, wykonuje go na wątku głównym i często wstawia treść do strony. Efekt kumuluje się po cichu, aż pewnego dnia INP i CLS lecą na łeb. Mój standard to regularny audyt: lista wszystkich skryptów zewnętrznych, ocena realnej wartości każdego i bezwzględne usuwanie tych bez mierzalnego zwrotu.

Techniki, które ratują wydajność przy skryptach trzecich, to ładowanie asynchroniczne i odraczanie do interakcji. Menedżery tagów konfiguruj tak, by ciężkie narzędzia uruchamiały się dopiero, gdy użytkownik wejdzie w interakcję ze stroną, a nie natychmiast przy starcie. Czat czy widżet opinii możesz wczytywać dopiero po przewinięciu lub kliknięciu. Każdy skrypt, którego start odroczysz poza ścieżkę krytyczną, to czystszy wątek główny i lepsze INP w pierwszych, najważniejszych sekundach wizyty.

Hosting i cache to fundament, na którym stoi cała reszta — i obszar najczęściej niedoceniany. Najlepiej zoptymalizowany frontend nie pomoże, jeśli serwer odpowiada w sekundę. Dobry hosting dopasowany do ruchu, cache po stronie serwera (strona generowana raz i serwowana wielokrotnie), kompresja transferu (Brotli lub Gzip) oraz CDN przybliżający zasoby do użytkownika geograficznie — to zestaw, który skraca TTFB i przyspiesza dostarczenie każdego zasobu. W połączeniu z poprawnymi nagłówkami cache dla zasobów statycznych (obrazy, CSS, JS) potrafi to przyspieszyć powracające wizyty wielokrotnie.

Monitoring — jak nie cofnąć się po wdrożeniu

Najboleśniejszy scenariusz w pracy nad Core Web Vitals to spektakularna poprawa, która po dwóch tygodniach cicho znika. Strona to żywy organizm: nowa wtyczka, dodany skrypt marketingowy, podmieniony baner czy aktualizacja motywu potrafią jednym wdrożeniem cofnąć całą wykonaną pracę. Dlatego monitoring nie jest dodatkiem — jest warunkiem, by zysk był trwały. Bez ciągłego pomiaru optymalizujesz raz, a regresji nawet nie zauważysz, dopóki nie spadną pozycje.

Praktyczny zestaw monitoringu opieram na trzech poziomach. Pierwszy to dane z pola w Google Search Console — raport Core Web Vitals pokazuje trend na całym serwisie i grupuje problematyczne wzorce adresów. Drugi to monitoring w czasie rzeczywistym (RUM — Real User Monitoring), który zbiera metryki od Twoich faktycznych użytkowników na bieżąco, bez 28-dniowego opóźnienia CrUX. Trzeci to testy w pipeline wdrożeniowym, które sprawdzają budżet wydajności jeszcze przed publikacją zmiany, zanim zdąży zepsuć produkcję.

Reguła, którą wpajam każdemu zespołowi: po każdym większym wdrożeniu sprawdzaj Core Web Vitals tak samo rutynowo, jak sprawdzasz, czy strona w ogóle działa. Dziesięć minut weryfikacji po deployu oszczędza tygodnie zastanawiania się, dlaczego ruch spadł. Możesz też zacząć od szybkiego, darmowego sprawdzenia stanu swojej strony w moich narzędziach SEO — to dobry punkt wyjścia, by zobaczyć, gdzie jesteś dzisiaj.

Proces optymalizacji Core Web Vitals krok po kroku

Optymalizację prowadzę zawsze w stałej kolejności, bo to ona decyduje o tym, czy praca daje efekt, czy rozpływa się w detalach. Poniższa sekwencja prowadzi od diagnozy do trwałego wyniku — to ten sam schemat, który stosuję w realnych projektach i którym domykam techniczną warstwę opisaną szerzej w przewodniku po technicznym SEO.

1. Pomiar startowy. Zbierz dane z pola (Search Console, PageSpeed) dla kluczowych szablonów stron — strona główna, kategoria, produkt, artykuł. To Twój punkt odniesienia.
2. Diagnoza per metryka. Dla każdego szablonu ustal, która metryka jest słaba i co konkretnie ją psuje (element LCP, długie zadania, źródła przeskoków).
3. Priorytetyzacja. Zacznij od poprawek o najwyższym stosunku efektu do nakładu — zwykle obraz LCP, wymiary obrazów i najcięższe skrypty trzecie.
4. Wdrożenie LCP. Format i preload obrazu, TTFB serwera, eliminacja zasobów blokujących render.
5. Wdrożenie INP. Redukcja i odroczenie JavaScriptu, dzielenie długich zadań, ujarzmienie skryptów trzecich.
6. Wdrożenie CLS. Wymiary wszystkich elementów, czcionki ze swap i preloadem, rezerwacja miejsca dla treści dynamicznych.
7. Weryfikacja w polu. Po wdrożeniu czekaj na aktualizację danych z pola — to one są werdyktem, nie wynik lab tuż po zmianie.
8. Monitoring ciągły. Włącz stały pomiar i sprawdzaj Core Web Vitals po każdym większym wdrożeniu, by nie cofnąć efektu.

Podsumowanie

Core Web Vitals to nie egzotyczna technikalia, lecz bezpośrednia miara tego, jak Twoja strona traktuje użytkownika — i jak traktuje ją za to Google. LCP mówi, jak szybko widzi treść, INP — jak szybko strona reaguje, a CLS — czy może jej zaufać, że nic mu nie ucieknie spod palca. Poprawa tych trzech liczb to nie polowanie na punkty w teście, lecz realne podniesienie jakości doświadczenia, które przekłada się jednocześnie na ranking i na konwersję.

Jeśli masz zacząć od jednej rzeczy, zacznij od obrazu LCP i wymiarów obrazów — to najtańsze zyski, jakie istnieją w tej dziedzinie. Potem zabierz się za skrypty firm trzecich, bo to one najczęściej psują INP i CLS naraz. A całość spnij ciągłym monitoringiem, żeby praca nie cofnęła się po pierwszym lepszym wdrożeniu. Potrzebujesz pełnej diagnozy i wdrożenia? Napisz do mnie przez formularz kontaktowy, a o moim doświadczeniu przeczytasz na stronie o autorze.