Core Web Vitals 2026: Prędkość to nowa waluta

Dashboard wydajności – Core Web Vitals LCP INP CLS

Speed First. Always.

Kluczowe wnioski

INP (Interaction to Next Paint) zastąpił FID od marca 2024 jako metrykę interaktywności w oficjalnych CWV.
Progi "dobrego" doświadczenia wg Google: LCP < 2,5 s, INP < 200 ms, CLS < 0,1.
Badania branżowe wskazują, że poprawa LCP może wspierać konwersję, ale skala efektu zależy od kontekstu serwisu.
CWV jest sygnałem rankingowym Google — ma jednak mniejszą wagę niż jakość treści i relevancja.
Narzędzia do pomiaru: PageSpeed Insights, Lighthouse, Chrome UX Report (CrUX), Web Vitals Extension.

Poradnik wideo

Materiał z kanału Kredo Labs — INP i Core Web Vitals w praktyce (uzupełnienie artykułu).

Obejrzyj na YouTube — Kanał YouTube Kredo Labs

INP: Klucz do interaktywności

Interaction to Next Paint (INP) zastąpiło wysłużone FID jako główny wskaźnik responsywności. Celem optymalizacji jest kalibracja stron tak, aby każda interakcja użytkownika wywoływała natychmiastową reakcję wizualną. Optymalizacja Main Thread to kluczowy priorytet nowoczesnego front-endu.

Czym dokładnie jest INP? To metryka, która mierzy czas od momentu interakcji użytkownika (kliknięcie, dotknięcie, naciśnięcie klawisza) do momentu, gdy przeglądarka wyrenderuje następną klatkę wizualną. Google uznaje wynik poniżej 200 ms za dobry, między 200 a 500 ms za wymagający poprawy, a powyżej 500 ms za słaby. W przeciwieństwie do starego FID, INP uwzględnia wszystkie interakcje podczas całej wizyty użytkownika, a nie tylko pierwszą.

Kluczowym wyzwaniem w optymalizacji INP jest zarządzanie głównym wątkiem przeglądarki (Main Thread). Każde długie zadanie JavaScript (long task) trwające ponad 50 ms blokuje możliwość reagowania na interakcje użytkownika. Skuteczną techniką jest dzielenie zadań (task splitting) za pomocą scheduler.yield() oraz requestIdleCallback(), aby długie operacje nie blokowały interfejsu.

Kolejną skuteczną strategią jest debouncing i throttling obsługi zdarzeń. Zdarzenia takie jak scroll, resize czy input mogą generować setki wywołań na sekundę. Bez odpowiedniego ograniczenia częstotliwości, każde z nich obciąża Main Thread i pogarsza INP. Warto również stosować technikę Passive Event Listeners dla zdarzeń dotykowych i przewijania, co informuje przeglądarkę, że nie zamierzamy blokować domyślnego zachowania.

Analizy danych CrUX sugerują, że strony z lepszym INP często osiągają lepsze wyniki biznesowe niż strony z wyraźnie słabszą responsywnością. To pokazuje przełożenie wydajności technicznej na wyniki biznesowe. Każde dodatkowe opóźnienie reakcji interfejsu zwiększa ryzyko, że użytkownik porzuci stronę.

// Optimization Report

Hydration Time Passed: 120ms

INP (p75) Passed: 89ms

Long Tasks Eliminated: 0

Edge Rendering

Przenosimy logikę renderowania na krawędź sieci. Twoja strona ładuje się z najbliższego serwera CDN, redukując TTFB do minimum.

Next-Gen Formats

AVIF i WebP często znacząco redukują wagę grafik względem starszych formatów, co wspiera szybsze ładowanie.

LCP: Największy element decyduje o wszystkim

Largest Contentful Paint (LCP) to metryka mierząca czas, jaki upływa od rozpoczęcia ładowania strony do momentu wyrenderowania największego widocznego elementu w viewport. Może to być obraz hero, blok tekstu, element wideo lub grafika tła. Google zaleca, aby LCP wynosił poniżej 2,5 sekundy dla dobrego doświadczenia użytkownika.

