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

Core Web Vitals to trzy metryki, którymi Google mierzy realne wrażenia użytkownika na Twojej stronie: jak szybko pojawia się treść (LCP), jak szybko strona reaguje na kliknięcia (INP) i jak bardzo „skacze" układ podczas ładowania (CLS). Od marca 2024 metryka INP zastąpiła starsze FID, a od 2025 wszystkie trzy są mierzalne już nie tylko w Chrome, ale też w Firefoksie i Safari. W tym przewodniku tłumaczę dokładne progi, najczęstsze przyczyny problemów, konkretne poprawki — i pokazuję, jak wycisnąć dobre wyniki w Next.js bez magii i bez ścigania się o „100/100".

Core Web Vitals to trzy metryki realnego doświadczenia użytkownika: LCP (jak szybko pojawia się treść), INP (jak szybko strona reaguje) i CLS (czy układ skacze). Tłumaczę dokładne progi, najczęstsze przyczyny i konkretne poprawki — w tym dźwignie w Next.js — bez ścigania się o „100/100” w Lighthouse.

Większość audytów wydajności kończy się w tym samym miejscu: ktoś otwiera PageSpeed Insights, widzi czerwoną liczbę, panikuje i zaczyna optymalizować przypadkowe rzeczy. Tymczasem Core Web Vitals to nie jest jedna liczba do „podbicia" — to trzy odrębne metryki, każda z własną przyczyną i własnym lekarstwem. Zacznijmy od tego, co naprawdę znaczą.

Czym są Core Web Vitals (i czym nie są)

Core Web Vitals (CWV) to podzbiór szerszego zestawu sygnałów Google o nazwie page experience. Mierzą jakość doświadczenia użytkownika w trzech wymiarach: ładowanie, interaktywność i stabilność wizualna. To, co wyróżnia CWV spośród dziesiątek metryk wydajności, to fakt, że Google ocenia je na podstawie danych od prawdziwych użytkowników Chrome — nie na podstawie jednego pomiaru w laboratorium.

Kluczowa zasada: każda metryka oceniana jest na 75. percentylu (p75) odsłon z ostatnich 28 dni. Oznacza to, że co najmniej 75% wizyt musi spełnić próg „dobry", żeby cała strona dostała ocenę „dobrą". Nie liczy się Twój najszybszy test ani Twój telefon — liczy się to, co widzi większość realnych użytkowników, często na słabszych urządzeniach i wolniejszych łączach.

Trzy metryki i ich dokładne progi

Wszystkie trzy progi muszą być spełnione na p75, żeby strona zaliczyła Core Web Vitals jako całość. Teraz po kolei — co je psuje i jak je naprawić.

LCP — jak szybko pojawia się treść

Largest Contentful Paint mierzy czas do wyrenderowania największego elementu widocznego w pierwszym ekranie — zwykle obrazu hero, dużego nagłówka albo bloku tekstu. To najbliższy maszynowy odpowiednik pytania „kiedy użytkownik widzi, że strona się załadowała".

Najczęstsze przyczyny słabego LCP:

• Wolny serwer i wysoki TTFB (czas do pierwszego bajtu).
• Zasoby blokujące renderowanie — CSS i JavaScript wstrzymujące pierwsze malowanie.
• Duże, nieskompresowane obrazy hero.
• Lazy-loading elementu LCP — klasyczny błąd: leniwe ładowanie głównego obrazu opóźnia jego wykrycie i pobranie.
• Czcionki webowe blokujące render tekstu.

Co realnie pomaga:

• Nowoczesne formaty obrazów (AVIF/WebP), poprawne wymiary i `srcset`.
• Atrybut `fetchpriority="high"` na obrazie LCP — natychmiast podbija jego priorytet.
• `preload` dla zasobów wykrywanych późno (np. obraz LCP wskazywany z CSS).
• Nigdy nie ładuj leniwie obrazu LCP — lazy-loading zostaw dla grafik poza ekranem.
• Niższy TTFB: CDN, cache, szybszy backend, renderowanie na brzegu sieci.
• Mniej zasobów blokujących: krytyczny CSS inline, `defer`/`async` dla niekrytycznego JS.
• Renderowanie po stronie serwera (SSR/SSG), żeby HTML z treścią docierał wcześniej.

INP — jak szybko strona reaguje (następca FID)

Interaction to Next Paint to najmłodsza z metryk. 12 marca 2024 INP oficjalnie zastąpiło First Input Delay (FID) jako Core Web Vital. Różnica jest fundamentalna: FID mierzyło wyłącznie *opóźnienie wejściowe pierwszej interakcji* — czyli ile czasu mijało, zanim przeglądarka mogła zacząć obsługiwać kliknięcie. Ignorowało to, jak długo trwa samo przetwarzanie i renderowanie.

