Jak poprawić Core Web Vitals — LCP, INP i CLS po kolei

Trzy metryki, trzy zupełnie różne przyczyny. Ten poradnik idzie od zmian, które zajmują kwadrans i dają najwięcej, do przebudów, w które warto wchodzić dopiero na końcu.

Autor: Redakcja SEOMaster · opublikowano 16.08.2026 · aktualizacja 28.08.2026

Core Web Vitals to trzy pomiary, które opisują trzy różne doświadczenia użytkownika: jak szybko widzi treść, jak szybko strona reaguje na kliknięcie i czy układ nie skacze mu pod palcem. Nie ma jednej optymalizacji, która poprawia wszystkie trzy naraz, dlatego naprawia się je osobno.

Zanim cokolwiek zmienisz, otwórz raport Core Web Vitals w Search Console i sprawdź, KTÓRA metryka jest poza progiem. Optymalizowanie tej, która i tak jest zielona, to najczęstszy sposób na zmarnowanie tygodnia.

CLS — najtańszy do naprawienia

Skakanie układu bierze się prawie zawsze z tego samego: przeglądarka nie wie, ile miejsca zająć coś, co jeszcze się nie wczytało, więc najpierw rysuje stronę bez tego, a potem ją przebudowuje.

1. Podaj wymiary każdemu obrazkowi i ramce

Atrybuty width i height nie ustawiają rozmiaru wyświetlania — od tego jest CSS. Mówią przeglądarce, jaki jest STOSUNEK boków, żeby mogła zarezerwować miejsce, zanim plik dotrze.

<!-- Zle: przegladarka nie wie, ile miejsca zostawic -->
<img src="/hero.jpg" alt="Widok warsztatu">

<!-- Dobrze: miejsce zarezerwowane od pierwszego renderu -->
<img src="/hero.jpg" alt="Widok warsztatu" width="1200" height="630">

/* Zeby obrazek dalej byl responsywny mimo atrybutow */
img { max-width: 100%; height: auto; }

2. Zarezerwuj miejsce na wszystko, co dogrywa się później

Banery zgody, reklamy, widżety opinii i osadzone mapy wstawiają się po wczytaniu strony. Jeśli pojawiają się NAD treścią, spychają ją w dół i generują największe pojedyncze przesunięcia.

/* Kontener o znanej wysokosci zamiast pustki, ktora sie rozepchnie */
.reklama-slot { min-height: 250px; }

3. Wczytaj czcionki tak, żeby nie przebudowywały tekstu

Podmiana czcionki zastępczej na docelową zmienia szerokość liter i przesuwa cały akapit. Deskryptor size-adjust dopasowuje czcionkę zastępczą tak, żeby zajmowała tyle samo miejsca.

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-display: swap;
  size-adjust: 100%;
}

CLS — pełne wyjaśnienie — pełna definicja w słowniku

LCP — najczęściej wymaga zmiany po stronie serwera

LCP mierzy moment, w którym pojawia się największy element widoczny bez przewijania. Prawie zawsze jest to duże zdjęcie w nagłówku albo pierwszy blok tekstu. Lighthouse wskazuje konkretny element, więc zacznij od sprawdzenia, o co dokładnie chodzi.

4. Sprawdź TTFB, zanim ruszysz front-end

Jeśli serwer odpowiada po ponad sekundzie, to jest Twój sufit — żadna optymalizacja obrazków nie zejdzie poniżej czasu odpowiedzi. Najczęstsze przyczyny to brak pamięci podręcznej, wolne zapytania do bazy i przekierowanie przed właściwą odpowiedzią.

TTFB — czas do pierwszego bajtu — pełna definicja w słowniku

5. Wczytaj obrazek LCP z priorytetem, a nie leniwie

To jedyny obrazek na stronie, który NIE powinien mieć loading z wartością lazy. Odroczenie właśnie jego to najczęstszy sposób na przypadkowe pogorszenie LCP przy okazji optymalizacji.

<!-- Glowne zdjecie: priorytet wysoki, bez lazy -->
<img src="/hero.avif" alt="..." width="1200" height="630" fetchpriority="high">

<!-- Wszystkie ponizej zgiecia: lazy -->
<img src="/galeria-1.avif" alt="..." width="800" height="600" loading="lazy">

6. Podaj nowoczesny format i właściwy rozmiar

AVIF i WebP ważą zwykle o połowę mniej od JPEG przy tej samej jakości. Drugi zysk, często większy, to przestanie wysyłać zdjęcie o szerokości 3000 pikseli na ekran o szerokości 400.

