Core Web Vitals dla sklepu B2B - LCP, INP, CLS 2026

W skrócie

• 1. LCP (Largest Contentful Paint) - czas do wyrenderowania największego elementu widocznego. Cel: < 2.5s.
• 2. INP (Interaction to Next Paint) - czas reakcji na interakcję. Cel: < 200ms. Zastąpił FID w 2024.
• 3. CLS (Cumulative Layout Shift) - suma nieoczekiwanych przesunięć layoutu. Cel: < 0.1.
• 4. Pomiar: Lighthouse (lab) + Chrome User Experience Report (CrUX, field) + Real User Monitoring.
• 5. Wpływ na ranking: umiarkowany - content i intent ważniejsze, ale CWV waży istotnie przy konkurencji o ten sam keyword.

LCP - czas do wyrenderowania głównego elementu

LCP mierzy, kiedy największy element widoczny na pierwszym viewporcie jest wyrenderowany.

Co liczy się jako LCP element:

• Obrazy (<img>)
• Wideo (<video> poster image)
• Background images CSS (z pewnymi ograniczeniami)
• Bloki tekstu (jeśli są największym elementem)

Typowy LCP element w sklepie B2B:

• Strona główna: główny baner / hero image
• PLP: pierwszy thumbnail produktu (jeśli powyżej fold-a) lub baner kategorii
• PDP: główne zdjęcie produktu
• Checkout: nagłówek lub tabela koszyka

Typowe problemy LCP:

1. Niezoptymalizowany obraz. JPG 800KB na hero. Pobiera się 2-3s na średnim internecie.
2. Brak fetchpriority="high". Browser nie wie, że ten obraz jest krytyczny.
3. Lazy loading na LCP element. Klasyczny błąd: loading="lazy" na pierwszej fotografii. Browser czeka aż user scrolluje.
4. Render-blocking CSS. CSS pobierane synchronicznie blokuje render LCP.
5. Webfonty wymagane do tekstu LCP. Tekst LCP nie wyrenderuje się przed pobraniem fonta.
6. Server-side latency. Backend trwa 2s przed wysłaniem HTML.

Optymalizacja LCP:

<!-- Główne zdjęcie produktu - LCP element -->
<img
  src="produkt.webp"
  alt="..."
  width="600"
  height="600"
  fetchpriority="high"
  decoding="sync"
/>
<!-- BEZ loading="lazy"! -->

<!-- Preload obrazu w head dla jeszcze szybszego LCP -->
<link rel="preload" as="image" href="produkt.webp" fetchpriority="high">

Plus: WebP/AVIF format, CDN, image optimization on the fly. LCP strony produktu.

INP - responsywność na interakcje

INP (Interaction to Next Paint) zastąpiło FID (First Input Delay) w 2024 roku. INP mierzy czas reakcji na każdą interakcję (nie tylko pierwszą).

Co liczy się jako interakcja:

• Klik
• Tap (mobile)
• Klawiatura
• Sklik checkbox/radio

INP = najgorszy czas reakcji na wszystkie interakcje w sesji (zaokrąglony przez Google do p98 dla pojedynczej sesji, potem p75 dla wszystkich sesji).

Typowe problemy INP w B2B:

1. Kliknięcie „dodaj do koszyka" wykonuje wszystko synchronicznie. Walidacja, wywołanie cache, update UI, wszystko w main thread.
2. JavaScript bundle za duży. 1.2 MB JS musi się parse'ować - main thread blokowany.
3. Third-party scripts długie taski. Analytics, chat, tracking - co kilka sekund 50-200ms blocking task.
4. Re-renders React'a/Vue'a bez memoization. Każde dodanie do koszyka renderuje całe drzewo.

Optymalizacja INP:

• Code splitting - JS ładowany on-demand (route-based, component-based)
• Defer/async dla third-party - analytics, chat po LCP
• Debounce/throttle dla interakcji wysokiej częstotliwości (scroll, resize)
• requestIdleCallback dla zadań niskoprio
• Web Workers dla heavy computations (kalkulacje cen po stronie klienta, walidacje)

