Wydajność sklepu B2B - Core Web Vitals 2026, LCP, INP, CLS

W skrócie

• 1. Core Web Vitals są rankingowe (Google) i konwersyjne (klient). Cele: LCP < 2.5s, INP < 200ms, CLS < 0.1.
• 2. Większość problemów wydajnościowych to: brak Varnish/cache, niezindeksowane PLP, źle zoptymalizowane obrazy, ciężkie skrypty third-party.
• 3. Najważniejsze działania od najmocniejszych: Varnish/full-page cache → search dedykowany (Elastic/Algolia) → CDN z image optimization → lazy loading → minimalizacja JS.
• 4. Headless nie jest rozwiązaniem wydajności sam w sobie. Headless źle zrobiony jest wolniejszy niż dobry monolit. Hyvä Theme (Magento) daje 70-80% benefitów headlessa za 20% kosztu.
• 5. Audyt wydajności: Lighthouse + WebPageTest + Chrome DevTools + analiza logów = pełen obraz.

Core Web Vitals - co Google mierzy

LCP (Largest Contentful Paint). Czas, w którym największy element widoczny (zazwyczaj główne zdjęcie produktu lub baner hero) jest wyrenderowany.

• Dobry: < 2.5s
• Wymaga poprawy: 2.5-4s
• Słaby: > 4s

Co psuje LCP w sklepie B2B:

• Brak cache (każde wejście generuje stronę)
• Zbyt duży obraz hero (nieoptymalizowany, bez WebP)
• Brak CDN (obraz pobierany z odległego serwera)
• Render-blocking JS / CSS

INP (Interaction to Next Paint). Czas, w którym przeglądarka reaguje na pierwsze ważne interakcje użytkownika (klik, scroll).

• Dobry: < 200ms
• Wymaga poprawy: 200-500ms
• Słaby: > 500ms

Co psuje INP:

• Ciężkie skrypty third-party (analytics, chat, tracking)
• Heavy main thread (długie taski JS)
• Brak code splittingu
• Synchroniczne wywołania bibliotek

CLS (Cumulative Layout Shift). Suma przesunięć layoutu po wczytaniu (im niżej tym lepiej).

• Dobry: < 0.1
• Wymaga poprawy: 0.1-0.25
• Słaby: > 0.25

Co psuje CLS:

• Obrazy bez wymiarów (width/height)
• Lazy loading bez placeholderów
• Dynamiczne wstawianie banerów/reklam
• Webfonty zamieniające content po wczytaniu (FOIT/FOUT)

Core Web Vitals dla sklepu B2B.

Cele wydajnościowe dla B2B 2026

Nie ma jednego „dobre". Cele zależą od skali i ekspetacji. Ale dla średniego polskiego B2B realistyczne targety:

Strony publiczne (niezalogowani, dla SEO):

• Homepage: LCP < 1.8s, INP < 100ms, CLS < 0.05
• PLP: LCP < 2.2s, INP < 150ms, CLS < 0.1
• PDP: LCP < 2.0s, INP < 150ms, CLS < 0.1

Strony zalogowanych (B2B):

• PDP z cenami kontraktowymi: LCP < 2.5s (więcej akceptowalne)
• Koszyk: < 1.5s do gotowości
• Checkout: każdy krok < 1.5s

API:

• Dodanie do koszyka: < 500ms
• Walidacja kuponu: < 800ms
• Złożenie zamówienia: < 2s (z wszystkimi validacjami)
• Pobranie listy produktów (PLP): < 600ms

Te targety są bardziej ambitne niż defaults Magento z domyślnym hostingem. Wymagają stack: Varnish + Elastic/Algolia + CDN + Redis + dobre kodowanie.

Najmocniejsze dźwignie wydajnościowe - w kolejności

Z mojego doświadczenia, ranking najsilniejszych działań:

1. Full-page cache (Varnish lub odpowiednik).

Dla niezalogowanych: cache całych stron HTML. LCP 4s → 200ms na cache hit. Zysk: 95% spadek czasu generacji strony.

Dla zalogowanych: ESI (fragmenty z cache + dynamic content z origin). Zysk: 50-70% spadek.

2. Search dedykowany (Elasticsearch / Algolia / OpenSearch).

Dla katalogu 10k+ SKU z filtrowaniem. PLP w MySQL: 5s. PLP w Elastic: 300ms. Zysk: 90%+ spadek czasu PLP.

Search w architekturze.

3. CDN z image optimization.

Obraz JPG 280 KB → WebP 35 KB. Pobieranie z edge zamiast origin. Zysk: 50-80% spadek LCP.

CDN dla katalogów.

4. Lazy loading + responsive images.

Strona z 50 produktami pobiera 50 × 200 KB obrazów. Z lazy loading + srcset: tylko viewport, w razie scrollu reszta. Zysk: 60-80% spadek initial download.

