Core Web Vitals — jak poprawić LCP, INP i CLS?

Czym są LCP, INP i CLS i dlaczego marketer powinien się tym przejmować?

LCP (Largest Contentful Paint) – czas, w którym użytkownik widzi największy element strony (zwykle hero: obraz, nagłówek, grafika). Google celuje w ≤ 2,5 s dla dobrego wyniku.

INP (Interaction to Next Paint) – ile trwa, zanim strona „odda” reakcję na interakcję (klik, wybór, przewinięcie elementu). Cel: ≤ 200 ms. Jeśli masz „przycisk działa dopiero po sekundzie” albo formularz reaguje z opóźnieniem, INP to wychwyci.

CLS (Cumulative Layout Shift) – czy układ strony skacze podczas ładowania (np. tekst przesuwa się pod obrazem, wyskakuje wysoki baner, przesuwa się formularz). Cel: ≤ 0,1.

Marketer widzi to w liczbach: wyższy współczynnik odrzuceń, gorsza konwersja na landing page i więcej kosztów w Google Ads/Meta, bo reklamowy „popyt” zderza się z wolnym UX. Na moim jednym z projektów dla klienta z e-commerce problem nie był w reklamach, tylko w tym, że LCP dobijało do ~4,5 s na urządzeniach mobilnych — konwersje spadły, a ROAS przestał się zgadzać mimo tego samego targeting’u.

Jak sprawdzić Core Web Vitals dla swojej strony (GA4 nie wystarczy)

Zaczynasz od danych, a nie od „czucia”. Do Core Web Vitals potrzebujesz raportów z UX użytkowników, a nie tylko logiki analitycznej.

Narzędzia startowe:

• PageSpeed Insights (PSI) – szybki wgląd w konkretne podstrony: LCP/INP/CLS oraz wskazówki typu „obraz nie jest zoptymalizowany” czy „zbyt dużo JS”.
• Chrome UX Report / CrUX w PSI – informacja, jak realni użytkownicy widzą stronę (to ważniejsze od symulacji).
• Search Console → raporty dot. UX (Core Web Vitals) – zestawienie url-i i trendów.
• WebPageTest i/lub Lighthouse – gdy chcesz „rozbroić” problem na czynniki (co dokładnie blokuje render).
• RUM (Real User Monitoring) – jeśli macie zasób i budżet: np. SpeedCurve, Calibre albo własny pomiar. RUM mówi prawdę, bo zbiera dane z realnych sesji.

Najprostsza procedura dla firmy (bez zespołu dev):

1. W Search Console wejdź w Core Web Vitals i wyfiltruj problematyczne podstrony (zwykle home, kategoria, produkt, landing pod kampanię).
2. W PSI sprawdź te url-e dla „Mobile”. Zapisz: aktualne LCP/INP/CLS oraz sekcje „Diagnostics” i „Opportunities”.
3. Ustal priorytet: napraw najpierw strony, do których kierujesz płatny ruch (Google Ads, Meta, newslettery). Nie „cały serwis naraz”.

Benchmark w praktyce: w danych Google typowo dopiero gdy większość ruchu jest w strefie „Good”, zaczyna to widać się w trendach biznesowych. Dla przypomnienia: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1.

LCP: co realnie poprawia największy element na ekranie

Najczęstszy powód słabego LCP to: zbyt ciężki hero (obraz), blokowanie renderu przez CSS/JS albo opóźnione ładowanie zasobów krytycznych.

Co robisz (kolejność ma znaczenie):

1. Optymalizuj obraz w hero i w pierwszym widoku
   • Wprowadź WebP/AVIF.
   • Utnij rozmiar „fizyczny” grafiki (np. z 3000px do 1600–2000px, jeśli to realny wymiar na stronie).
   • Włącz lazy-loading tylko dla elementów poniżej foldu — hero ma ładować się natychmiast.
2. Odciąż render-blocking
   • W PSI szukaj „Eliminate render-blocking resources” i „Reduce unused CSS”.
   • Jeśli masz sekcje/banery z systemów typu tracking/CRM, odetnij je od krytycznego CSS na start (tzw. critical CSS).
3. Włącz preloading tam, gdzie to ma sens
   • Jeśli hero jest obrazem kluczowym: rozważ <link rel="preload" as="image"> (współpraca z devem).
   • Nie „preloaduj wszystkiego”, bo to pogorszy — preload ma sens tylko dla elementów, które realnie są w pierwszym widoku.

Co możesz powiedzieć devowi (konkret): LCP to zwykle element „hero image”, „headline” albo „background image”. W PSI sprawdź „LCP element” i dopasuj działania do tego konkretu.

Mniej oczywista rzecz: czasem LCP psuje font. Jeśli hero zależy od custom fontu, a Ty go ładowaniem blokujesz render, użytkownik widzi „pustkę”, zanim pojawi się właściwa czcionka. Dla devów: ogranicz liczbę fontów (np. 1 rodzina + 1 wariant), wdroż font-display: swap i upewnij się, że font nie blokuje first paint.