CLS - stabilność layoutu

CLS mierzy nieoczekiwane przesunięcia layoutu. Najgorszy scenariusz: klient klika „kup", w międzyczasie ładuje się baner, klient klika baner zamiast „kup".

Typowe problemy CLS w sklepie:

1. Obrazy bez width/height lub aspect-ratio. Browser nie zna rozmiaru, ładuje, layout się przesuwa.
2. Webfonty zmieniające font fallback → custom. Tekst rośnie/skraca się po pobraniu fonta. FOUT/FOIT.
3. Dynamiczne wstawianie banerów / popupów cookie. Bez zarezerwowania miejsca.
4. Lazy loading bez placeholderów. Obraz wjeżdża → layout się przesuwa.
5. Liczniki promocji (Czas do końca:) ładowane po render.

Optymalizacja CLS:

<!-- Zawsze width/height na obrazach -->
<img src="..." width="400" height="300" alt="..." />

<!-- Lub aspect-ratio w CSS -->
<style>
  .product-image {
    aspect-ratio: 1 / 1;
    width: 100%;
    height: auto;
  }
</style>

<!-- Font swap z size-adjust (CSS Font Loading API) -->
<style>
  @font-face {
    font-family: 'Inter';
    src: url(...) format('woff2');
    font-display: swap;
    size-adjust: 105%; /* dopasowanie do fallback */
  }
</style>

<!-- Placeholder dla lazy-loaded content -->
<div class="placeholder" style="min-height: 400px;">
  <!-- Tu wjedzie zawartość -->
</div>

Lab data vs. field data - co Google realnie używa

Lab data (Lighthouse, PageSpeed Insights):

• Test wykonywany w kontrolowanym środowisku
• Mobile lub desktop
• Throttling sieci (Slow 4G zazwyczaj)
• Powtarzalne, ale syntetyczne

Field data (Chrome User Experience Report - CrUX):

• Realni użytkownicy Chrome
• Ich device, sieć, lokalizacja
• 28-dniowe rolling window
• To Google używa do rankingu

Konsekwencja: możesz mieć Lighthouse 95/100, ale CrUX w czerwonym. Powody:

• Twoi klienci na starszych urządzeniach
• Twój region ma wolniejszą sieć
• Twoi klienci wykonują akcje pogarszające INP (długie sesje z wieloma interakcjami)

Sprawdzaj field data:

• Google Search Console → Core Web Vitals report
• PageSpeed Insights pokazuje pole CrUX dla URL
• https://crux.run/dashboard?url={URL} - community dashboard

Wpływ na SEO

Google używa Core Web Vitals jako rankingowego sygnału od 2021. Co to znaczy:

Tie-breaker. Przy dwóch stronach o podobnej relevance i autorytecie - szybsza wygrywa.

Domain-level signal. Google patrzy na CrUX dla całej domeny, nie tylko konkretnej strony. Wolne strony w innych częściach domeny szkodzą wszystkim.

Mobile-first. Mobile CWV ważą bardziej niż desktop (mobile-first indexing).

Opóźnienie: zmiany CWV widoczne w rankingu po 2-4 miesiącach (CrUX rolling 28-day, plus Google update queue).

