Core Web Vitals Shoper: jak poprawić LCP, INP i CLS
Rozpocznij projekt
Blog → Shoper
Shoper 28 kwietnia 2026

Core Web Vitals Shoper: jak poprawić LCP, INP i CLS

Core Web Vitals w Shoper: progi LCP, INP i CLS, dane rzeczywiste i laboratoryjne oraz plan poprawy obrazów, JavaScriptu, fontów i układu.

Adrian Kozicki — autor artykułu, strateg SEO e-commerce
Adrian Kozicki Strateg SEO e-commerce · SEOmmerce
CWVPerformanceShoperLCPPageSpeed

Core Web VitalsCzas, po którym ładuje się największy widoczny element strony — kluczowy wskaźnik szybkości i czynnik rankingowy. Pełna definicja w słowniku → w Shoper trzeba diagnozować jak trzy różne problemy: szybkość głównej treści, responsywność interakcji i stabilność układu. Jeden zielony wynik Google PageSpeed Insights nie opisuje doświadczenia wszystkich klientów. Shoper jako SaaS rozdziela odpowiedzialność między platformę, motyw Storefront lub RWD, konfigurację katalogu i zewnętrzne skrypty, dlatego zaczynamy od danych dla konkretnego typu strony, urządzenia i metryki.

Core Web Vitals: LCP, INP i CLS

Google Core Web Vitals to zestaw metryk polowych opisujących doświadczenie rzeczywistych użytkowników. Ocena jest prowadzona na 75. percentylu wizyt. Dobre wartości to:

MetrykaCo opisujeDobry wynik
LCP — Largest Contentful Paintczas wyświetlenia największego elementu treścido 2,5 s
INP — Interaction to Next Paintopóźnienie reakcji strony na interakcjedo 200 ms
CLS — Cumulative Layout Shiftnieoczekiwane przesunięcia układudo 0,1

FID został zastąpiony przez INP jako podstawowy wskaźnik responsywności. Nie dopisuj starego FID do aktualnego raportu jako czwartej równorzędnej metryki. W sklepie wynik może różnić się między stroną główną, kategorią, kartą produktu i koszykiem, bo każdy szablon ładuje inne obrazy, moduły oraz JavaScript.

Jak sprawdzić Core Web Vitals sklepu Shoper

CrUX i PageSpeed Insights pokazują dane polowe, gdy dla danego adresu lub całego źródła istnieje wystarczająca próbka. Raport Core Web Vitals w Google Search Console grupuje podobne adresy i pomaga ustalić skalę problemu. Test laboratoryjny w Lighthouse lub Chrome DevTools nie zastępuje danych użytkowników, ale pomaga odtworzyć waterfall, długie zadania JavaScript i element LCP.

Narzędzie: https://pagespeed.web.dev → wklej URL → zakładka „Field Data”.

Jeżeli także GSC nie ma wystarczającej próbki, raportujemy wynik laboratoryjny jako diagnozę, nie jako potwierdzenie zaliczenia Core Web Vitals. Dla zmian szablonu warto dodać własny pomiar RUM, aby obserwować LCP, INP i CLS w prawdziwych sesjach bez czekania na pełne okno CrUX.

Praktyczny audyt obejmuje co najmniej stronę główną, kategorię, produkt oraz koszyk na urządzeniu mobilnym. Dla każdego szablonu zapisujemy element LCP, rozkład czasu, źródła przesunięć CLS, długie zadania głównego wątku i skrypty zewnętrzne.

Jak poprawić LCP w Shoper

LCP nie mówi, co jest przyczyną opóźnienia. Najpierw rozdziel czas odpowiedzi serwera, opóźnienie wykrycia zasobu, pobieranie zasobu i czas renderowania. Dopiero wtedy wybierz zmianę.

Obraz LCP i priorytet ładowania

Obrazu w pierwszym widoku nie ładuj leniwie. Powinien być widoczny w początkowym HTML albo wcześnie preloadowany, mieć odpowiedni wariant rozmiaru i — po potwierdzeniu, że to element LCP — fetchpriority="high". Nie nadawaj wysokiego priorytetu całej galerii, bo zasoby zaczną konkurować o łącze.

