Core Web Vitals 2025: co naprawdę wpływa na LCP, INP i CLS już na etapie projektu i developmentu

Core Web Vitals to zestaw wskaźników, które pokazują, czy strona jest szybka i wygodna w odbiorze. W 2025 roku liczą się przede wszystkim trzy: LCP (jak szybko widać główną treść), INP (jak szybko strona reaguje na kliknięcia i wpisywanie) oraz CLS (czy nic nie „skacze” podczas ładowania). Dobra wiadomość: większość problemów da się rozwiązać jeszcze w fazie projektu i podczas developmentu, bez polowania na „magiczne” wtyczki po wdrożeniu.

Dlaczego planowanie pod CWV zaczyna się od projektu

To, czy strona będzie szybka, decyduje się na etapie pomysłów: ile i jak ciężkie obrazy wstawimy, ile krojów pisma załadujemy, czy górna część strony ma karuzelę, film lub ciężki slider. Jeśli zadbamy o to na początku, programiści nie będą musieli „odchudzać” gotowego projektu, a marketing nie straci ruchu przez wolne wczytywanie.

LCP (Largest Contentful Paint): co naprawdę go psuje

LCP to moment, w którym największy element treściowy nad wodą (np. hero image, duży nagłówek, blok tekstu) staje się widoczny. Najczęstsze przyczyny złego LCP to ciężkie grafiki, fonty blokujące renderowanie, wolne serwowanie plików i zbyt wiele skryptów ładowanych od razu.

• Obrazy hero: używaj formatów nowej generacji (AVIF/WEBP), kompresuj i ustaw atrybuty width/height, aby przeglądarka znała docelowy rozmiar.
• Preload kluczowego elementu: jeśli w hero jest obraz, warto go wskazać jako priorytet do pobrania (preload) i podać właściwy fetchpriority.
• Fonty: ogranicz liczbę rodzin i odmian. Użyj font-display: swap, aby tekst pojawiał się natychmiast systemową czcionką, a dopiero potem podmieniał się na docelową.
• Serwowanie: CDN i kompresja HTTP. Dla obrazów w hero rozważ bezpośrednie serwowanie z najbliższej lokalizacji.
• CSS krytyczny: mały wycinek stylów potrzebnych nad wodą wstrzyknięty w kod strony, a reszta asynchronicznie.

INP (Interaction to Next Paint): jak projekt i kod wpływają na „responsywność”

INP mierzy, jak szybko strona reaguje na interakcje użytkownika (kliknięcia, dotknięcia, wpisywanie). Złe wyniki wynikają zwykle z ciężkiej logiki w JS, „nasłuchiwania” zbyt wielu zdarzeń, blokujących operacji w głównym wątku i komponentów, które odświeżają się w całości po każdej zmianie.

• Minimalizm w JS: usuwaj nieużywane biblioteki i wtyczki. Jeden lekki framework lub czysty JS będzie szybszy niż kilka nakładających się narzędzi.
• Podział kodu (code-splitting): ładuj tylko to, co potrzebne na danej podstronie. Panele administracyjne, widgety i konfiguratory wczytuj dopiero na żądanie.
• Asynchroniczność: długie operacje (np. obliczenia, generowanie list) przenoś do web workers lub dziel na mniejsze porcje, by nie blokować UI.
• Odchudzanie interfejsu: unikaj ciężkich efektów i animacji, które wymagają przerysowania całej strony; trzymaj się transformacji i opacity.
• Kontrola „listenersów”: zamiast nasłuchiwać na każdym elemencie, użyj delegowania zdarzeń na wyższym poziomie DOM.

CLS (Cumulative Layout Shift): koniec z „uciekającymi” przyciskami

CLS mierzy „skakanie” układu podczas ładowania. Najczęstsze przyczyny to obrazy bez rozmiarów, fonty zmieniające metryki tekstu, opóźnione bannery, dynamicznie doczytywane elementy nad treścią i niespodziewane paski ogłoszeń.

• Rezerwacja miejsca: każdemu obrazowi i wideo nadaj width/height lub style z rezerwą. Karuzele i reklamy mają mieć z góry zaplanowany box.
• Stabilne fonty: używaj font metrics override lub paruj kroje o podobnych metrykach, by „swap” nie rozpychał linii.
• Lazy loading z głową: grafiki pod pierwszym ekranem tak, ale nie ładuj leniwie obrazów nad wodą.
• Banery i zgody: planuj ich miejsce w układzie, zamiast „wpychać” je nad nagłówkiem po załadowaniu.

Projekt graficzny: prosty zestaw reguł, który ratuje wydajność

Wystarczy kilka decyzji, by makiety „z urzędu” były przyjazne CWV:

• Maksymalnie jeden hero asset nad wodą (obraz lub krótki nagłówek + CTA). Unikaj pełnoekranowego wideo startowego.
• Jedna rodzina kroju + 2–3 odmiany wag; italik tylko gdy naprawdę potrzebny.
• Ikony jako sprite lub font-ikon; unikaj wielu osobnych plików SVG zewnętrznych nad wodą.
• Reużywalne komponenty: karty, listy, akordeony — łatwiej je później optymalizować i ładować selektywnie.