Optymalizacja LCP to wielowarstwowy proces. Pierwszym krokiem jest zidentyfikowanie elementu LCP na stronie. Najczęściej jest to obraz hero lub główny nagłówek. W narzędziach deweloperskich Chrome można to sprawdzić w zakładce Performance, gdzie element LCP jest wyraźnie oznaczony. Następnie koncentrujemy się na czterech kluczowych obszarach: czasie odpowiedzi serwera (TTFB), czasie ładowania zasobu, czasie renderowania i opóźnieniu wynikającym z CSS/JS.

Redukcja TTFB (Time to First Byte) to fundament dobrego LCP. Jeśli serwer odpowiada wolno, żadna optymalizacja front-endu tego nie nadrobi. Rozwiązaniem jest edge computing i CDN z punktami obecności blisko użytkownika, co zwykle poprawia TTFB. Kluczowe jest również implementowanie cache na poziomie serwera (stale-while-revalidate), cache przeglądarki z odpowiednimi nagłówkami oraz wstępnych połączeń (preconnect) do zewnętrznych domen.

Dla obrazów będących elementem LCP kluczowe jest użycie atrybutu fetchpriority="high" w tagu <img> oraz unikanie lazy loadingu dla elementu powyżej folda. Preload z odpowiednim typem MIME pozwala przeglądarce rozpocząć pobieranie obrazu jeszcze przed przetworzeniem całego HTML. To prosta zmiana, która często zauważalnie poprawia LCP.

Blokujący CSS to kolejny częsty winowajca wolnego LCP. Przeglądarka nie wyrenderuje żadnego elementu, dopóki nie pobierze i nie przetworzy wszystkich arkuszy stylów w sekcji <head>. Rozwiązaniem jest inline Critical CSS, czyli umieszczenie minimalnego zestawu stylów potrzebnych do wyrenderowania widocznej części strony bezpośrednio w HTML, a resztę CSS ładuje się asynchronicznie. Ta technika często poprawia czas renderowania.

CLS: Koniec z przeskakującym layoutem

Cumulative Layout Shift to największy wróg zaufania klienta. Dzięki pre-rezerwacji miejsca na zasoby i inteligentnemu ładowaniu czcionek (Font Display: Swap), eliminujemy irytujące migotanie elementów podczas ładowania.

CLS mierzy sumę wszystkich nieoczekiwanych przesunięć layoutu, które występują w trakcie całego cyklu życia strony. Google uznaje wynik poniżej 0,1 za dobry. Każde przesunięcie jest obliczane jako iloczyn dwóch wartości: frakcji wpływu (impact fraction) i frakcji odległości (distance fraction). Im większy element się przesuwa i im dalej, tym wyższy wynik CLS.

Najczęstsze przyczyny wysokiego CLS to: obrazy i reklamy bez zdefiniowanych wymiarów, dynamicznie wstrzykiwana treść (np. banery cookie, powiadomienia), niestabilne ładowanie czcionek web oraz późne ładowanie komponentów JavaScript. Problemy te eliminuje się poprzez systemowe stosowanie rezerwacji wymiarów za pomocą atrybutów width i height dla wszystkich mediów, a także nowoczesną właściwość CSS aspect-ratio.

Dynamiczna treść, taka jak banery reklamowe, powinna mieć zarezerwowane miejsce w layoutze za pomocą kontenerów o stałych wymiarach. Jeśli reklama się nie załaduje, kontener pozostaje pusty, ale layout nie ulega przesunięciu. Technika ta jest szczególnie istotna dla wydawców i sklepów e-commerce, gdzie reklamy stanowią istotną część przychodu.

Kolejnym istotnym aspektem jest strategia ładowania czcionek. Domyślnie przeglądarki stosują FOIT (Flash of Invisible Text), co oznacza, że tekst jest niewidoczny do momentu załadowania czcionki. Rekomendowanym podejściem jest FOUT (Flash of Unstyled Text) z dyrektywą font-display: swap, które zapewnia natychmiastowe wyświetlenie tekstu z czcionką systemową, a następnie płynną podmianę na czcionkę docelową. Aby zminimalizować wizualne przesunięcie, należy dobrać czcionkę fallback o zbliżonych metrykach (za pomocą CSS size-adjust, ascent-override i descent-override).

99/100

Mobile Score Average

"Nowoczesne frameworki są zoptymalizowane pod kątem Zero-JS na start, co gwarantuje błyskawiczne LCP."