Jak poprawić Core Web Vitals? LCP, INP i CLS krok po kroku

Core Web Vitals to trzy mierzalne metryki: LCP (2,5 s), INP (200 ms) i CLS (0,1). LCP poprawia kompresja obrazów do WebP/AVIF, preload zasobu hero i szybszy TTFB serwera. INP poprawia redukcja JavaScriptu na głównym wątku, code splitting i skracanie zadań powyżej 50 ms. CLS naprawia rezerwacja miejsca na obrazy (width/height, aspect-ratio) i font-display: swap. Wdrożenie tych technik podnosi wynik z „wymaga poprawy” do „dobry” zwykle w 2-6 tygodni, bez zmiany silnika strony.

Czym są Core Web Vitals i jakie progi trzeba osiągnąć?

Core Web Vitals to trzy metryki Google mierzące realne wrażenia użytkownika podczas ładowania i obsługi strony: LCP, INP i CLS, z progiem „dobry” liczonym na poziomie 75. percentyla wizyt w danym okresie.

LCP (Largest Contentful Paint) mierzy, jak szybko pojawia się największy widoczny element – zdjęcie hero, nagłówek albo blok wideo. INP (Interaction to Next Paint) mierzy czas między kliknięciem albo wpisem w formularzu a reakcją przeglądarki. CLS (Cumulative Layout Shift) liczy, o ile treść przesuwa się po wyrenderowaniu, np. gdy przycisk „Kup teraz” ucieka w dół, bo nad nim doładował się baner.

• LCP: dobry ≤ 2,5 s, wymaga poprawy 2,5-4,0 s, słaby > 4,0 s.
• INP: dobry ≤ 200 ms, wymaga poprawy 200-500 ms, słaby > 500 ms.
• CLS: dobry ≤ 0,1, wymaga poprawy 0,1-0,25, słaby > 0,25.

Dane pochodzą z dwóch źródeł: pomiaru w terenie (Chrome User Experience Report, widoczny w Search Console i PageSpeed Insights) oraz pomiaru laboratoryjnego (Lighthouse, WebPageTest), który symuluje warunki, ale nie zastępuje danych z realnych przeglądarek. Więcej wpisów o wydajności stron znajdziesz w kategorii bezpieczeństwo i wydajność bazy wiedzy Craftis.

Poprawa każdej z trzech metryk wymaga innego zestawu działań technicznych – dalsza część tekstu rozbija je osobno dla LCP, INP i CLS.

Jak poprawić LCP na stronie?

LCP poprawia się przez skrócenie czasu, w jakim przeglądarka pobiera, dekoduje i renderuje największy widoczny element strony – w praktyce niemal zawsze obraz hero, duży nagłówek albo sekcję wideo.

Ładowanie LCP rozkłada się na cztery etapy: odpowiedź serwera, start pobierania zasobu, pobieranie i renderowanie. Największy skok wyniku daje zwykle połączenie kompresji obrazu z priorytetowym ładowaniem, nie pojedyncza zmiana.

Kompresja i nowoczesne formaty obrazów

Zdjęcie hero w WebP zamiast JPEG waży zwykle o 25-35% mniej przy tej samej jakości, a AVIF potrafi zejść nawet o 50% poniżej wagi oryginału – zdjęcie 800 KB spada do 400-520 KB w WebP albo 350-400 KB w AVIF.

WebP czy AVIF – który format wybrać?

WebP obsługują wszystkie aktualne przeglądarki i koduje się szybciej, co ma znaczenie przy generowaniu obrazów w locie. AVIF daje niższą wagę pliku, ale kodowanie trwa 3-5 razy dłużej i część starszych przeglądarek mobilnych nadal go nie wspiera w pełni. Rozsądny kompromis: AVIF z fallbackiem do WebP przez znacznik <picture>.

Priorytetowe ładowanie elementu LCP (preload i fetchpriority)

Element odpowiedzialny za LCP powinien mieć <link rel="preload" as="image" href="..."> w head oraz atrybut fetchpriority="high" na tagu <img> – przeglądarka pobiera wtedy ten zasób w pierwszej kolejności. Przy audycie sklepu z branży wnętrzarskiej sam preload zdjęcia hero skrócił LCP z 3,8 s do 2,6 s.

