Przejdź do treści
Wydajność 5 min czytania

LCP na stronie produktu w sklepie B2B - jak zejść poniżej 2 sekund

Karta produktu w sklepie B2B to strona, którą klient otwiera dziesiątki razy w godzinę. Powolne LCP boli każdorazowo. Sklep z 80k SKU i klasycznym Magento 2.4 bez optymalizacji ma LCP w okolicach 3-5 sekund. Z konkretną listą poprawek - można zejść do 1,5-2 sekund, bez przebudowy architektury.

Jakub Owsianka Autor
Zaktualizowano:
Okladka artykulu: LCP na stronie produktu w sklepie B2B - jak zejść poniżej 2 sekund (kategoria: Wydajność)
Okladka artykulu: LCP na stronie produktu w sklepie B2B - jak zejść poniżej 2 sekund (kategoria: Wydajność)
Spis treści (9)

W skrócie

  • 1. Krok 1: WebP / AVIF zamiast JPG (-70% wagi)
  • 2. Krok 2: fetchpriority="high" na głównym obrazie (-200-500ms)
  • 3. Krok 3: Preload obrazu w <head> (-100-300ms)
  • 4. Krok 4: CDN z image optimization on-the-fly (-300-800ms)
  • 5. Krok 5: Eliminacja render-blocking CSS / JS przed LCP (-200-700ms)

Razem: realny LCP 3.5s → 1.5s na typowym Magento.

Krok 1 - Format obrazu

WebP / AVIF zamiast JPG.

Porównanie wielkości dla zdjęcia produktu 1000×1000:

  • JPG (jakość 80): 180 KB
  • WebP (jakość 80): 70 KB
  • AVIF (jakość 80): 45 KB

WebP wspierane przez wszystkie nowoczesne przeglądarki od 2020. AVIF od 2022 (Chrome, Firefox), Safari od 2023.

Implementacja:

<picture>
  <source srcset="produkt.avif" type="image/avif">
  <source srcset="produkt.webp" type="image/webp">
  <img src="produkt.jpg" alt="..." width="1000" height="1000">
</picture>

Lub przez CDN:

Cloudflare Polish, BunnyCDN Optimizer, Fastly IO konwertują format on-the-fly. Wystarczy URL image.jpg?format=webp i CDN to ogarnie.

Magento: moduły obrazów (Mageworx, Amasty Image Compress) lub Adobe Commerce Page Builder. Lub po prostu CDN z optimization.

Shopware: wbudowane Thumbnail Service ma WebP support od 6.4.

Krok 2 - fetchpriority na głównym obrazie

Atrybut fetchpriority="high" mówi przeglądarce: ten zasób jest krytyczny, pobierz go priorytetowo.

<!-- Główny obraz produktu (LCP element) -->
<img
  src="produkt.webp"
  alt="..."
  width="600"
  height="600"
  fetchpriority="high"
>

<!-- Pozostałe obrazy galerii - domyślny priority lub low -->
<img src="produkt-2.webp" loading="lazy" fetchpriority="low">

Wsparcie: Chrome od 2022, Safari od 2023, Firefox od 2023. Browser bez wsparcia po prostu zignoruje atrybut.

Realny zysk: 200-500ms LCP. Najwięcej w środowiskach z wolnym backendem (sklep wysyła HTML wolno, ale obraz jest na CDN i może być pobierany równolegle szybciej).

Krok 3 - preload obrazu w head

<link rel="preload"> mówi przeglądarce zacząć pobierać zasób natychmiast po otrzymaniu HTML, nawet przed parsowaniem reszty.

<head>
  ...
  <link rel="preload" as="image" href="/images/produkt-12345.webp" fetchpriority="high">
</head>

Wartość: podczas gdy browser parsuje HTML, obraz już się pobiera. Klasycznie obraz pobiera się dopiero po dotarciu do <img> tag w HTML.

Realny zysk: 100-300ms LCP.

Uwaga: preload tylko prawdziwie krytycznych zasobów (1 obraz, krytyczne fonty). Jeśli preload'ujesz 10 obrazów - efekt odwrotny, sieć przeciążona.

Krok 4 - CDN z image optimization

CDN robi trzy rzeczy istotne dla LCP:

1. Edge proximity. Obraz z node'a w Frankfurcie do Krakowa = 15ms. Obraz z serwera w Warszawie do Krakowa też 15ms. Obraz z USA do Krakowa = 150ms. Dla zagranicznych klientów CDN ratuje skórę.

2. HTTP/2, HTTP/3, Brotli. Multipleksing, kompresja. Realnie -50-100ms na żądanie.

3. Image optimization on-the-fly. URL parameter (?width=600&format=webp) → CDN serwuje przekonwertowany obraz, cachuje wynik. Pierwsze pobranie dłuższe (konwersja), kolejne - natychmiastowe.

Wynik dla typowego sklepu B2B: -300-800ms LCP po dodaniu CDN. Cloudflare free tier wystarczy.

CDN dla katalogów.

Krok 5 - Eliminacja render-blocking

Browser nie renderuje strony aż pobierze i sparseuje krytyczny CSS i JS. Jeśli te są wolno pobierane / parsowane - LCP czeka.

Render-blocking CSS:

<!-- ZŁY - blocking CSS dla całego sklepu -->
<link rel="stylesheet" href="/static/sklep.min.css">

<!-- DOBRY - critical CSS inline, reszta lazy -->
<style>
  /* tylko CSS dla above-the-fold contentu */
  body, .product-page, .product-image { ... }