INP mierzy znacznie więcej. Obserwuje wszystkie interakcje w całym cyklu życia strony i raportuje (w uproszczeniu) tę najwolniejszą, mierząc pełny czas w trzech fazach:

• Opóźnienie wejściowe — od kliknięcia do startu obsługi zdarzenia.
• Czas przetwarzania — wykonanie funkcji obsługujących zdarzenie.
• Opóźnienie prezentacji — czas do namalowania kolejnej klatki z efektem wizualnym.

Najczęstsze przyczyny słabego INP to długie zadania JavaScriptu blokujące główny wątek, ciężka hydracja frameworka podczas ładowania oraz nieoptymalne procedury obsługi zdarzeń. Co pomaga:

• Rozbijanie długich zadań (powyżej 50 ms) i oddawanie kontroli głównemu wątkowi (`scheduler.yield()`, `scheduler.postTask()`, oddawanie kontroli przez `await`).
• Mniej JavaScriptu: code-splitting i leniwe ładowanie niekrytycznego kodu.
• Debounce/throttle dla zdarzeń o wysokiej częstotliwości.
• Odraczanie niepilnych aktualizacji UI (w Reakcie `useDeferredValue`, `useTransition`).
• Ograniczenie hydracji — mniej komponentów klienckich, hydracja częściowa/progresywna.

CLS — czy układ „skacze"

Cumulative Layout Shift mierzy sumę nieoczekiwanych przesunięć układu podczas ładowania. To ta irytująca sytuacja, gdy chcesz kliknąć przycisk, a w ostatniej chwili wskakuje baner reklamowy i klikasz coś innego. Jako jedyna metryka jest bezwymiarowa.

Przyczyny:

• Obrazy, wideo i ramki `iframe` bez podanych wymiarów.
• Czcionki webowe (przeskok FOUT/FOIT przy podmianie fontu).
• Dynamicznie wstrzykiwana treść (reklamy, embedy, banery) wstawiana nad istniejącą.
• Późno ładujące się banery i paski cookie.

Poprawki:

• Zawsze ustawiaj `width`/`height` albo CSS `aspect-ratio` na obrazach, wideo i ramkach.
• Rezerwuj miejsce na reklamy, embedy i komponenty ładowane dynamicznie, zanim się pojawią.
• Czcionki: strategia `font-display` plus dopasowanie metryk fontu zastępczego (`size-adjust`), by uniknąć przeskoku.
• Nie wstawiaj treści nad już widoczną — wstawiaj poniżej lub w zarezerwowanych slotach.
• Animuj wyłącznie `transform` i `opacity` (kompozytowane), nigdy `top`/`left`/`width`/`height`.

Dane z terenu vs laboratorium — i najgroźniejszy mit

To jest miejsce, w którym większość ludzi się gubi. Istnieją dwa zupełnie różne rodzaje danych o wydajności:

• Dane z terenu (field data / RUM): zbiór CrUX (Chrome User Experience Report) — prawdziwi użytkownicy, prawdziwe urządzenia i łącza, p75, okno 28 dni. To właśnie te dane Google bierze pod uwagę w rankingu.
• Dane laboratoryjne (lab data): Lighthouse / PageSpeed Insights w trybie lab — pojedyncze, symulowane ładowanie na ustalonym urządzeniu. Świetne do diagnozy, ale nieużywane do rankingu.

Stąd najgroźniejszy mit branży: „100/100 w Lighthouse oznacza dobre Core Web Vitals". To nieprawda. Z analiz danych HTTP Archive wynika, że mniej więcej połowa stron z wynikiem 100 w Lighthouse i tak nie przechodziła progów CWV u realnych użytkowników. Wynik 100 znaczy tylko tyle, że Lighthouse nie ma Ci już nic więcej do zasugerowania — a nie, że Twoi użytkownicy mają dobre doświadczenie.

Jest też twardy fakt techniczny: INP w ogóle nie da się w pełni zmierzyć w laboratorium, bo wymaga prawdziwych interakcji użytkownika. Dlatego diagnozuj w lab, ale oceniaj po danych z terenu.

Czy Core Web Vitals to czynnik rankingowy?

Tak, ale mniejszy, niż sugerują nagłówki. CWV są częścią sygnałów page experience (obok HTTPS, przyjazności mobilnej i braku natrętnych interstycjali). Google wielokrotnie powtarza, że pokaże najbardziej trafną i pomocną treść nawet jeśli jej page experience jest słabe.