Eliminacja zasobów blokujących renderowanie

CSS i JS ładowane synchronicznie w head wstrzymują renderowanie do czasu ich pobrania. Krytyczny CSS (style widocznego obszaru) warto wstawić inline w head, resztę doładować asynchronicznie atrybutem media="print" onload="this.media='all'". Skrypty zbędne przy pierwszym renderowaniu powinny mieć atrybut defer albo async.

Skrócenie czasu odpowiedzi serwera (TTFB)

Google traktuje TTFB poniżej 600 ms jako wartość dobrą dla LCP – powyżej tego progu nawet zoptymalizowany frontend nie osiągnie 2,5 s. Cache stron, OPcache PHP, indeksy na często odpytywanych kolumnach bazy i serwer bliski geograficznie odbiorcom zwykle obniżają TTFB z 900-1200 ms do 250-450 ms.

Odłożone ładowanie obrazów poza pierwszym ekranem

loading="lazy" warto ustawiać wyłącznie na obrazach poniżej pierwszego ekranu – nigdy na elemencie LCP, bo lazy loading opóźnia jego pobranie. Odwrócenie tej zasady (lazy na hero, preload na obrazku w stopce) to częsty błąd ręcznej optymalizacji.

Skuteczna poprawa LCP łączy zwykle 3-4 z powyższych technik naraz – sama kompresja obrazu rzadko przesuwa wynik z „słaby” na „dobry”.

Jak poprawić INP na stronie?

INP poprawia się przez skrócenie czasu, w jakim główny wątek przeglądarki jest zajęty JavaScriptem, żeby zdążył zareagować na kliknięcie, dotknięcie ekranu albo wpis w formularzu w czasie poniżej 200 ms.

Metryka zastąpiła w marcu 2024 roku First Input Delay, bo FID mierzył opóźnienie tylko pierwszej interakcji – strona może mieć dobry FID i słaby INP, jeśli zawiesza się przy kolejnych kliknięciach.

Redukcja i dzielenie kodu JavaScript (code splitting)

Ładowanie całego bundla JS na starcie, nawet gdy 80% kodu obsługuje funkcje niepotrzebne na danej podstronie, zajmuje główny wątek na czas jego wykonania. Podział bundla na części ładowane na żądanie (dynamic import, code splitting na poziomie widoków) zmniejsza ilość JS wykonywanego na starcie o 40-60%.

Skracanie długich zadań (long tasks) powyżej 50 ms

Zadanie JS trwające dłużej niż 50 ms na głównym wątku blokuje reakcję na interakcję użytkownika – Chrome DevTools w panelu Performance oznacza takie fragmenty czerwonym paskiem. Rozbicie długiej funkcji na mniejsze części, przez setTimeout z opóźnieniem 0 albo scheduler.yield(), pozwala wcisnąć obsługę kliknięcia między fragmenty obliczeń.

Ograniczenie skryptów firm trzecich

Widżety czatu, piksele reklamowe i zewnętrzne narzędzia analityczne doładowują własny JavaScript konkurujący o główny wątek z kodem strony. Audyt w Chrome DevTools (zakładka Performance, sekcja Third-party) pokazujący ponad 200 ms blokady to sygnał do usunięcia zbędnych narzędzi albo przeniesienia ich ładowania na moment po interakcji, np. po scrollu.

Debouncing i throttling obsługi zdarzeń

Nasłuchiwacze scroll, resize czy input wykonujące kosztowne operacje przy każdym wywołaniu warto ograniczyć techniką debounce (wykonanie po zakończeniu serii zdarzeń) albo throttle (maksymalnie raz na interwał, np. 100 ms). Pole wyszukiwania odpytujące API przy każdym naciśnięciu klawisza zamiast co 300 ms to częsta przyczyna skoków INP.

Web Workers dla obliczeń w tle