</style>
<link rel="preload" href="/static/sklep.min.css" as="style" onload="this.rel='stylesheet'">

Render-blocking JS:

<!-- ZŁY - synchronous JS -->
<script src="analytics.js"></script>
<script src="chat.js"></script>

<!-- DOBRY - defer/async -->
<script src="analytics.js" defer></script>
<script src="chat.js" async></script>

<!-- JESZCZE LEPIEJ - chat ładowany po interakcji -->
<script>
  // Załaduj chat dopiero gdy klient scrolluje lub po 5s
  window.addEventListener('scroll', loadChat, { once: true });
  setTimeout(loadChat, 5000);
</script>

Realny zysk: 200-700ms LCP zależnie od wagi i liczby blokujących skryptów.

Magento PDP - typowe problemy

1. Quickview / hover effects ładowane z głównym JS.

Funkcje, które nie są używane natychmiast (preview po hoverze) ładowane razem z core JS. Move do osobnego chunka, lazy load.

2. Recommendation engine sync.

„Klienci kupowali także" - często wywoływane synchronicznie podczas render. Move do async, render po LCP.

3. Recenzje (Trusted Shops, Opineo) iframe.

Iframe widget z third-party = blocking. Lazy load, intersection observer.

4. Galeria zdjęć ładuje wszystkie obrazy.

5 zdjęć produktu × 200 KB = 1 MB. Lazy load 4 pozostałych, eager tylko pierwsze.

5. Selektory atrybutów (configurable products).

Magento generuje JS z całą logiką atrybutów (kolor → SKU mapping). Może być 50-200 KB JS na configurable z dużą liczbą wariantów. Optymalizacja: lazy load tej logiki.

Hyvä Theme - skokowa zmiana dla Magento

Hyvä to alternatywny theme dla Magento (Alpine.js + Tailwind zamiast Knockout). Daje:

  • 70-90% mniej JS (Alpine.js to ~10 KB vs. Knockout 80+ KB)
  • 60-80% szybsze rendering (mniej layoutów, mniej queries)
  • LCP zazwyczaj 30-50% lepsze out-of-the-box

Wdrożenie Hyvä: licencja jednorazowa ~6-8 tys. EUR per organizację, plus integracja modułów (każdy moduł musi być Hyvä-compatible lub przepisany).

Dla nowych projektów Magento 2.4 dla B2B w 2026 - Hyvä jest praktycznie defaultem.

Mierzenie i monitoring

Po implementacji wszystkich kroków - mierz.

Lab:

  • Lighthouse DevTools, mobile + desktop
  • PageSpeed Insights dla 5-10 reprezentatywnych PDP

Field (krytyczne):

  • Google Search Console → Core Web Vitals → PDP segment
  • 28-dniowe okno, sprawdzaj co tydzień

Performance budget:

  • LCP PDP (niezalogowany): < 2.0s
  • LCP PDP (zalogowany): < 2.5s
  • Total page weight PDP: < 1.5MB
  • Initial JS: < 200KB gzipped

Co zwiększa LCP w roku 2 (regresja)

Po wdrożeniu często pierwszy miesiąc - pięknie. Po 6-12 miesiącach - wynik się degraduje. Powody:

1. Nowe pluginy. Każdy plugin coś dorzuca. „Tylko jeden mały skrypt" - 50-100ms.

2. Nowe banery / promocje. Dodanie sliderem dziesięciu banerów = 10× obraz do pobrania.

3. Marketing tools. Google Tag Manager, Facebook Pixel, GA4, Hotjar - każdy 50-200ms.

4. Trzecie strony zmieniają swoje skrypty. Zewnętrzny chat zmienia loader, ten staje się większy.

5. Wzrost katalogu. 30k SKU → 80k SKU. Każde wyszukiwanie wolniejsze (search bez aktualizacji indeksu).

Performance budget i ciągły monitoring to obrona.

FAQ

Czy mogę mieć LCP 1s na Magento? Dla niezalogowanych z idealnym stackiem (Varnish + CDN + Hyvä + preload) - tak. Dla zalogowanych B2B z cenami kontraktowymi - typowo 1.5-2.0s realne.

Czy AVIF jest worth it? Tak. -25-40% wagi vs. WebP. Wszystkie nowoczesne przeglądarki wspierają. Fallback do WebP/JPG dla starszych.

Czy mogę preload kilku obrazów? Krytycznie ważnych - max 1-2. Preload jest dla najmocniejszego priorytetu, nadużycie = utrata efektu.

Czy fetchpriority działa na background-image? Nie. Tylko na <img> i <link rel="preload">. Dla background images: preload + load via JS.

Czy headless rozwiązuje problem LCP? Może. Z dobrym SSR i edge caching - tak. Z client-side rendering (CSR) - pogarsza LCP (browser musi pobrać JS, wykonać, dopiero potem renderować).

Co dalej

O autorze

Jakub Owsianka

Architekt rozwiązania w WiseB2B - silniku platform B2B. Zaczynał po stronie biznesu (własne sklepy), potem deweloper, dziś projektuje wdrożenia dla sklepów z katalogami w dziesiątkach tysięcy SKU. W ostatnich latach wdrożył AI-development w zespole i funkcjonalności oparte o AI bezpośrednio w silniku sklepu.

Pełne bio LinkedIn

Czytaj dalej w temacie wydajności

Masz pytanie do tego artykułu?

Dodatkowy kontekst, problem z własnym wdrożeniem, druga opinia - napisz wprost. Odpowiadam osobiście w 1-2 dni robocze.

kontakt@aisello.pl