Lazy loading obrazów.

5. Redis cache dla cen kontraktowych i stanów.

Każde wyświetlenie produktu zalogowanego klienta = zapytanie do ERP o cenę. Z cache 10-15 min: <5% requestów idzie do ERP. Zysk: 70%+ spadek latency dla zalogowanych.

Cache warstwy.

6. Indeksy w bazie + naprawienie N+1.

Klasyk. Lista produktów wykonująca 200 zapytań SQL zamiast 3. Po refaktorze: 90% spadek czasu.

7. Code splitting i lazy JS.

JS bundlowany w jednym pliku 800 KB → 5 chunków po 50-200 KB ładowanych on-demand. Zysk: 30-50% spadek INP.

8. Minifykacja CSS / JS + Brotli/gzip compression.

Klasyka. 500 KB CSS → 80 KB after minify+brotli. Zysk: 40-60% mniejszy transfer.

9. Eliminacja render-blocking skryptów.

Analytics, chat, tracking - wszystko async/defer. Critical CSS inline. Zysk: 200-500ms LCP.

10. HTTP/2 lub HTTP/3 + HTTP/2 server push.

Najczęściej już jest. Wartość marginalna ale niezerowa.

Problem PLP w B2B - gdzie się sypie

Page Listing produktów to najczęściej najwolniejsza strona w sklepie. Powody:

1. Filtry po wielu atrybutach.

Klient zaznacza 5 filtrów. MySQL bez Elastic: 4-12 sekund. To umiera.

Rozwiązanie: Elasticsearch/OpenSearch (Magento 2.4+ wymaga z urzędu), Algolia dla mniejszych.

2. Faceted search (filtry z licznikami).

„Producent: Bosch (123), Makita (87)..." - każda liczba to osobne query. 20 filtrów × COUNT(*) = wolno.

Rozwiązanie: Elasticsearch aggregations w jednym query.

3. Ceny kontraktowe dla każdego produktu na liście.

Lista 50 produktów × wywołanie silnika cen ERP = 50 wywołań. Każde 100-300ms = 5-15s.

Rozwiązanie: batch'owe wywołanie do ERP („daj ceny dla klienta X na te 50 SKU") + cache w Redis.

4. Stany magazynowe per produkt.

50 produktów × pull stan z ERP = analogiczny problem.

Rozwiązanie: synchronizacja stanów do sklepu lokalnie (z TTL 30-120s) + on-demand dla edge case'ów.

5. Obrazki - duże, niezoptymalizowane.

50 produktów × obraz thumbnail 100-300 KB = 5-15 MB pobrane.

Rozwiązanie: CDN z image optimization (WebP 20-40 KB per thumbnail) + lazy loading.

Optymalizacja PLP.

PDP (strona produktu) - wąskie gardła

1. Rendering Magento bez optymalizacji.

Magento ma EAV i ładuje atrybuty per produkt. PDP może wykonywać 50-150 queries SQL na render.

Rozwiązanie: Hyvä Theme (alpine.js+tailwind, mniej queries) lub headless.

2. Cena kontraktowa.

Dla zalogowanego B2B - wywołanie silnika cen ERP. 200-500ms.

Rozwiązanie: cache Redis 5-15 min, klucz (klient, sku, qty=1).

3. Obraz LCP - galeria produktów.

Pierwsza fotografia produktu = zazwyczaj LCP element. Bez optymalizacji ładuje się 1-3s.

Rozwiązanie: priorytetyzacja głównego obrazu (fetchpriority="high", brak loading="lazy"), WebP, CDN.

4. Recommendations / cross-sell / up-sell.

Algorytm rekomendacji wykonuje queries do bazy. Może dodawać 500ms-2s.

Rozwiązanie: async render (po wyrenderowaniu głównego contentu), cache rekomendacji.

5. Recenzje i opinie.

Często third-party (Trusted Shops, Opineo). Każdy ładuje własny JS. Razem 200-500 KB.

Rozwiązanie: ładowanie poniżej fold'a (lazy), async/defer.

LCP strony produktu.

Checkout - krytyczna ścieżka

Checkout dla B2B ma dodatkowe walidacje vs. B2C:

• Walidacja limitu kredytowego (ERP)
• Walidacja stanu magazynowego (ERP/WMS)
• Walidacja cen kontraktowych (ERP)
• Walidacja uprawnień kupującego (approval workflow)

Każda walidacja = round-trip do innego systemu. Bez cache i async - checkout trwa 5-15s. Klient porzuca.

Strategia:

1. Pre-validate w koszyku. Soft walidacja w czasie dodawania do koszyka (cache 5-10 min).
2. Final validate przy potwierdzaniu. Hard walidacja na ostatnim kroku, synchronicznie.
3. Async dla mniej krytycznych. Email, SMS, push do BaseLinkera - po potwierdzeniu, w kolejce.
4. Idempotency. Klient klika 2× „Złóż zamówienie" - tylko jedno trafia do ERP.