Najuczciwsze podsumowanie: trafność i jakość treści dominują, a Core Web Vitals działają jak języczek u wagi — gdy kilka stron ma porównywalnie wartościową treść, lepsze doświadczenie może przeważyć szalę. Optymalizuj CWV dla użytkownika, konwersji i tej przewagi remisowej — nie jako magiczny skrót do pierwszej pozycji. Szersze podejście opisuję we wpisie SEO vs GEO — Google a widoczność w AI.

Jak optymalizować Core Web Vitals w Next.js

Next.js daje gotowe dźwignie pod każdą z trzech metryk:

• `next/image` — automatyczna konwersja do AVIF/WebP, responsywne rozmiary i wymuszone wymiary (chroni CLS). Użyj `priority` na obrazie LCP (ustawia `fetchpriority="high"` i preload) → lepszy LCP. Uwaga: nie oznaczaj `priority` wielu obrazów naraz — konkurujące preloady szkodzą LCP.
• `next/font` — self-hosting czcionek (bez zewnętrznego żądania) i automatyczne dopasowanie metryk fontu zastępczego → eliminuje przeskok przy podmianie fontu → lepszy CLS i LCP.
• SSG / `force-static` (App Router) — prerendering HTML na etapie builda → szybsze dostarczenie treści → lepszy LCP.
• Server Components — mniej JS po stronie klienta, mniej hydracji i pracy głównego wątku → lepszy INP. Pułapka: wysoko postawione `"use client"` zmusza całe poddrzewo do wysłania jako kod kliencki — przesuwaj granicę klienta jak najniżej, do najmniejszego interaktywnego komponentu.

To samo podejście stosuję w praktyce przy migracji do Next.js — szybki rdzeń architektury jest tańszy niż łatanie wydajności po fakcie.

Narzędzia, których faktycznie używasz

• PageSpeed Insights — pokazuje dane CrUX z terenu (góra) i dane Lighthouse z lab (dół) dla URL-a lub całej domeny.
• Search Console → raport Core Web Vitals — oparty na CrUX, grupuje adresy wg statusu (Dobry / Wymaga poprawy / Słaby), osobno mobile i desktop.
• Biblioteka `web-vitals` — oficjalna paczka Google do pomiaru LCP/INP/CLS na Twoich własnych użytkownikach (Twój RUM).
• Chrome DevTools — od Chrome 132 (styczeń 2025) panel Performance pokazuje wszystkie CWV i dane CrUX bezpośrednio; dawne rozszerzenie Web Vitals zostało wbudowane w DevTools.

2025–2026: co się zmieniło

• Core Web Vitals stały się cross-browserowe. LCP i INP nie są już tylko w Chrome: Firefox 144 (październik 2025) i Safari 26.2 (grudzień 2025) dodały API potrzebne do ich pomiaru.
• Narzędzia: rozszerzenie Web Vitals zostało scalone z DevTools (Chrome 132); dawny CrUX Dashboard został zastąpiony narzędziem CrUX Vis (po listopadzie 2025).
• Same metryki i progi się nie zmieniły od przejścia na INP w marcu 2024. Uwaga: jeśli widzisz w sieci „nowe progi LCP 2,0 s" albo „nowe metryki VSI/ER" — to dezinformacja, nie ma takich oficjalnych zmian. Dobry próg LCP to wciąż 2,5 s.

Od czego zacząć — kolejność działań

• Sprawdź dane z terenu w Search Console i PSI (nie sam wynik Lighthouse).
• Zidentyfikuj, która z trzech metryk nie przechodzi — każda ma inne lekarstwo.
• LCP: zoptymalizuj obraz hero, dodaj `priority`/`fetchpriority`, popraw TTFB.
• INP: zetnij i rozbij JavaScript, ogranicz hydrację.
• CLS: dodaj wymiary obrazów, zarezerwuj miejsce na elementy dynamiczne, dopasuj czcionki.
• Zmierz ponownie po 28 dniach — CrUX to krocząca średnia, zmiany propagują się stopniowo.

---

Robię pełne audyty technicznego SEO i Core Web Vitals — od diagnozy danych z terenu po konkretne poprawki LCP, INP i CLS w kodzie. Jeśli chcesz nauczyć się tego od podstaw, te zagadnienia rozkładam na czynniki pierwsze w kursie SEO & GEO. Napisz do mnie — zacznę od analizy Twoich realnych danych CrUX i pokażę, co da największy zwrot.

Warto przeczytać dalej:

• Dane strukturalne Schema.org — kompletny przewodnik
• SEO vs GEO — Google a widoczność w AI
• GEO — Generative Engine Optimization w praktyce