INP: jak sprawić, żeby kliknięcia były natychmiastowe

INP najczęściej siada przez:

• ciężkie skrypty (JS) i opóźnione interakcje,
• animacje i eventy na „zbyt wielu” elementach naraz,
• formularze z walidacją po stronie klienta, które mielą DOM i wywołują lagi,
• widgety (czat, powiadomienia, heatmapy) z agresywnym listenerem.

Plan naprawczy:

1. Znajdź „co blokuje interakcję”

   W PSI/Lighthouse i WebPageTest sprawdź, jakie zasoby i zadania robią się w czasie interakcji. INP zwykle rośnie przy długich taskach w głównym wątku.

2. Odetnij niepotrzebny JS na landingach reklamowych

   Jeśli kierujesz ruch z Google Ads na osobny URL, to nie musisz ładować całej „reszty portalu”. Często widgety są podpięte globalnie (wszędzie ten sam kod).

3. Popraw formularz i walidację
   Zobacz też: SEO od podstaw — jak działa pozycjonowanie w Google?
   • Waliduj lekko i szybko (np. na blur, nie na każde wciśnięcie).
   • Zmniejsz liczbę handlerów i unikaj przebudowy całego formularza po każdej zmianie.
   • Jeśli wysyłasz żądania, zrób loading state, ale bez blokowania UI.
4. Przesuń ładowanie widgetów

   Czat i narzędzia marketingowe często podnoszą INP. Ustaw je na „after interaction” lub „on idle”, jeśli architektura na to pozwala.

Benchmark, który ma sens w decyzjach: jeśli z INP masz wartości np. 500–800 ms, to konwersje w formularzu lecą szybciej niż zmiana copy. W praktyce dopóki INP nie zejdziesz bliżej 200–300 ms (dla większości urządzeń), optymalizacja reklam to często „kosmetyka”.

Kontrolowana niedoskonałość: jeśli brakuje budżetu na „pełne” usprawnienia, zrób chociaż jeden ruch: wywal widgety na landingach reklamowych albo odłóż je po pierwszej interakcji. To daje szybkie efekty i nie wymaga przebudowy całej aplikacji.

CLS: jak zatrzymać skakanie layoutu i uniknąć frustracji użytkownika

CLS to klasyk: elementy wczytują się z opóźnieniem i „zjadają miejsce” innym komponentom. Najczęściej wina leży w obrazach bez wymiarów, reklamach/bannerach, czcionkach oraz dynamicznie ładowanych sekcjach.

Najczęstsze przyczyny i naprawy:

• Obrazy bez width/height – dodaj atrybuty rozmiaru w HTML/CSS, żeby przeglądarka zarezerwowała miejsce.
• Reklamy lub banery ładowane po starcie – ustaw wysokość i miejsce z góry (container z ustalonym rozmiarem).
• Czcionki – ucieczka CLS występuje przy fallbacku. Rozwiązanie: font-display: swap i dopasowanie metryk (w praktyce: mniej skoków w porównaniu do „wczytane później wszystko”).
• Widoki warunkowe – cookie banner, pop-upy, sekcje „rozwijane” ładuje się późno i przesuwa treść. Daj im przestrzeń lub uruchamiaj po czasie/na działanie użytkownika.

Tip z praktyki: CLS możesz „popsuć” nawet dobrymi optymalizacjami LCP. Dlatego po każdej zmianie sprawdzaj wszystkie trzy: LCP, INP i CLS, bo optymalizacje często konkurują ze sobą.

Kto za to odpowiada i ile to kosztuje? Agencja vs freelancer vs „zrobimy sami”

Core Web Vitals nie wymaga matematyki — wymaga sensownego procesu i pracy nad kodem/zasobami. U Ciebie (marketerze) kluczowe są decyzje: które landing page naprawiamy i po czym poznajemy efekt.

Najczęstsze modele współpracy:

Dodatkowo koszty ukryte: jeśli strona opiera się na CMS z wtyczkami, to naprawy mogą wymagać zmian w konfiguracji lub wymiany komponentów. Często to nie „kod”, tylko „system”.

Benchmarky biznesowe, które warto mieć w głowie:

• W Google Ads średni CTR w Polsce w wielu branżach to zwykle 2–5% (zależnie od konkurencji i jakości kreacji).
• CPC (koszt kliknięcia) potrafi wahać się od 5 do 30+ PLN — i w takim układzie każda poprawa konwersji z landing page jest jak „bonus” do ROAS.
• Obsługa Google Ads w małych firmach to często 800–3 000 PLN miesięcznie; analogicznie, optymalizacja CWV bywa tańsza niż miesiąc przepalania budżetu na słaby UX.

Moja obserwacja: jeśli strona ma wolny LCP/INP, to poprawa reklam przynosi mniejszy efekt niż naprawa landing page. To nie znaczy „wyłącz Ads”, tylko: napraw najpierw to, co blokuje konwersje.

