Core Web Vitals często trafiają na biurko wtedy, gdy „wszystko wygląda świetnie”, a mimo to w PageSpeed Insights widać czerwone pola. Dobra wiadomość: w większości przypadków da się poprawić LCP, INP i CLS bez psucia projektu. Trzeba tylko wiedzieć, które elementy designu realnie kosztują czas, a które kosztują go wyłącznie przez sposób wdrożenia.

Core Web Vitals w skrócie: co mierzą i gdzie najczęściej „ucieka” wynik

LCP (Largest Contentful Paint) mówi, jak szybko użytkownik zobaczy największy element w pierwszym ekranie. INP (Interaction to Next Paint) ocenia, jak sprawnie strona reaguje na kliknięcia i inne interakcje. CLS (Cumulative Layout Shift) mierzy, czy układ „pływa” podczas ładowania.

Poniżej szybka mapa problemów, która pomaga przypisać objawy do metryk i dobrać działania bez ruszania layoutu.

Metryka	Cel (wartości orientacyjne)	Typowe przyczyny	Najczęściej skuteczne działania
LCP	≤ 2,5 s	ciężki obraz hero, wolny TTFB, blokujące CSS/JS	optymalizacja i priorytetyzacja obrazów, cache/CDN, krytyczny CSS, defer
INP	≤ 200 ms	długie zadania JS, zbyt dużo skryptów, ciężkie widgety	dzielenie kodu, opóźnianie funkcji, ograniczenie skryptów, porządek w eventach
CLS	≤ 0,1	brak wymiarów obrazów/iframe, banery wstrzykiwane „nad treścią”, fonty	width/height lub aspect-ratio, rezerwacja miejsca, stabilne ładowanie fontów

Zacznij od danych, nie od „wrażeń”: lab kontra realne wizyty

Wynik z Lighthouse to dobry kierunek, ale biznesowo liczy się to, co dzieje się u prawdziwych użytkowników. Dlatego sensowny start to zestaw: dane terenowe (Search Console / CrUX) plus testy laboratoryjne (Lighthouse / WebPageTest), które pokażą wodospad zasobów i moment, w którym LCP faktycznie się „zapala”.

Jeśli strona ma dużo typów podstron (home, kategorie, produkt, artykuł), warto wybrać po 1–2 reprezentatywne adresy z każdej grupy. Poprawianie losowej podstrony, bo ma najgorszy wynik w PSI, często kończy się pracą, która niewiele zmienia w skali całego serwisu.

Tabela narzędzi, które zwykle wystarczają do kontroli postępu:

Narzędzie	Po co je używać	Kiedy daje największą wartość
Google Search Console (raport CWV)	dane z realnych wizyt, grupowanie podobnych URL	priorytetyzacja: które szablony psują wyniki
PageSpeed Insights	lab + dane terenowe (jeśli dostępne)	szybkie wskazówki i porównanie przed/po
Lighthouse (Chrome DevTools)	audyt lokalny, sugestie dot. zasobów i blokad	praca developerska i weryfikacja zmian
WebPageTest	filmstrip, waterfall, testy na słabszych łączach	diagnoza LCP, TTFB, krytycznych zasobów
Chrome Performance	profil JS, long tasks, input latency	polowanie na problemy INP

LCP: najszybsze zyski zwykle są „na pierwszym ekranie”

Jeśli LCP jest słaby, najczęściej winny jest element hero: duża grafika, slider, wideo albo blokujące style. Klucz to nie „odchudzić projekt”, tylko ustawić priorytety ładowania tak, by przeglądarka jak najszybciej dostała to, co buduje pierwszy ekran.

W praktyce pomagają trzy kierunki: obraz LCP, ścieżka krytycznego renderowania i serwer.

• Obraz hero: kompresja, AVIF/WebP, poprawny rozmiar, brak lazy loadingu na LCP.
• Krytyczne zasoby: ograniczenie blokującego CSS/JS, preloading tego, co naprawdę musi być wcześniej.
• TTFB i cache: szybka odpowiedź serwera, CDN dla statyków, sensowne nagłówki cache.

Dobry, prosty przykład priorytetyzacji grafiki hero:

<link rel="preload" as="image" href="/img/hero.avif" imagesrcset="/img/hero-960.avif 960w, /img/hero-1440.avif 1440w" imagesizes="100vw">

<img
  src="/img/hero-1440.avif"
  srcset="/img/hero-960.avif 960w, /img/hero-1440.avif 1440w"
  sizes="100vw"
  width="1440"
  height="720"
  fetchpriority="high"
  alt=""
>

Tu są dwa ważne detale: fetchpriority="high" (często pomaga, gdy przeglądarka konkuruje o zasoby) oraz jawne width/height, które przy okazji stabilizują layout.

Obrazy bez utraty jakości: „design” wygrywa wdrożeniem, nie wagą pliku

Wiele stron traci LCP nie dlatego, że grafiki są duże wizualnie, tylko dlatego, że są duże plikowo albo źle dopasowane do urządzenia. Ten sam kadr może wyglądać identycznie, a ważyć 5 razy mniej po konwersji do AVIF i poprawnym srcset.

Po akapicie audytu graficznego zwykle pojawiają się szybkie poprawki, które nie dotykają makiet:

• AVIF / WebP
• srcset i sizes
• kompresja bezstratna dla elementów UI
• CDN dla statycznych zasobów
• sensowne limity wymiarów dla miniatur

Jeśli w projekcie jest dużo zdjęć „pełna szerokość”, dobrze działa podejście art direction: inne kadry na mobile i desktop. To nadal ten sam design, tylko lepiej dopasowany do ekranu.

INP: szybkość reakcji bez wycinania interakcji i animacji

INP potrafi zaboleć na stronach, które wizualnie są lekkie, ale logicznie ciężkie: dużo JS na starcie, sporo walidacji, rozbudowane filtry, czaty, mapy, testy A/B, rozbudowane trackowanie.

Najczęściej nie trzeba usuwać funkcji. Trzeba je przełożyć w czasie, skrócić długie zadania i ograniczyć „przepychanki” w wątku głównym.

Lista działań, które realnie poprawiają INP na typowych wdrożeniach:

• Podział JS na mniejsze porcje: code splitting i ładowanie funkcji dopiero wtedy, gdy są potrzebne.
• Odchudzenie startu: mniej kodu wykonuje się przy pierwszym renderze, więcej dopiero po interakcji.
• Porządek w eventach: delegacja zdarzeń, mniej handlerów na setkach elementów, mniej pracy w callbackach.
• Praca w tle: Web Worker dla cięższych obliczeń, gdy to ma sens.

W HTML często wystarczy dopilnować podstaw:

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

A w aplikacji doładowywać rzadko używane moduły:

button.addEventListener("click", async () => {
  const { openConfigurator } = await import("./configurator.js");
  openConfigurator();
});

To podejście zwykle pozwala zachować „bogaty” UI, a jednocześnie sprawić, że kliknięcia nie czekają na wykonanie zaległego kodu.

CSS i render: jak przyspieszyć pierwszy ekran bez zmiany wyglądu

Design nie musi być prostszy, żeby CSS był szybszy. Najczęściej problemem jest to, że przeglądarka dostaje zbyt dużo stylów na start, w tym reguły dla podstron i komponentów, których na pierwszym ekranie w ogóle nie ma.

W praktyce działają dwa ruchy: krytyczny CSS inline dla pierwszego widoku oraz odroczone ładowanie reszty. Do tego usuwanie nieużywanych reguł, szczególnie w CMS-ach z rozbudowanymi motywami i wtyczkami.

Wersja „bezpieczna” dla wdrożeń, gdzie ważna jest spójność wyglądu:

<style>
/* critical CSS dla header, hero, pierwszej sekcji */
</style>

<link rel="preload" href="/assets/styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/assets/styles.css"></noscript>

Efekt bywa zaskakujący: strona wygląda tak samo, ale pierwszy render pojawia się wcześniej, a LCP spada o setki milisekund.

CLS: stabilny layout nawet z banerami, fontami i komponentami zewnętrznymi

CLS najczęściej „psuje się” przez drobiazgi, które w projekcie są niewidoczne: obraz bez wymiarów, iframe z mapą, baner cookies wstrzyknięty nad nagłówkiem, font, który podmienia metrykę tekstu.