Operacje niewymagające dostępu do DOM – przetwarzanie danych, filtrowanie długich list, generowanie miniatur po stronie klienta – da się przenieść do Web Workera, osobnego wątku działającego równolegle z głównym. Panel filtrów produktowych po takiej zmianie i podziale bundla JS obniżył medianę INP z 340 ms do 160 ms w miesiąc.

Jak poprawić CLS na stronie?

CLS poprawia się przez rezerwację miejsca dla każdego elementu strony, zanim jego treść się załaduje, żeby przeglądarka nie przesuwała już wyrenderowanej zawartości.

Wynik CLS to iloczyn frakcji przesunięcia i odległości przesunięcia w pikselach – im większy i częstszy skok układu, tym gorsze wrażenie, zwłaszcza na mobile, gdzie ekran jest mniejszy.

Rezerwacja miejsca na obrazy i wideo

Każdy tag <img> i <video> powinien mieć atrybuty width i height albo CSS aspect-ratio, żeby przeglądarka zarezerwowała przestrzeń przed pobraniem pliku. Brak tych atrybutów to najczęstsza pojedyncza przyczyna wysokiego CLS na galeriach i blogach – pusty box o wysokości 0 rozszerza się nagle po dociągnięciu obrazu.

Stabilizacja czcionek (font-display i preload)

Czcionki webowe bez odpowiedniej konfiguracji dają efekt FOIT lub FOUT – tekst renderuje się czcionką systemową, a po doładowaniu fonta zmienia szerokość i przesuwa layout. font-display: swap razem z <link rel="preload" as="font" type="font/woff2" crossorigin> ogranicza ten skok. Deskryptor size-adjust w @font-face dodatkowo dopasowuje metryki czcionki zapasowej do docelowej.

Rezerwacja miejsca na reklamy i osadzone widgety

Bloki reklamowe, osadzone posty i formularze newslettera doładowywane asynchronicznie potrafią zepchnąć treść o kilkaset pikseli w dół po pełnym wczytaniu strony. Kontener z min-height odpowiadającym typowemu rozmiarowi reklamy, np. 250 px dla formatu 300×250, eliminuje ten skok nawet przy opóźnieniu ładowania 1-2 s.

Unikanie wstawiania treści nad już wyrenderowaną zawartością

Baner promocyjny, powiadomienie o cookies albo pasek z ofertą wstawiane dynamicznie ponad już wyrenderowaną treścią przesuwają wszystko poniżej o wysokość nowego elementu. Rozwiązaniem jest zarezerwowanie miejsca na taki element od razu w układzie strony zamiast wstrzykiwania go po fakcie przez JavaScript.

Blog, który dodał width i height do 140 obrazów i zmienił ładowanie reklam na kontenery z zarezerwowaną wysokością, obniżył CLS z 0,34 do 0,06 w dwa tygodnie.

Jakimi narzędziami zmierzyć Core Web Vitals przed i po optymalizacji?

Core Web Vitals mierzy się danymi z pola (field data), pokazującymi realne wyniki odwiedzających, oraz danymi laboratoryjnymi (lab data), do testowania pojedynczej poprawki przed wdrożeniem na produkcję.

Dane z pola widać w Google Search Console (raport „Podstawowe wskaźniki internetowe”) oraz w PageSpeed Insights, w sekcji danych realnych użytkowników z ostatnich 28 dni. To jedyne źródło, które Google bierze pod uwagę jako sygnał rankingowy – opisane w dokumentacji Google Search Central.

Lighthouse i WebPageTest symulują warunki sieciowe i sprzętowe – domyślnie wolne 4G i procesor spowolniony 4-krotnie. Lighthouse nie mierzy INP bezpośrednio, tylko zastępczy Total Blocking Time, więc do weryfikacji potrzebne są dane z pola albo biblioteka web-vitals wpięta na stronie. Metodologię pomiaru opisuje web.dev/vitals.

1. Zapisz wynik bazowy z PageSpeed Insights (dane z pola) i z Lighthouse (dane laboratoryjne).
2. Wdróż jedną zmianę na raz – np. preload obrazu hero albo width i height do obrazów.
3. Po 24-48 godzinach porównaj wynik lab z danymi z pola – rozbieżność powyżej 20-30% sugeruje, że test lab nie odzwierciedla realnych warunków użytkowników.