<picture>
  <source srcset="/hero.avif" type="image/avif">
  <source srcset="/hero.webp" type="image/webp">
  <img src="/hero.jpg" alt="..." width="1200" height="630" fetchpriority="high">
</picture>

7. Usuń zasoby blokujące renderowanie

Arkusz stylów i skrypt w sekcji head zatrzymują rysowanie strony do czasu ich pobrania. Style krytyczne wstaw w kodzie strony, resztę wczytaj asynchronicznie, a skrypty oznacz jako defer.

<script src="/app.js" defer></script>

LCP — pełne wyjaśnienie — pełna definicja w słowniku

INP — prawie zawsze wina JavaScriptu

INP mierzy czas od kliknięcia do momentu, w którym użytkownik widzi efekt. Zły wynik oznacza, że główny wątek przeglądarki jest zajęty czymś innym i nie ma kiedy narysować odpowiedzi.

8. Znajdź długie zadania

W narzędziach deweloperskich w karcie wydajności nagraj interakcję i poszukaj bloków dłuższych niż 50 milisekund. Zwykle winowajcą jest jeden skrypt, a nie rozproszony problem.

9. Przenieś ciężką pracę poza reakcję na kliknięcie

Użytkownik ma zobaczyć efekt natychmiast. Ciężkie przeliczanie może poczekać do następnej klatki albo trafić do wątku roboczego.

przycisk.addEventListener('click', () => {
  pokazStanWczytywania();          // natychmiast, widoczne dla uzytkownika
  requestAnimationFrame(() => {
    setTimeout(() => ciezkiePrzeliczenie(), 0);  // po narysowaniu klatki
  });
});

10. Ogranicz skrypty zewnętrzne

Menedżery tagów, czaty i narzędzia do map ciepła potrafią samodzielnie zjadać setki milisekund. Sprawdź, ile z nich jest naprawdę używanych — to zwykle najtańszy zysk w całym INP.

INP — pełne wyjaśnienie — pełna definicja w słowniku

Jak sprawdzić, że zadziałało

• Zmierz przed zmianą i zapisz wynik — bez punktu odniesienia nie odróżnisz poprawy od wahania pomiaru.
• Po wdrożeniu sprawdź wynik laboratoryjny w PageSpeed Insights; powinien zareagować od razu.
• Poczekaj dwa do czterech tygodni na dane terenowe w Search Console. To one liczą się w wyszukiwarce.

Nie optymalizuj w ciemno: Zanim wdrożysz cokolwiek z tej listy, sprawdź, czy Twoja strona rzeczywiście ma ten problem. Połowa poradników o wydajności każe naprawiać rzeczy, których na Twojej stronie nie ma.

Najczęstsze pytania

Dlaczego PageSpeed Insights pokazuje inny wynik przy każdym uruchomieniu?

Bo wynik laboratoryjny to jeden test na symulowanym łączu i symulowanym procesorze; wahania rzędu kilkunastu punktów są normalne. Rozstrzygające są dane terenowe z górnej części raportu — pochodzą od prawdziwych użytkowników z ostatnich 28 dni i to one liczą się w wyszukiwarce.

Czy muszę mieć wynik 100 w Lighthouse?

Nie. Lighthouse to narzędzie diagnostyczne, a nie cel. W wyszukiwarce liczy się, czy trzy metryki Core Web Vitals mieszczą się w progach dla 75 procent wizyt — a to da się osiągnąć z wynikiem Lighthouse w okolicach 70.

Poprawiłem stronę, a Search Console nadal pokazuje słaby wynik. Dlaczego?

Bo dane terenowe to średnia krocząca z 28 dni. Po realnej poprawie trzeba odczekać pełne okno, żeby zobaczyć nową wartość. Efekt widać stopniowo, zwykle od drugiego tygodnia.

Co poprawić najpierw, jeśli mam czas tylko na jedną rzecz?

Wymiary obrazków. Podanie width i height każdemu obrazkowi to zmiana na kilkanaście minut, która zwykle likwiduje większość problemu z CLS — a CLS jest najtańszą do naprawienia z trzech metryk.

Pojęcia z tego poradnika

• Core Web Vitals (CWV)
• Largest Contentful Paint (LCP)
• Interaction to Next Paint (INP)
• Cumulative Layout Shift (CLS)
• Time To First Byte (TTFB)
• Lazy loading
• WebP / AVIF
• Zasoby blokujące renderowanie
• preload / preconnect / prefetch
• Obrazy responsywne: srcset, sizes i picture
• WOFF2 (czcionki webowe)
• JavaScript (JS)

Wszystkie poradniki · Cała Wiedza · Sprawdź to na swojej stronie