Najbardziej opłacalna zasada: przeglądarka ma wiedzieć z góry, ile miejsca zajmie każdy element, który pojawi się później.

Kilka sprawdzonych praktyk:

• obrazy i video: width/height albo aspect-ratio
• sloty na reklamy i widgety: stała wysokość kontenera zanim załaduje się treść
• komponenty nad treścią: zamiast wpychać content w dół, lepiej użyć warstwy typu overlay
• fonty: font-display: swap, a dla kluczowych krojów preload

Przykład rezerwacji miejsca bez ingerencji w wygląd:

.hero-media { aspect-ratio: 16 / 9; background: #f2f2f2; }

I stabilniejsze fonty:

@font-face{
  font-family: "Brand";
  src: url("/fonts/brand.woff2") format("woff2");
  font-display: swap;
}

Skrypty zewnętrzne: marketing i analityka, które nie niszczą metryk

Najtrudniejsze przypadki to nie obrazy, tylko integracje. Chat, mapa, odtwarzacz, rozbudowane tagi, systemy rekomendacji. Każdy z nich potrafi dorzucić JS, opóźnić main thread i dołożyć przesunięcia.

Da się to ułożyć partnersko z marketingiem: część rzeczy ładować po zgodzie, część po interakcji, część z opóźnieniem, a część w ogóle usunąć, jeśli nie daje wartości.

Proces wdrożenia zmian, który zwykle minimalizuje ryzyko „zepsucia” designu i funkcji:

1. Najpierw staging i pomiary na tych samych scenariuszach (desktop i mobile).
2. Potem wdrożenie etapami na kluczowych szablonach (np. home i topowe landing pages).
3. Na końcu monitoring regresji po aktualizacjach CMS, wtyczek i tagów.

To podejście pomaga utrzymać kontrolę, bo problemy CWV często wracają po drobnej zmianie, która miała „tylko dodać jeden skrypt”.

Budżet wydajności: jak bronić designu i jednocześnie poprawiać wyniki

Dobrze działa prosty performance budget, zapisany jak wymaganie projektowe. Nie jako restrykcja kreatywna, tylko jako ramy wdrożeniowe: maksymalny rozmiar hero, limit fontów, zasady dla animacji i video.

Taki budżet można opisać na poziomie komponentów, a nie całej strony. Przykład: „hero może mieć wideo, ale startuje jako poster i ładuje odtwarzacz dopiero po kliknięciu” albo „czcionki brandowe są dwie, reszta to system fonts”. Design zostaje, implementacja staje się tańsza w milisekundach.

Jak podchodzi do tego Pro‑Strony.pl: strategia, wdrożenie, a potem iteracje

W praktyce najwięcej zysku daje podejście end to end: od hostingu i cache, przez front-end, po SEO i analityką. W Pro‑Strony.pl taki model pracy jest naturalny, bo projekty stron i sklepów często idą w parze z pozycjonowaniem, kampaniami i dalszym rozwojem, a to wymusza myślenie o metrykach nie tylko „na dzień odbioru”.

Dobrze też działa zaczynanie od audytu i strategii dla kluczowych szablonów, a potem wdrażanie zmian w kolejności, która daje szybki efekt biznesowy: najpierw LCP na stronach wejścia, potem INP na podstronach z interakcją (filtry, koszyk), a CLS wszędzie tam, gdzie układ potrafi się przesuwać przez elementy dynamiczne.

Monitoring po wdrożeniu: jak nie stracić wyniku po miesiącu

Core Web Vitals to temat „żywy”. Zmieni się slider, dojdzie nowy piksel, wtyczka zaktualizuje bibliotekę, hosting zmieni parametry. Bez monitoringu łatwo wrócić do punktu wyjścia.

Minimum, które utrzymuje wynik w ryzach, to regularny przegląd raportu CWV w Search Console oraz cykliczne testy Lighthouse dla najważniejszych adresów. Przy większych serwisach warto dołożyć alerty z RUM lub testy regresji w CI, żeby pogorszenie LCP, INP czy CLS było widać od razu, a nie dopiero wtedy, gdy spadnie ruch albo konwersja.