Plan krok po kroku: od audytu do efektu (z priorytetami pod kampanie)

Oto wersja, którą wdrażałem wiele razy. Jest uporządkowana pod właściciela firmy i marketera — czyli: jak działać, gdy nie masz czasu na zgadywanie.

Krok 1: wybierz 3–5 URL-i, które mają największy wpływ

• landing page pod kampanię z Google Ads/Meta,
• strona, na którą prowadzi najwięcej ruchu organicznego,
• produkt/kategoria z największym ruchem i koszykiem.

Krok 2: zderz dane z biznesem

W GA4 patrz na czas do zdarzenia, konwersje, drop-off na formularzach. Do Core Web Vitals używaj PSI/Search Console jako źródła „wydajności”.

Krok 3: napraw w kolejności LCP → INP → CLS

To nie jest „religia”, tylko logika: LCP dotyka pierwszego wrażenia i wpływa na to, czy użytkownik w ogóle zostaje. INP psuje akcję (klik, formularz). CLS psuje czytelność i zaufanie (użytkownik czuje, że strona „nie ogarnia”).

Krok 4: wdrażaj zmiany małymi partiami i waliduj

• Wprowadź 1–2 poprawki (np. obrazy + fonty).
• Sprawdź PSI/Lighthouse dla 1–2 url-i.
• Dopiero potem przejdź do kolejnego zestawu (np. JS/INP).

Krok 5: po wdrożeniu podepnij „szósty zmysł” do marketingu

Jeżeli poprawiasz landing pod kampanię, oceniaj nie tylko CWV, ale i marketingowo:

• czy spada koszt na lead (CPL),
• czy rośnie konwersja na stronie (CR),
• czy mniej osób rezygnuje w formularzu.

Praktyczne KPI po wdrożeniu: dąż do LCP ≤ 2,5 s oraz INP ≤ 200 ms. CLS trzymaj ≤ 0,1. Realistycznie: nawet częściowa poprawa (np. LCP z 4,0 do 3,0 s) potrafi dać wzrost konwersji.

Jedna „mniej oczywista” rzecz, o której mało kto mówi: sprawdzaj wydajność wersji, którą realnie widzi użytkownik z reklam. Czasem strona mobilna ma inny kod, innego wtyczki albo inny bundle. Zdarzyło mi się widzieć INP dramatycznie gorsze tylko na widokach mobile z określonego szablonu.

Najczęstsze błędy (i dlaczego psują efekt)

• Naprawa tylko „na raporcie”, bez wpływu na realnych użytkowników

  Jeśli poprawisz Lighthouse, ale CrUX/PSI dla mobile dalej pokazuje słabe LCP/INP, to konwersje w reklamach się nie poprawią. Zawsze weryfikuj „Good/Needs improvement” w ujęciu realnych danych.

• Priorytetowanie złej podstrony
  Zobacz też: Techniczne SEO — sitemap, robots.txt, crawlability

  Naprawiasz artykuł blogowy, a kampanie jadą na landing „/oferta/…”. Efekt dla biznesu będzie minimalny. Core Web Vitals musi być zsynchronizowane z ruchem i funnel’em.

• Dodawanie kolejnych „ulepszeń”, które podnoszą INP

  Każdy tracking, czat, animacja i widget to potencjalny wzrost INP. Po optymalizacji LCP często przychodzi „dorzućmy jeszcze popup i chat” — i znów masz lagi przy klikaniu.

• Brak kontroli po wdrożeniu

  Bez walidacji trudno stwierdzić, czy poprawa dotyczy LCP/INP/CLS, czy tylko zmienił się „jeden wykres”. Wydajność to układ naczyń połączonych.

SEO vs Google Ads vs strona: co jest ważniejsze, gdy masz słabe CWV?

Krótko: przy słabych LCP/INP/CLS nie ma sensu robić „maksymalnej optymalizacji SEO i kampanii”, dopóki landing page nie działa.

Jeśli muszę to ubrać w jedno zdanie: Core Web Vitals to podstawa „szybkości i zaufania” landing page, a kampanie to silnik. Bez paliwa silnik nie pokaże mocy.

Podsumowanie: co zrobisz dzisiaj, żeby zobaczyć efekt?

Masz trzy konkretne cele: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1. Najlepszy start to wybranie 3–5 url-i pod kampanie, sprawdzenie PSI/Search Console na mobile i naprawa w kolejności LCP → INP → CLS: obrazy i fonty, render-blocking i JS, a na końcu stabilność layoutu.

Pytanie do Ciebie: które podstrony obsługują Twoje płatne kampanie i jak wyglądają ich LCP/INP/CLS w PageSpeed Insights (dla mobile)? Jeśli wkleisz 2–3 wyniki (wartości + nazwę elementu LCP), mogę zaproponować priorytety zmian i „plan prac” do wdrożenia.