Target: każdy krok checkout < 1.5s, finalizacja zamówienia < 2.5s.

Wydajność checkoutu B2B.

Third-party scripts - cichy zabójca INP

Każdy skrypt zewnętrzny to potencjalne pogorszenie wydajności:

• Google Analytics 4 - 50-100ms blocking
• Facebook Pixel - 80-150ms
• Hotjar / Microsoft Clarity - 100-200ms
• Chat (Intercom, LiveChat) - 200-500ms (często blocking)
• Cookie consent banner - 50-100ms (jeśli źle zaimplementowany)
• Trusted Shops widget - 100-200ms
• Allegro Smart, banery marketingowe - różnie

Razem - 1-3 sekundy do INP, jeśli wszystko sync/blocking.

Strategia:

1. Audit: WebPageTest pokaże co konkretnie ile blokuje
2. Defer/async - gdziekolwiek możliwe
3. Lazy load - chat tylko gdy klient scrolluje, GA tylko po consent
4. Self-host - niektóre skrypty (fonty Google, niektóre analytics) można self-host
5. Cookie consent przed wszystkim - fingerprintujące JS-y ładuj dopiero po consent

Audyt wydajności - proces

Powtarzalny proces, którego używam:

Krok 1: Lighthouse + PageSpeed Insights.

• Generuje raport dla pojedynczej strony
• Pokazuje LCP, INP, CLS + sugestie
• Dla 5-10 reprezentatywnych URL (home, PLP najpopularniejsza, PDP losowo, checkout)

Krok 2: WebPageTest.

• Szczegółowy waterfall (co i kiedy się ładuje)
• Comparison mode (przed/po optymalizacji)
• Multi-location testing (PL, DE, US - jeśli istotne)

Krok 3: Chrome DevTools Performance tab.

• Profilowanie konkretnych interakcji
• Main thread analysis
• Memory profiling

Krok 4: Server-side profiling.

• New Relic / Datadog APM / Tideways / Blackfire (PHP)
• Slow query log (MySQL)
• Redis MONITOR (uważnie)
• ERP integration latency

Krok 5: Real User Monitoring (RUM).

• Google Search Console (real LCP/INP/CLS od real users)
• Cloudflare Analytics
• Datadog RUM
• Sentry Performance

Krok 6: Synteza i priorytetyzacja.

• Lista problemów z impact (jak duży zysk) i effort (jak dużo pracy)
• Quick wins (high impact, low effort) jako pierwsze

Audyt wydajności sklepu - checklista.

Wydajność jako proces, nie projekt

Najczęstsza pułapka: „optymalizujemy sklep raz na 2 lata". To nie działa, bo:

• Każdy deploy może coś popsuć
• Dodawanie modułów (chat, A/B testing, marketing automation) obciąża
• Wolumeny rosną (więcej produktów, więcej userów)
• Browser landscape się zmienia (Chrome regularnie zmienia algorytmy)

Wydajność jako proces:

1. Continuous monitoring - alerty na regresji
2. Performance budget - limity per metric (LCP nie może wzrosnąć > 200ms na release)
3. Performance reviews - comiesięczny audyt
4. Performance gates w CI/CD - Lighthouse CI w pipeline, blokuje deploy jeśli wynik się pogorszył

Tylko tak utrzymasz wynik na dłuższą metę.

FAQ

Czy Magento 2 może być szybki? Tak. Z Varnishem + Elastic + Redis + Hyvä Theme + CDN - LCP < 2s realne dla PLP/PDP. Bez tych elementów - nie.

Czy headless commerce automatycznie znaczy szybki sklep? Nie. Headless z błędną konfiguracją SSR/SSG jest wolniejszy niż dobry monolit. Dobry headless z Next.js + edge functions może być świetny, ale wymaga ekspertyzy.

Czy Hyvä Theme jest must-have dla Magento w 2026? Dla nowych projektów Magento 2.4 dla B2B - praktycznie tak. Hyvä daje 60-80% korzyści wydajnościowych headless za 10-20% kosztu.

Czy mogę zmierzyć wydajność tylko dla zalogowanych? Tak. Lighthouse CI z autentykacją, RUM tagujący „logged-in" segment, custom timing API. Mierzysz osobno publiczne i logged-in.

Co z mobile dla B2B? Klienci B2B kupują z desktopa, ale mobile użytkownik to często szef zakupów sprawdzający coś szybko. Mobile-friendly wciąż istotne dla SEO i UX.

Co dalej

• Konkretne obszary: Core Web Vitals, LCP PDP, Optymalizacja PLP, Lazy loading, Cache strategie, Audyt wydajności, Wydajność checkoutu
• Pillary pokrewne: Architektura, Platformy