<img
  src="hero-960.webp"
  srcset="hero-640.webp 640w, hero-960.webp 960w, hero-1440.webp 1440w"
  sizes="100vw"
  width="1440"
  height="720"
  loading="eager"
  fetchpriority="high"
  alt="Opis zawartości grafiki"
>

Obrazy produktów poza pierwszym viewportem mogą korzystać z loading="lazy" i decoding="async". Zawsze zachowaj wymiary lub proporcje, aby poprawa LCP nie pogorszyła CLS.

Fonty bez blokowania pierwszego widoku

Sprawdź, czy font rzeczywiście znajduje się w łańcuchu krytycznym, ile wariantów jest pobieranych i czy preload wskazuje dokładnie używany plik. Nie preloaduj wszystkich wag.

Modyfikację wykonuj w kontrolowanej warstwie motywu, jeżeli dany wariant Shopera udostępnia taki zakres. Preloaduj wyłącznie faktycznie używany plik i wagę:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="preload" as="font" type="font/woff2" 
  href="TWÓJ_URL_CZCIONKI.woff2" crossorigin>

Jeśli używasz Google Fonts przez @import w CSS — zmień na <link> w <head> z &display=swap.

Fix 2: Lazy load dla obrazów

Lazy loading stosuj do obrazów poza pierwszym viewportem. Obrazu LCP nie odkładaj; nadaj mu prawidłowy priorytet, wymiary oraz wariant dopasowany do viewportu.

W edytorze szablonu Shoper znajdź tagi <img> w listingach produktów i dodaj:

<img src="..." alt="..." loading="lazy" decoding="async">

Obrazy hero sekcji (above the fold) — loading="eager", reszta — loading="lazy".

Po wdrożeniu porównaj ten sam typ strony, urządzenie i warunki testu. Liczba miniatur w pierwszym viewportcie zależy od układu, więc nie kopiuj jednego progu do każdego sklepu.

CSS krytyczny i renderowanie

Krytyczny CSS powinien być częścią kontrolowanej warstwy motywu lub procesu budowania. Nie wstrzykuj stylów odpowiedzialnych za pierwsze renderowanie przez GTM.

Critical CSS to style potrzebne do wyrenderowania pierwszego widoku. Jego zakres wyznacza pomiar i struktura motywu, nie uniwersalny limit rozmiaru.

Narzędzie do generowania critical CSS: criticalcss.com lub purgecss lokalnie.

Po zbudowaniu i przetestowaniu motywu niewielki zestaw stylów krytycznych może trafić do <head>. Resztę CSS ładuj bez ryzyka pozostawienia strony bez stylów:

<link rel="stylesheet" href="style.css" media="print" 
  onload="this.media='all'">

Wpływ zależy od obecnego CSS, cache i elementu LCP. Sprawdź regresje wizualne oraz zachowanie bez JavaScript.

Fix 4: Obrazy produktowe — format, warianty i wymiary

Sprawdź format, rozmiary wariantów, kompresję i faktyczny adres zwracany przez sklep. Nie zakładaj obsługi konkretnego formatu na podstawie rozszerzenia albo niezweryfikowanej wersji platformy.

Dodaj prawidłowe width i height albo zarezerwuj miejsce przez aspect-ratio. Przeglądarka powinna znać proporcje obrazu przed pobraniem pliku, aby ograniczyć przesunięcia układu.

Jak poprawić INP i reakcję sklepu

INP mierzy czas od interakcji do następnego wyświetlenia odpowiedzi. W laboratorium nie da się odtworzyć rozkładu prawdziwych interakcji; Total Blocking Time jest jedynie wskaźnikiem pomocniczym. W Shoperze sprawdzamy przede wszystkim skrypty marketingowe, widgety, obsługę wariantów, filtrów, wyszukiwarki i przycisku „do koszyka”. Długie zadania JavaScript, wielokrotne nasłuchiwacze i kod uruchamiany po każdej zmianie DOM blokują główny wątek.

