Core Web Vitals w 2026 — jak zoptymalizować LCP, INP i CLS krok po kroku

Core Web Vitals to trzy metryki, którymi Google mierzy realne doświadczenie użytkownika: LCP odpowiada za szybkość wyświetlenia głównej treści, INP za responsywność interfejsu, a CLS za stabilność układu. Aby serwis został uznany za spełniający wymagania, siedemdziesiąt pięć procent wizyt musi mieścić się w progach „dobrych” — i to mierzonych na prawdziwym ruchu, a nie w warunkach laboratoryjnych.

Czym są Core Web Vitals i dlaczego mają znaczenie

Core Web Vitals to podzbiór sygnałów Page Experience, które Google wykorzystuje w rankingu. Ich wpływ jest realny, choć nie decydujący — dobre wyniki nie wypromują słabej treści, ale przy zbliżonej jakości merytorycznej dwóch serwisów przewaga techniczna przesądza o kolejności.

Znacznie istotniejszy jest wpływ biznesowy. Wydłużenie czasu ładowania przekłada się bezpośrednio na wzrost współczynnika odrzuceń, a w e-commerce na porzucenia koszyka. Optymalizacja wydajności jest więc przede wszystkim optymalizacją konwersji.

LCP — Largest Contentful Paint

Mierzy czas, po którym w polu widzenia pojawi się największy element treści: zwykle zdjęcie w sekcji nagłówkowej, blok wideo lub duży nagłówek tekstowy.

Najczęstsze przyczyny słabego LCP

• Nieoptymalizowany obraz w pierwszym widoku — plik w formacie JPEG o wymiarach znacznie większych niż obszar wyświetlania.
• Zasoby blokujące renderowanie — arkusze stylów i skrypty ładowane w sekcji nagłówka dokumentu.
• Wolna odpowiedź serwera — wysoki czas TTFB przy generowaniu strony bez warstwy cache.
• Kroje pisma z zewnętrznych serwerów ładowane bez strategii wyświetlania tekstu zastępczego.

Co zrobić

• Przekonwertuj obrazy do formatu WebP lub AVIF — redukcja wagi sięga kilkudziesięciu procent bez widocznej utraty jakości.
• Dodaj atrybut fetchpriority="high" do obrazu, który jest elementem LCP, i nigdy nie ładuj go leniwie.
• Zastosuj preconnect do domen, z których pobierasz kroje pisma i skrypty krytyczne.
• Osadź krytyczny CSS bezpośrednio w dokumencie, a resztę ładuj asynchronicznie.
• Włącz kompresję Brotli i serwuj zasoby statyczne z sieci CDN.
• Ustaw font-display: swap, aby tekst był widoczny przed pobraniem docelowego kroju.

INP — Interaction to Next Paint

Metryka wprowadzona w marcu 2024 w miejsce FID. Mierzy opóźnienie między działaniem użytkownika a wizualną reakcją interfejsu — i obejmuje wszystkie interakcje w trakcie wizyty, nie tylko pierwszą. To czyni ją znacznie trudniejszą do oszukania.

Co psuje INP

• Długie zadania w głównym wątku — pojedyncze operacje JavaScript przekraczające 50 milisekund.
• Nadmiar skryptów zewnętrznych — piksele reklamowe, mapy ciepła, widżety chatów, narzędzia do testów A/B.
• Ciężkie procedury obsługi zdarzeń, które wykonują obliczenia synchronicznie zamiast oddać kontrolę przeglądarce.
• Nadmiarowe przerysowania w aplikacjach React przy źle dobranych zależnościach.

Co zrobić

• Podziel długie zadania na mniejsze fragmenty i oddawaj kontrolę wątkowi głównemu między nimi.
• Ładuj skrypty analityczne i marketingowe dopiero po zdarzeniu pełnego załadowania strony.
• Zastąp widżety zewnętrzne lekkimi odpowiednikami — chat można podmienić na przycisk uruchamiający właściwy skrypt na żądanie.
• Stosuj dzielenie kodu, aby przeglądarka pobierała wyłącznie to, czego dana podstrona faktycznie używa.
• Ogranicz liczbę narzędzi śledzących do tych, z których naprawdę korzystasz w raportowaniu.

CLS — Cumulative Layout Shift

Mierzy, jak bardzo elementy przesuwają się w trakcie ładowania. To metryka, którą użytkownicy odczuwają najdotkliwiej: treść skacze w momencie kliknięcia i użytkownik trafia w niewłaściwy element.

Typowe źródła przesunięć