Testowanie jednej zmiany na raz, nie pakietu dziesięciu poprawek naraz, pozwala wskazać, która technika faktycznie podniosła wynik.

Ile czasu i budżetu wymaga poprawa Core Web Vitals?

Koszt i czas poprawy zależą od liczby problemów i wielkości strony – CLS na stronie z 10 podstronami naprawia się inaczej niż na sklepie z 2000 kart produktowych.

• Optymalizacja obrazów (kompresja, WebP/AVIF, width i height) do 50 podstron: 1-3 dni robocze, 800-2500 zł.
• Redukcja JavaScriptu (code splitting, audyt third-party): 3-10 dni roboczych, 2000-6000 zł zależnie od złożoności frontendu.
• Poprawa TTFB i konfiguracji serwera (cache, CDN, baza danych): 1-4 dni robocze, 500-2000 zł.
• Pełny audyt i wdrożenie dla wszystkich trzech metryk na stronie średniej wielkości: 2-4 tygodnie, 4000-10 000 zł.

Strony na WordPressie z rozbudowaną liczbą wtyczek wymagają zwykle więcej czasu na diagnostykę niż na naprawę – wskazanie, która z 20-30 aktywnych wtyczek generuje zbędny JavaScript, zajmuje więcej godzin niż sama poprawka. Stały monitoring wyniku realizuje Craftis w ramach opieki nad stroną WordPress, a strony budowane od podstaw pod kątem Core Web Vitals powstają w ramach usługi tworzenia stron internetowych.

Jakie błędy najczęściej pogarszają wynik Core Web Vitals?

Najczęstszym błędem jest wdrażanie poprawek bez wcześniejszego zmierzenia, która metryka faktycznie generuje problem – zespół spędza tydzień na kompresji obrazów, gdy realny problem tkwi w 400 ms blokady wątku przez skrypt czatu.

• Instalowanie kolejnych wtyczek „przyspieszających” bez usunięcia tych, które faktycznie generują obciążenie – efektem bywa 3-4 wtyczki cache działające jednocześnie i konfliktujące ze sobą.
• Kompresja obrazów bez ustawienia width i height – LCP spada, ale CLS pozostaje wysoki, bo miejsce na obraz wciąż nie jest zarezerwowane.
• Testowanie wyniku wyłącznie na desktopie, gdy 60-75% ruchu na stronach polskich sklepów i usługowych pochodzi z urządzeń mobilnych o słabszych procesorach.
• Ignorowanie danych z pola na rzecz samego Lighthouse – strona może mieć 95 punktów w teście laboratoryjnym i nie spełniać progu „dobry” w danych realnych użytkowników.

Poprawa jednej metryki kosztem drugiej to skutek pracy bez pomiaru bazowego – agresywne opóźnianie JS dla LCP potrafi pogorszyć INP, jeśli skrypty obsługujące interakcję odłożą się zbyt późno.

Jak wdrożyć poprawki Core Web Vitals krok po kroku?

Wdrożenie ma sens w kolejności: pomiar, priorytetyzacja według wpływu na wynik, wdrożenie pojedynczych zmian, ponowny pomiar – nie w kolejności przypadkowego stosowania wszystkich technik naraz.

1. Zmierz aktualny wynik LCP, INP i CLS w PageSpeed Insights i Search Console dla najważniejszych szablonów (strona główna, karta produktu, formularz kontaktowy).
2. Zidentyfikuj metrykę najbardziej odbiegającą od progu „dobry” i zacznij od niej.
3. Wdróż 2-3 techniki dla wybranej metryki jednocześnie, np. dla LCP: kompresja obrazu hero, preload i skrócenie TTFB.
4. Sprawdź wynik lab od razu i wynik z pola po 3-7 dniach, potem przejdź do kolejnej metryki.
5. Ustaw cykliczne sprawdzanie wyniku raz w miesiącu, bo nowe treści, wtyczki i skrypty marketingowe potrafią pogorszyć go ponownie w kilka miesięcy.