W praktyce: dla większości polskich keywords B2B impact jest umiarkowany. Konkurencja często też ma słabe CWV. Ale dla konkurencyjnych keywordów (np. „integracja Magento Comarch") - solidne CWV daje przewagę.

Najczęstsze błędy w Core Web Vitals w polskich sklepach B2B

1. Tylko Lighthouse. Wynik 90/100, klient skarży się że wolny. Bo CrUX (field) w czerwonym.

2. Optymalizacja tylko homepage. Homepage ma świetne CWV, ale 95% ruchu to PLP/PDP, które są wolne.

3. Brak monitoringu po deploy. Każdy nowy moduł, każdy A/B test może pogorszyć CWV. Bez ciągłego monitorowania regresja niezauważona.

4. Optymalizacja dla niezalogowanych. Klient B2B 90% czasu zalogowany. Optymalizacja stron publicznych nie pomaga zalogowanym.

5. Ignorowanie third-party. „Dodaliśmy tylko jeden mały skrypt analytics" → INP wzrasta o 100ms.

6. Cookie consent killer. Implementacje cookie consent często blokują render aż do interakcji userskiej. LCP zabity.

7. Headless source map nie generated. Optymalizacja JS bez source mapów - niemożliwe znalezienie konkretnego problemu.

Mierzenie CWV - narzędzia w praktyce

Lab / synthetic:

• Lighthouse (DevTools): single page, dobry start
• PageSpeed Insights: Lighthouse + CrUX dla URL
• WebPageTest: szczegółowy waterfall, multi-location, comparison
• Lighthouse CI: integracja z CI/CD, performance budget gates

Field / real user:

• Google Search Console: real CWV dla domeny, segmenty by URL pattern
• Cloudflare Browser Insights: jeśli używasz CF
• Sentry Performance: integracja z aplikacją
• Datadog RUM: korporacyjne
• SpeedCurve: kompleksowe, drogie
• Custom: web-vitals.js: 5KB biblioteka Google, wysyła do twojego API

Co konkretnie monitorować:

• LCP / INP / CLS per page type (home, PLP, PDP, checkout)
• Per user segment (zalogowani vs. nie, desktop vs. mobile)
• Per device, per network
• Trend over time

Performance budget - disciplina

Performance budget to limity, które nie powinny być przekraczane bez świadomej decyzji.

Przykładowy budget dla sklepu B2B:

Metryka	Page type	Budget
LCP	Homepage	1.8s
LCP	PLP (niezalogowany)	2.2s
LCP	PDP (niezalogowany)	2.0s
LCP	PDP (zalogowany)	2.5s
INP	Wszystkie	200ms
CLS	Wszystkie	0.05
JS bundle (initial)	Wszystkie	200KB gzipped
CSS bundle (initial)	Wszystkie	50KB gzipped
Total page weight	PDP	1.5MB

Egzekwowanie:

• Lighthouse CI w pipeline (failuje deploy jeśli budget przekroczony)
• Performance reviews co miesiąc
• Komunikacja do zespołu: dodanie funkcji X jeśli pogorszy LCP o > 100ms - wymaga zgody

FAQ

Czy CWV są jedynym sygnałem wydajności dla Google? Nie. Time to First Byte (TTFB), Total Blocking Time (TBT), Speed Index - pomocnicze metryki. Ale Core Web Vitals (LCP, INP, CLS) to to, co Google ujawniło jako rankingowe.

Czy mogę mieć dobry LCP a zły CLS? Tak. Strona szybko ładuje główny element (LCP dobre), ale po wczytaniu obrazy bez wymiarów przesuwają layout (CLS złe). To dwie osobne metryki.

Co z INP dla zalogowanych B2B? Tak samo ważne. Klient B2B kupujący 50 produktów wykonuje 100+ interakcji. INP > 200ms = każda interakcja czuje się laggy.

Czy headless rozwiązuje CWV? Może. Source good headless (Next.js + SSR + CDN + edge) - tak. Bad headless (CSR z lazy fetch wszystkiego) - gorzej niż dobry monolit.

Czy Magento OS może mieć CWV w zielonym? Tak, z odpowiednim stackem (Varnish + Elastic + Redis + CDN + Hyvä Theme). Bez tego - trudne.

Co dalej

• LCP konkretnie na PDP: LCP strony produktu
• Lazy loading bez psucia CLS: Lazy loading obrazów
• Audyt wydajności: Audyt wydajności sklepu
• Pillar wydajności: Wydajność e-commerce