• Obrazy i ramki bez zadeklarowanych wymiarów.
• Bannery zgód, paski informacyjne i powiadomienia wstawiane nad istniejącą treścią.
• Kroje pisma powodujące przebudowę układu po zamianie na docelowy.
• Treść doładowywana dynamicznie w miejscu, dla którego nie zarezerwowano przestrzeni.

Co zrobić

• Zawsze podawaj atrybuty width i height albo aspect-ratio dla obrazów i ramek.
• Rezerwuj miejsce dla banerów i treści ładowanych asynchronicznie za pomocą minimalnej wysokości kontenera.
• Wstawiaj powiadomienia w warstwie nakładki, a nie w przepływie dokumentu.
• Wstępnie ładuj kroje pisma używane w pierwszym widoku i dobieraj krój zastępczy o zbliżonych proporcjach.
• Nie wstrzykuj reklam ani rekomendacji między akapity bez zarezerwowanego miejsca.

Jak mierzyć — narzędzia i kolejność działań

Kolejność pracy ma znaczenie. Zacznij od Search Console, żeby zidentyfikować grupy adresów z problemem. Następnie zdiagnozuj reprezentatywny adres z każdej grupy w PageSpeed Insights. Popraw najpierw to, co dotyczy szablonu — jedna zmiana naprawia wtedy setki podstron naraz.

Checklista wdrożeniowa

• Obrazy w formacie WebP lub AVIF, z wymiarami dopasowanymi do faktycznego obszaru wyświetlania.
• Obraz odpowiadający za LCP z wysokim priorytetem pobierania, bez leniwego ładowania.
• Krytyczny CSS osadzony w dokumencie, pozostałe style ładowane asynchronicznie.
• Skrypty innych firm odroczone do momentu pełnego załadowania strony.
• Wszystkie obrazy i ramki z zadeklarowanymi wymiarami.
• Kroje pisma serwowane z własnej domeny, z ustawionym trybem wyświetlania tekstu zastępczego.
• Kompresja Brotli i nagłówki cache dla zasobów statycznych.
• Zasoby statyczne serwowane z CDN.
• Pomiar metryk od realnych użytkowników wdrożony i raportowany.

Urządzenia mobilne to osobny problem

Google ocenia wersję mobilną i desktopową oddzielnie, a indeksowanie odbywa się w trybie mobile-first. W praktyce oznacza to, że o widoczności serwisu decydują wyniki uzyskane na telefonach — zwykle znacznie gorsze niż na komputerach.

Powód jest dwojaki. Po pierwsze, sprzęt: przeciętny telefon w ruchu rzeczywistym ma wielokrotnie słabszy procesor niż komputer deweloperski, na którym powstawał serwis. Po drugie, łącze: sieć komórkowa poza centrami miast bywa zawodna, a opóźnienia rosną.

• Testuj na realnym urządzeniu średniej klasy, nie na najnowszym modelu. Symulacja w narzędziach deweloperskich jest przybliżeniem.
• Serwuj mniejsze obrazy telefonom za pomocą atrybutów srcset i sizes — wysyłanie grafiki w rozdzielczości desktopowej na ekran o szerokości kilkuset pikseli marnuje transfer i pogarsza LCP.
• Ogranicz JavaScript na mobile. Ten sam skrypt, który na komputerze wykonuje się w kilkanaście milisekund, na telefonie potrafi zająć kilkukrotnie więcej i zablokować reakcję na dotyk.
• Sprawdź obszary dotykowe. Zbyt małe lub zbyt blisko siebie umieszczone przyciski generują przypadkowe kliknięcia i powtórne interakcje, które podbijają INP.
• Uważaj na banner zgody na cookies — na małym ekranie zajmuje znaczącą część widoku i bywa jednocześnie elementem LCP oraz źródłem przesunięć układu.

Podsumowanie

Core Web Vitals nie są celem samym w sobie — są miarą tego, czy serwis jest wygodny w użyciu. Największą poprawę daje zwykle kilka podstawowych działań: właściwy format i priorytet obrazu w pierwszym widoku, ograniczenie skryptów zewnętrznych oraz konsekwentne rezerwowanie miejsca dla elementów ładowanych asynchronicznie.

Warto pamiętać, że optymalizacja jest procesem ciągłym. Każda nowa integracja marketingowa, każdy kolejny widżet i każda zmiana szablonu mogą pogorszyć wyniki. Dlatego pomiar metryk od realnych użytkowników powinien być stałym elementem utrzymania serwisu, a nie jednorazowym audytem przed uruchomieniem.