Najpierw usuń albo ogranicz kod, który nie tworzy wartości. Potem podziel długą pracę, odłóż zadania niekrytyczne i pokaż natychmiastową informację zwrotną. Nie przenoś automatycznie każdego skryptu do GTM — nadal wykona się w przeglądarce i może obciążyć interakcję.

Jak poprawić CLS w motywie Shoper

CLS pogarszają elementy, które pojawiają się lub zmieniają rozmiar po rozpoczęciu renderowania: obrazy bez wymiarów, banery, komunikaty dostawy, widgety opinii, fonty i galerie. Rezerwuj miejsce przed pobraniem treści przez width i height, aspect-ratio albo stabilny kontener.

Szczególną uwagę poświęć karcie produktu. Zmiana wariantu nie powinna przeskakiwać przycisku zakupu, a doładowanie ceny, dostępności lub rat nie może przesuwać elementu, który użytkownik właśnie zamierza kliknąć. CLS z danych polowych może być gorszy od testu Lighthouse, bo pojawia się również po interakcjach i podczas dłuższej sesji.

Core Web Vitals a SEO i sprzedaż

Core Web Vitals są częścią szerszej oceny page experience, ale Google podkreśla, że dobry wynik nie gwarantuje wysokich pozycji. Treść odpowiadająca na potrzebę użytkownika pozostaje ważniejsza niż pogoń za perfekcyjnym score. Dla sklepu wydajność jest jednocześnie problemem UX: wolna reakcja filtra, skaczący przycisk albo opóźnione zdjęcie utrudniają zakup niezależnie od wpływu na SEO.

Jeżeli obecny motyw RWD ogranicza kontrolę nad krytyczną ścieżką, osobną decyzją może być przejście na Shoper Storefront. Sama zmiana technologii nie jest jednak dowodem poprawy — wymaga pomiaru przed i po. Szerszą kontrolę adresów, treści, schema i analityki opisuje SEO nowego Storefrontu.

Protokół wyniku przed i po zmianie

PoleCo zapisać
Typ stronyStrona główna, kategoria albo produkt
Element LCPKonkretny selektor i zasób
Dane poloweZakres dat, urządzenie i 75. percentyl
LaboratoriumProfil sieci, CPU, liczba prób i mediana
ZmianaJeden opisany wariant wdrożenia
RegresjeCLS, INP, błędy obrazu, wygląd i checkout

Taki zapis pozwala wykazać efekt konkretnej decyzji bez publikowania anonimowych benchmarków.

Gdzie sprawdzić granicę odpowiedzialności

  • TTFB i nagłówki cache — zmierz odpowiedzi oraz sprawdź aktualny kontrakt platformy.
  • CDN i protokół — potwierdź w dokumentacji i z pomocą techniczną Shopera.
  • Kod motywu, obrazy i skrypty zewnętrzne — zinwentaryzuj elementy, które kontrolujesz.

Pełny audyt kończy się backlogiem zmian z dowodem problemu, właścicielem warstwy i testem odbioru. Część zadań wykona zespół motywu, część właściciel integracji, a ograniczenia platformy wymagają potwierdzenia w aktualnej dokumentacji lub u wsparcia Shopera.

Źródła techniczne


Jeśli nie wiesz, od czego zacząć, zamów audyt sklepu Shoper. Wskażemy problematyczny szablon, element LCP, źródła INP i CLS oraz kolejność testów — bez deklarowania wyniku przed pomiarem.

Źródła referencyjne i dalsza weryfikacja

Materiały poniżej prowadzą do dokumentacji właścicieli platform i instytucji. Są punktem kontroli aktualności, a nie automatycznym potwierdzeniem każdego zdania w artykule.

Opublikowano: · Zaktualizowano:

Masz pytania do tego artykułu lub chcesz żebym spojrzał na Twój sklep?

Napisz do CyberSolus →

Więcej z bloga

Wróć do bazy wiedzy.

← Wszystkie artykuły