Wynik „dobry” we wszystkich trzech metrykach jednocześnie osiąga się rzadko przy jednorazowym wdrożeniu – zwykle wymaga 2-3 iteracji rozłożonych na 4-8 tygodni.

Trzy metryki reagują na różne poprawki i żadna pojedyncza wtyczka nie naprawia wszystkich naraz. Optymalizacja zaczyna się od zmierzenia, która z trzech wartości faktycznie odbiega od progu, a dopiero potem od wdrożenia konkretnej zmiany.

Najczęściej zadawane pytania o poprawę Core Web Vitals

Czym różni się LCP od zwykłego czasu ładowania strony?

LCP mierzy czas do wyrenderowania największego widocznego elementu, np. zdjęcia hero, a nie moment, w którym cała strona kończy się ładować. Klasyczny load event uwzględnia wszystkie zasoby, także te niewidoczne od razu, więc słabo odzwierciedla realne wrażenie z otwierania strony.

Czy INP zastąpił całkowicie First Input Delay (FID)?

Tak, Google zastąpił FID metryką INP jako oficjalny wskaźnik Core Web Vitals w marcu 2024 roku, bo FID mierzył opóźnienie tylko pierwszej interakcji. INP agreguje opóźnienia z całej sesji i lepiej pokazuje responsywność w dłuższych sesjach, np. na stronach z filtrami produktowymi.

Jak sprawdzić, która podstrona ma najgorszy wynik Core Web Vitals?

Raport „Podstawowe wskaźniki internetowe” w Google Search Console grupuje adresy URL według szablonu strony i pokazuje, ile z nich mieści się w strefie „dobry”, „wymaga poprawy” i „słaby” dla każdej metryki. Kliknięcie w grupę pokazuje przykładowe URL-e z problemem, co zawęża diagnostykę do jednego szablonu, np. karty produktu.

Czy poprawa Core Web Vitals wymaga zmiany silnika strony (CMS)?

Nie – w większości przypadków poprawę da się wdrożyć w obrębie istniejącego CMS-a, w tym WordPressa, przez optymalizację obrazów, konfigurację cache, redukcję liczby wtyczek i poprawki w szablonie. Zmiana silnika bywa uzasadniona tylko wtedy, gdy architektura platformy generuje problem niemożliwy do naprawy inaczej.

Jak długo utrzymuje się poprawa wyniku po wdrożeniu?

Wynik utrzymuje się tak długo, jak nie zmienia się kod i treść strony w sposób pogarszający wydajność – nowe wtyczki, dodane skrypty marketingowe czy nieskompresowane zdjęcia potrafią cofnąć wynik w 2-3 miesiące od wdrożenia poprawek. Cykliczne sprawdzanie wyniku raz w miesiącu jest częścią utrzymania strony, nie jednorazowym zadaniem.

Czy Core Web Vitals różnią się między mobile a desktopem?

Tak, Google raportuje wyniki osobno dla urządzeń mobilnych i desktopowych, bo różnią się mocą procesora i prędkością łącza. Strona z dobrym wynikiem na desktopie zwykle ma wyraźnie gorszy wynik na mobile, zwłaszcza w INP, bo ten sam kod JavaScript wykonuje się na przeciętnym smartfonie 3-4 razy wolniej niż na komputerze klasy średniej.

Czy wtyczki do cache w WordPressie wystarczą, żeby poprawić Core Web Vitals?

Wtyczka cache poprawia głównie TTFB, co pomaga LCP, ale nie rozwiązuje problemów z niezoptymalizowanymi obrazami, brakiem width i height czy nadmiarem JavaScriptu wpływającym na INP i CLS. Podnosi wynik zwykle o jeden stopień, ale próg „dobry” we wszystkich trzech metrykach wymaga dodatkowych, celowanych poprawek.

Ile kosztuje profesjonalny audyt Core Web Vitals?

Cena zależy od wielkości strony i liczby szablonów – dla wizytówki lub bloga do 30 podstron audyt kosztuje zwykle 500-1500 zł, dla sklepu z wieloma kartami produktowymi 1500-4000 zł. Obejmuje pomiar wszystkich trzech metryk na kluczowych szablonach i priorytetyzację poprawek według wpływu na wynik.