Development: checklista „zanim wyjdziemy na produkcję”

• Obrazy: AVIF/WEBP, odpowiednie rozdzielczości, atrybuty width/height, fetchpriority dla hero.
• CSS: wydzielony „critical CSS” dla nad-wodą + asynchroniczny załadunek reszty.
• JS: code-splitting, usunięty „dead code”, lazy dla widgetów i formularzy, brak blokujących document.write.
• Fonty: preload dla najważniejszego kroju, font-display: swap, ograniczona liczba subsetów.
• Serwowanie: kompresja, HTTP/2 lub HTTP/3, długożyjące cache z wersjonowaniem plików.
• Pomiar: test w środowisku zbliżonym do produkcji (throttling 3G/4G, urządzenia mobilne, zimny cache).

Treści i CMS: gdzie marketing może „zepsuć” lub „uratować” wynik

Nawet najlepiej napisana strona spowolni, jeśli do CMS trafią zbyt ciężkie zdjęcia lub osadzenia z zewnątrz bez kontroli. Dlatego:

• Ustal limit wagi pojedynczego obrazu (np. 200–300 KB nad wodą, do 100 KB dla miniaturek) i automatyczną konwersję do AVIF/WEBP.
• Wprowadzaj pola na wymiary grafik; edytor ma wiedzieć, że miniatura to np. 800×600.
• Osadzaj wideo przez „lite” komponenty z obrazem zastępczym i odtwarzaniem na klik.
• Ostrożnie z zewnętrznymi skryptami: mapy, czaty, systemy A/B ładuj tylko tam, gdzie są potrzebne.

Mobile first naprawdę się opłaca

Core Web Vitals są mierzone w realnych warunkach użytkowników, bardzo często mobilnych. Projektując, zacznij od mobilnego widoku: krótkie nagłówki, czytelne CTA, lekkie obrazy, mądre kolejności sekcji. Potem rozbuduj desktop, ale bez dokładania ozdobników, które spowolnią każdy ekran.

Monitoring po wdrożeniu: co śledzić co tydzień

Nie wystarczy raz „zrobić dobrze”. W miarę dodawania treści wyniki potrafią się pogorszyć. Minimalny zestaw kontroli to: zmiany LCP/INP/CLS z danych rzeczywistych (pole), ciężar strony głównej i najważniejszych landingów, lista nowych skryptów i osadzeń, alerty o dużych regresjach po publikacjach.

Najczęstsze mity i błędy

• „Zainstalujemy wtyczkę i będzie szybko”. Wtyczki pomagają, ale złych decyzji projektowych nie odczarują.
• „Desktop jest szybki, więc mobilny też”. Telefon ma słabszy procesor i często gorszą sieć; optymalizuj pod mobil.
• „Najpierw zrobimy ładnie, potem przyspieszymy”. Największe zyski są na etapie projektu i architektury, nie po fakcie.
• „CDN rozwiąże wszystko”. Pomoże w dostarczaniu plików, ale nie naprawi ciężkiego JS ani skaczącego layoutu.

Plan wdrożenia CWV na 30 dni (dla zespołu MŚP)

Tydzień 1: przegląd makiet i inwentaryzacja zasobów (obrazy, fonty, skrypty). Podejmij decyzje: liczba fontów, formaty grafik, krytyczny CSS, polityka osadzeń.

Tydzień 2: implementacja hero (obraz/preload), code-splitting dla JS, konfiguracja kompresji i cache, przygotowanie „lite” komponentów do osadzeń.

Tydzień 3: testy mobilne z ograniczoną przepustowością, poprawki INP (web workers, delegowanie zdarzeń), stabilizacja CLS (rezerwacje miejsca).

Tydzień 4: szkolenie zespołu contentowego (limity wagi, formaty, zasady osadzeń), włączenie monitoringu i alertów, przegląd wyników po publikacji.

Podsumowanie

Core Web Vitals to nie „magia Google”, tylko zdrowy rozsądek: szybko pokazać najważniejszą treść (LCP), reagować natychmiast na działania użytkownika (INP) i trzymać stabilny układ (CLS). Jeśli podejmiesz właściwe decyzje już na etapie projektu i developmentu, utrzymanie dobrych wyników po starcie będzie dużo łatwiejsze. Zyskają użytkownicy, SEO i konwersje.

Źródła

https://web.dev/vitals/ — kompendium Core Web Vitals: definicje, progi jakości i dobre praktyki

https://developers.google.com/search/docs/appearance/core-web-vitals — dokumentacja Google Search: jak CWV wpływa na doświadczenie i widoczność

https://web.dev/articles/inp — przewodnik po INP: typowe przyczyny i sposoby poprawy responsywności

https://web.dev/articles/optimize-lcp — jak poprawić LCP: obrazy, fonty, CSS i priorytety zasobów

https://web.dev/articles/cls — jak zapobiegać przesunięciom układu (CLS) w praktyce