Core Web Vitals w sklepie - co poprawić najpierw w kodzie i szablonie

Core Web Vitals w sklepie poprawiaj w kolejności: najpierw najsłabszy wskaźnik na szablonie z największym ruchem, zwykle LCP karty produktu i kategorii na telefonie, potem INP na stronach, gdzie klient najczęściej klika, a na końcu CLS. W kodzie oznacza to kolejno: główne zdjęcie widoczne w HTML od pierwszej odpowiedzi serwera i ładowane z wysokim priorytetem, mniej blokującego CSS i JavaScriptu, krótsze zadania JavaScript w filtrach i wariantach oraz zarezerwowane miejsce na banery, zdjęcia i czcionki.

Ten wpis jest dla właścicieli sklepów, którzy zlecają poprawki programiście, i dla programistów, którzy chcą ustalić plan prac. Nie powtarzamy tu, jak mierzyć wydajność, tylko pokazujemy, które zmiany w kodzie i szablonie dają efekt najszybciej, jak je układać w kolejności i jak wdrażać, żeby nie zepsuć koszyka ani checkoutu. Przykłady dotyczą sklepów na WooCommerce, PrestaShop, Shopify i innych platformach, bo mechanizmy przeglądarki są wszędzie te same.

[#wazne] W skrócie: kolejność poprawek Core Web Vitals w sklepie wyznaczają ruch i najsłabszy wskaźnik. Zwykle zaczyna się od LCP na karcie produktu i kategorii: zdjęcie główne w HTML, atrybut fetchpriority=high, brak leniwego ładowania, mniej blokujących zasobów. Potem INP: dzielenie długich zadań JavaScript i fasady dla czatów i wideo. Na końcu CLS: wymiary zdjęć, miejsce na banery i dopasowane czcionki. Programiści Vinson wdrażają takie poprawki w szablonach WooCommerce, PrestaShop i Shopify, testując każdą zmianę na kopii sklepu.

Core Web Vitals w sklepie - od czego zależy kolejność poprawek

Core Web Vitals to trzy wskaźniki Google opisujące doświadczenie użytkownika: LCP mierzy wyświetlenie największego elementu strony, INP - szybkość reakcji na kliknięcia i dotyk, a CLS - nieoczekiwane przesunięcia układu. Google uznaje za dobre LCP do 2,5 s, INP do 200 ms i CLS do 0,1, liczone na 75. percentylu odsłon z danych Chrome UX Report z ostatnich 28 dni (stan na wrzesień 2026 - sprawdź aktualną dokumentację Google). Jak zebrać te dane i rozłożyć wynik na części, opisujemy we wpisie wydajność sklepu internetowego - jak zmierzyć i przyspieszyć ładowanie.

Gdy pomiar jest gotowy, pojawia się pytanie, od czego zacząć. Lista zaleceń z Lighthouse ma często kilkanaście pozycji, a budżet programisty jest ograniczony. Kolejność warto ustalić, odpowiadając na trzy pytania:

Który szablon ma najwięcej ruchu, zwłaszcza płatnego? W większości sklepów są to karta produktu i kategoria, a nie strona główna.
Który wskaźnik jest na nim najsłabszy na telefonach? To on decyduje o ocenie całej grupy adresów w raporcie Search Console.
Ile szablonów naprawi jedna zmiana w kodzie? Poprawka w motywie karty produktu działa na tysiącach adresów naraz, a poprawka jednej strony landingowej - tylko na niej.

W sklepie każdy szablon ma swój typowy element, który psuje wskaźniki. Mapa poniżej pomaga przypisać problemy do konkretnych plików motywu, zanim programista zacznie zmiany:

[#chart:wpr86a]

LCP - co poprawić najpierw w szablonie karty produktu i kategorii

Web.dev dzieli LCP na cztery części i podaje orientacyjny udział każdej z nich w dobrze zoptymalizowanej stronie: czas do pierwszego bajtu około 40%, opóźnienie rozpoczęcia ładowania zasobu poniżej 10%, czas pobierania zasobu około 40% i opóźnienie renderowania poniżej 10%. Obie części z „opóźnieniem” w nazwie powinny być jak najbliżej zera. Jeśli w Twoim sklepie opóźnienia zajmują sekundę, problem leży w kodzie szablonu, a nie w samym zdjęciu czy serwerze.

Główne zdjęcie musi być widoczne w HTML od razu

Najczęstszy błąd w sklepach to zdjęcie produktu, o którym przeglądarka dowiaduje się za późno. Galeria budowana w całości przez JavaScript, zdjęcie ustawione jako tło w CSS albo baner wstawiany skryptem sprawiają, że pobieranie zaczyna się dopiero po wczytaniu i wykonaniu kodu. Web.dev zaleca, by zasób LCP był wstępnie ładowany (preload) z wysokim priorytetem, jeśli nie da się go umieścić bezpośrednio w HTML.

Nadaj atrybut fetchpriority="high" obrazowi, który ma być elementem LCP. Web.dev ostrzega, że wysoki priorytet dla więcej niż jednego lub dwóch obrazów przestaje pomagać.
Nigdy nie ładuj leniwie obrazu LCP - to zalecenie web.dev podane wprost. Sprawdź, czy motyw lub wtyczka optymalizacyjna nie dodaje loading="lazy" do wszystkich zdjęć.
Ukrytym slajdom karuzeli nadaj niski priorytet (fetchpriority="low"), żeby nie konkurowały z pierwszym zdjęciem.
Hostuj krytyczne zasoby w tej samej domenie co HTML, jeśli to możliwe - przeglądarka wykorzysta istniejące połączenie.

CSS i skrypty, które blokują renderowanie

Nawet szybko pobrane zdjęcie nie wyświetli się, dopóki przeglądarka nie przetworzy stylów i skryptów blokujących. Web.dev zaznacza, że synchroniczne skrypty w sekcji head prawie nigdy nie są potrzebne, a arkusz stylów powinien być mniejszy niż zasób LCP. W praktyce oznacza to usunięcie nieużywanego CSS z motywu, odroczenie stylów niekrytycznych i przeniesienie skryptów do ładowania z atrybutem defer. Jeśli front sklepu renderuje treść dopiero w przeglądarce, a między TTFB a pierwszym wyświetleniem treści jest duża przerwa, rozważ renderowanie po stronie serwera.

Rozmiar i format zdjęcia w kodzie szablonu

Dopiero gdy zdjęcie jest odkrywane wcześnie, opłaca się skracać czas jego pobierania. Web.dev zaleca tu trzy rzeczy: obraz dopasowany do rozmiaru wyświetlania, nowoczesny format z kompresją oraz serwowanie z CDN, także wyspecjalizowanego w obrazach. W szablonie oznacza to poprawnie ustawione atrybuty srcset i sizes, żeby telefon nie pobierał wersji przygotowanej dla dużego monitora. Częsty błąd w motywach to atrybut sizes ustawiony na pełną szerokość ekranu przy zdjęciu, które na komputerze zajmuje połowę kolumny. Przeglądarka wybiera wtedy za duży plik, a czas pobierania rośnie bez żadnej korzyści dla klienta. Sprawdź też, czy pierwsze miniatury w kategorii nie są ładowane w rozmiarze karty produktu.

[#uwaga] Łączenie i opóźnianie skryptów przyspiesza katalog, ale potrafi zepsuć checkout: pole płatności się nie wyświetla albo przycisk zamówienia nie reaguje. Optymalizacje JavaScript ustawiaj osobno dla stron katalogu i osobno dla koszyka oraz zamówienia, a po każdej zmianie składaj zamówienie testowe.

Core Web Vitals w sklepie poprawiaj w kolejności: najpierw najsłabszy wskaźnik na szablonie z największym ruchem, zwykle LCP karty produktu i kategorii na telefonie, potem INP na stronach, gdzie klient najczęściej klika, a na końcu CLS. W kodzie oznacza to kolejno: główne zdjęcie widoczne w HTML od pierwszej odpowiedzi serwera i ładowane z wysokim priorytetem, mniej blokującego CSS i JavaScriptu, krótsze zadania JavaScript w filtrach i wariantach oraz zarezerwowane miejsce na banery, zdjęcia i czcionki.

Ten wpis jest dla właścicieli sklepów, którzy zlecają poprawki programiście, i dla programistów, którzy chcą ustalić plan prac. Nie powtarzamy tu, jak mierzyć wydajność, tylko pokazujemy, które zmiany w kodzie i szablonie dają efekt najszybciej, jak je układać w kolejności i jak wdrażać, żeby nie zepsuć koszyka ani checkoutu. Przykłady dotyczą sklepów na WooCommerce, PrestaShop, Shopify i innych platformach, bo mechanizmy przeglądarki są wszędzie te same.

[#wazne] W skrócie: kolejność poprawek Core Web Vitals w sklepie wyznaczają ruch i najsłabszy wskaźnik. Zwykle zaczyna się od LCP na karcie produktu i kategorii: zdjęcie główne w HTML, atrybut fetchpriority=high, brak leniwego ładowania, mniej blokujących zasobów. Potem INP: dzielenie długich zadań JavaScript i fasady dla czatów i wideo. Na końcu CLS: wymiary zdjęć, miejsce na banery i dopasowane czcionki. Programiści Vinson wdrażają takie poprawki w szablonach WooCommerce, PrestaShop i Shopify, testując każdą zmianę na kopii sklepu.

Core Web Vitals w sklepie - od czego zależy kolejność poprawek

Core Web Vitals to trzy wskaźniki Google opisujące doświadczenie użytkownika: LCP mierzy wyświetlenie największego elementu strony, INP - szybkość reakcji na kliknięcia i dotyk, a CLS - nieoczekiwane przesunięcia układu. Google uznaje za dobre LCP do 2,5 s, INP do 200 ms i CLS do 0,1, liczone na 75. percentylu odsłon z danych Chrome UX Report z ostatnich 28 dni (stan na wrzesień 2026 - sprawdź aktualną dokumentację Google). Jak zebrać te dane i rozłożyć wynik na części, opisujemy we wpisie wydajność sklepu internetowego - jak zmierzyć i przyspieszyć ładowanie.

Gdy pomiar jest gotowy, pojawia się pytanie, od czego zacząć. Lista zaleceń z Lighthouse ma często kilkanaście pozycji, a budżet programisty jest ograniczony. Kolejność warto ustalić, odpowiadając na trzy pytania:

Który szablon ma najwięcej ruchu, zwłaszcza płatnego? W większości sklepów są to karta produktu i kategoria, a nie strona główna.
Który wskaźnik jest na nim najsłabszy na telefonach? To on decyduje o ocenie całej grupy adresów w raporcie Search Console.
Ile szablonów naprawi jedna zmiana w kodzie? Poprawka w motywie karty produktu działa na tysiącach adresów naraz, a poprawka jednej strony landingowej - tylko na niej.

W sklepie każdy szablon ma swój typowy element, który psuje wskaźniki. Mapa poniżej pomaga przypisać problemy do konkretnych plików motywu, zanim programista zacznie zmiany:

[#chart:wpr86a]

LCP - co poprawić najpierw w szablonie karty produktu i kategorii

Web.dev dzieli LCP na cztery części i podaje orientacyjny udział każdej z nich w dobrze zoptymalizowanej stronie: czas do pierwszego bajtu około 40%, opóźnienie rozpoczęcia ładowania zasobu poniżej 10%, czas pobierania zasobu około 40% i opóźnienie renderowania poniżej 10%. Obie części z „opóźnieniem” w nazwie powinny być jak najbliżej zera. Jeśli w Twoim sklepie opóźnienia zajmują sekundę, problem leży w kodzie szablonu, a nie w samym zdjęciu czy serwerze.

Główne zdjęcie musi być widoczne w HTML od razu

Najczęstszy błąd w sklepach to zdjęcie produktu, o którym przeglądarka dowiaduje się za późno. Galeria budowana w całości przez JavaScript, zdjęcie ustawione jako tło w CSS albo baner wstawiany skryptem sprawiają, że pobieranie zaczyna się dopiero po wczytaniu i wykonaniu kodu. Web.dev zaleca, by zasób LCP był wstępnie ładowany (preload) z wysokim priorytetem, jeśli nie da się go umieścić bezpośrednio w HTML.

Nadaj atrybut fetchpriority="high" obrazowi, który ma być elementem LCP. Web.dev ostrzega, że wysoki priorytet dla więcej niż jednego lub dwóch obrazów przestaje pomagać.
Nigdy nie ładuj leniwie obrazu LCP - to zalecenie web.dev podane wprost. Sprawdź, czy motyw lub wtyczka optymalizacyjna nie dodaje loading="lazy" do wszystkich zdjęć.
Ukrytym slajdom karuzeli nadaj niski priorytet (fetchpriority="low"), żeby nie konkurowały z pierwszym zdjęciem.
Hostuj krytyczne zasoby w tej samej domenie co HTML, jeśli to możliwe - przeglądarka wykorzysta istniejące połączenie.

CSS i skrypty, które blokują renderowanie

Nawet szybko pobrane zdjęcie nie wyświetli się, dopóki przeglądarka nie przetworzy stylów i skryptów blokujących. Web.dev zaznacza, że synchroniczne skrypty w sekcji head prawie nigdy nie są potrzebne, a arkusz stylów powinien być mniejszy niż zasób LCP. W praktyce oznacza to usunięcie nieużywanego CSS z motywu, odroczenie stylów niekrytycznych i przeniesienie skryptów do ładowania z atrybutem defer. Jeśli front sklepu renderuje treść dopiero w przeglądarce, a między TTFB a pierwszym wyświetleniem treści jest duża przerwa, rozważ renderowanie po stronie serwera.

Rozmiar i format zdjęcia w kodzie szablonu

Dopiero gdy zdjęcie jest odkrywane wcześnie, opłaca się skracać czas jego pobierania. Web.dev zaleca tu trzy rzeczy: obraz dopasowany do rozmiaru wyświetlania, nowoczesny format z kompresją oraz serwowanie z CDN, także wyspecjalizowanego w obrazach. W szablonie oznacza to poprawnie ustawione atrybuty srcset i sizes, żeby telefon nie pobierał wersji przygotowanej dla dużego monitora. Częsty błąd w motywach to atrybut sizes ustawiony na pełną szerokość ekranu przy zdjęciu, które na komputerze zajmuje połowę kolumny. Przeglądarka wybiera wtedy za duży plik, a czas pobierania rośnie bez żadnej korzyści dla klienta. Sprawdź też, czy pierwsze miniatury w kategorii nie są ładowane w rozmiarze karty produktu.

[#uwaga] Łączenie i opóźnianie skryptów przyspiesza katalog, ale potrafi zepsuć checkout: pole płatności się nie wyświetla albo przycisk zamówienia nie reaguje. Optymalizacje JavaScript ustawiaj osobno dla stron katalogu i osobno dla koszyka oraz zamówienia, a po każdej zmianie składaj zamówienie testowe.

INP - jak odciążyć JavaScript w szablonie sklepu

INP składa się z trzech części: opóźnienia przed rozpoczęciem obsługi zdarzenia, czasu wykonania kodu obsługi i opóźnienia prezentacji, czyli narysowania zmiany na ekranie. Web.dev definiuje długie zadanie jako każde zadanie trwające ponad 50 ms - w tym czasie przeglądarka nie reaguje na klienta. W sklepie długie zadania pojawiają się najczęściej w kilku miejscach:

filtry produktów, które przebudowują całą listę po każdym kliknięciu,
wybór wariantu, który przelicza cenę, dostępność i podmienia galerię w jednym kroku,
dodanie do koszyka z animacją mini koszyka i odświeżeniem kilku elementów nagłówka,
podpowiedzi wyszukiwarki uruchamiane przy każdym wpisanym znaku,
skrypty zewnętrzne, które wykonują się w trakcie ładowania strony, gdy klient już próbuje kliknąć.

Dzielenie długich zadań i oddawanie sterowania przeglądarce

Zasada z web.dev brzmi: najpierw zaktualizuj to, co klient widzi, a resztę pracy wykonaj w kolejnym zadaniu. Przy wyborze wariantu oznacza to natychmiastowe zaznaczenie przycisku i nowej ceny, a dopiero potem przeliczenia, zapis do analityki czy doładowanie zdjęć. Do oddania sterowania służy funkcja scheduler.yield(), którą według web.dev obsługują Chrome i Edge od wersji 129 oraz Firefox od wersji 142, ale nie Safari, więc potrzebny jest wariant zastępczy oparty na setTimeout (stan na wrzesień 2026 - sprawdź aktualną dokumentację). Unikaj też odczytywania wymiarów elementów zaraz po zmianie ich stylów w tym samym zadaniu, bo wymusza to dodatkowe przeliczenie układu.

Fasady dla czatu, wideo i widżetów

Fasada to statyczny element, który wygląda jak widżet zewnętrzny, ale nie ładuje jego kodu, dopóki klient z niego nie skorzysta. Dokumentacja Chrome opisuje przykład odtwarzacza YouTube: fasada waży 3 KB, a właściwy odtwarzacz, około 540 KB, ładuje się dopiero po kliknięciu. Ten sam wzorzec stosuje się do okien czatu. Trzeba jednak pamiętać o koszcie: dokumentacja wskazuje, że przy fasadzie czatu część funkcji, np. oznaczenie nowej wiadomości, pojawia się z opóźnieniem. Warto też wiedzieć, że Lighthouse 13 usunął osobny audyt dotyczący fasad, ale sama technika nadal skraca pracę przeglądarki na starcie strony.

Duży DOM na liście produktów

Kategoria z kilkudziesięcioma kafelkami, rozbudowane menu i ukryte warianty w kodzie każdego kafelka tworzą tysiące elementów DOM. Web.dev wskazuje, że duży DOM wymaga więcej pracy przy każdym renderowaniu, także po interakcji. Pomagają: mniej zagnieżdżonych elementów w kafelku, ładowanie menu na żądanie i właściwość CSS content-visibility, która odkłada renderowanie elementów poza ekranem.

CLS - poprawki w szablonie, które usuwają przesunięcia

Przesunięcia układu mają w sklepie zwykle kilka powtarzalnych źródeł. Każde rozwiązuje się w kodzie szablonu, a nie w ustawieniach panelu:

Element sklepu	Dlaczego przesuwa układ	Poprawka w kodzie
Zdjęcia produktów i miniatury	brak wymiarów, przeglądarka nie zna proporcji	atrybuty width i height lub CSS aspect-ratio
Pasek promocji, odliczanie, komunikat o dostawie	wstawiany skryptem nad treścią	zarezerwowane miejsce w HTML albo nakładka poza układem
Baner zgody na cookies	doklejany na górze strony	nakładka, która nie przesuwa treści
Czcionki	zamiana czcionki zastępczej na docelową	font-display, dopasowanie size-adjust, preload kroju
Opinie i produkty polecane	doładowane pod ceną	kontener z min-height lub umieszczenie niżej na stronie
Animacje mini koszyka	zmiana top lub left	animacja przez transform

Przy czcionkach web.dev proponuje font-display: optional, dobór czcionki zastępczej i właściwości size-adjust, ascent-override, descent-override oraz line-gap-override, które zbliżają wymiary czcionki zastępczej do docelowej, a także wstępne ładowanie najważniejszego kroju. Warto też sprawdzić, czy strony sklepu mogą korzystać z pamięci wstecz i dalej przeglądarki (bfcache) - strona przywrócona z tej pamięci pojawia się od razu w pełnej postaci, bez ponownych przesunięć, co ma znaczenie, gdy klient wraca z karty produktu do listy.

Najczęstsze problemy Core Web Vitals w kodzie sklepu - objaw i poprawka

Ten sam słaby wynik może mieć różne przyczyny, dlatego zanim programista zacznie zmiany, warto dopasować objaw do grupy poprawek:

[#chart:wpr86b]

Jak wdrażać poprawki Core Web Vitals, żeby nie zepsuć sprzedaży

Poprawki wydajności dotykają motywu, kolejności ładowania skryptów i sposobu wyświetlania zdjęć, czyli elementów obecnych na każdej stronie. Dlatego każdą zmianę wprowadzaj najpierw na kopii sklepu - jak ją przygotować, opisujemy we wpisie środowisko testowe sklepu - jak zbudować staging. Na kopii porównujesz wynik laboratoryjny przed zmianą i po niej, przechodzisz ścieżkę zakupu i dopiero wtedy wdrażasz poprawkę. Przykładowy cykl pracy:

[#chart:wpr86c]

[#tip] Wdrażaj jedną grupę poprawek naraz i zapisuj datę wdrożenia. Dane terenowe z 28 dni zmieniają się powoli, więc gdy w jednym wdrożeniu zmienisz zdjęcia, czcionki i skrypty, nie dowiesz się, która zmiana pomogła, a która zaszkodziła.

Do zlecenia dla programisty dołącz listę adresów do testów, wyniki pomiaru wyjściowego i kryterium odbioru, np. LCP karty produktu na telefonie w teście laboratoryjnym poniżej ustalonej wartości przy działającym koszyku i płatnościach. Bez takiego kryterium trudno ocenić, czy prace są skończone.

Szablon na platformie SaaS i sklep na własnym serwerze

Na platformach abonamentowych, takich jak Shopify czy Shoper, serwer i CDN są po stronie dostawcy, więc pole do pracy to kod motywu, aplikacje i skrypty zewnętrzne. Na WooCommerce i PrestaShop dochodzą konfiguracja serwera, pamięci podręcznej i wtyczek optymalizacyjnych, które same potrafią wprowadzić problemy, np. leniwe ładowanie zdjęcia głównego. Konkretne kroki dla sklepu na WordPressie zebraliśmy w tekście szybkość sklepu WooCommerce - jak poprawić Core Web Vitals krok po kroku. Niezależnie od platformy zasada jest ta sama: poprawka w szablonie karty produktu działa na cały katalog, więc to tam warto zacząć.

Jak Vinson pomaga poprawić Core Web Vitals w sklepie

Zapewniamy wsparcie programistyczne dla sklepów i sprzedawców: integracje, automatyzacje, poprawki i rozwój sklepów oraz narzędzi. Przy Core Web Vitals zaczynamy od mapy szablonów i najsłabszego wskaźnika, a potem wdrażamy poprawki w kodzie motywu: kolejność i priorytety ładowania zdjęć, porządek w CSS i skryptach, fasady dla widżetów, podział długich zadań JavaScript i rezerwację miejsca na dynamiczne elementy. Każdą zmianę testujemy na kopii sklepu z zamówieniem testowym. Szczegóły znajdziesz na stronie Wsparcie programistyczne dla e-commerce.

Najczęściej zadawane pytania

Który wskaźnik Core Web Vitals poprawiać w sklepie najpierw?

Ten, który jest najsłabszy na szablonie z największym ruchem, zwykle na karcie produktu lub kategorii na telefonie. W wielu sklepach jest to LCP, bo największym elementem strony jest zdjęcie produktu. Jeśli LCP jest dobre, a INP słabe, zacznij od skryptów w filtrach, wariantach i widżetach.

Czy zdjęcie produktu może mieć atrybut loading="lazy"?

Zdjęcie główne widoczne od razu po wejściu na stronę - nie. Web.dev zaleca, by nigdy nie ładować leniwie obrazu LCP, a nadać mu wysoki priorytet atrybutem fetchpriority="high". Leniwe ładowanie sprawdza się przy zdjęciach niżej na stronie, np. w produktach polecanych.

Co najczęściej psuje INP w sklepie internetowym?

Długie zadania JavaScript, czyli trwające ponad 50 ms, uruchamiane przy kliknięciu filtra, wyborze wariantu lub dodaniu do koszyka, oraz skrypty zewnętrzne ładowane na starcie strony. Pomaga podział pracy na mniejsze zadania i ładowanie czatów czy wideo dopiero po interakcji klienta.

Jak usunąć przesunięcia układu (CLS) w sklepie?

Nadaj zdjęciom wymiary lub proporcje, zarezerwuj miejsce na paski promocji i bloki doładowywane skryptem, wyświetlaj baner zgód jako nakładkę i dopasuj czcionkę zastępczą do docelowej. Animacje w nagłówku i mini koszyku rób przez transform, a nie zmianę położenia elementu.

Po jakim czasie poprawki Core Web Vitals będą widoczne w Google?

Test laboratoryjny pokaże zmianę od razu, ale dane od użytkowników w raportach Google obejmują 28 dni, więc pełny efekt widać po kilku tygodniach. Dlatego warto zapisywać daty wdrożeń i porównywać wyniki po upływie tego okresu.

Core Web Vitals w sklepie poprawia się najskuteczniej w szablonach, od najsłabszego wskaźnika na stronach z największym ruchem. Jeśli chcesz ustalić kolejność prac i wdrożyć poprawki w kodzie bez ryzyka dla koszyka, sprawdź wsparcie programistyczne Vinson.

INP - jak odciążyć JavaScript w szablonie sklepu

INP składa się z trzech części: opóźnienia przed rozpoczęciem obsługi zdarzenia, czasu wykonania kodu obsługi i opóźnienia prezentacji, czyli narysowania zmiany na ekranie. Web.dev definiuje długie zadanie jako każde zadanie trwające ponad 50 ms - w tym czasie przeglądarka nie reaguje na klienta. W sklepie długie zadania pojawiają się najczęściej w kilku miejscach:

filtry produktów, które przebudowują całą listę po każdym kliknięciu,
wybór wariantu, który przelicza cenę, dostępność i podmienia galerię w jednym kroku,
dodanie do koszyka z animacją mini koszyka i odświeżeniem kilku elementów nagłówka,
podpowiedzi wyszukiwarki uruchamiane przy każdym wpisanym znaku,
skrypty zewnętrzne, które wykonują się w trakcie ładowania strony, gdy klient już próbuje kliknąć.

Dzielenie długich zadań i oddawanie sterowania przeglądarce

Zasada z web.dev brzmi: najpierw zaktualizuj to, co klient widzi, a resztę pracy wykonaj w kolejnym zadaniu. Przy wyborze wariantu oznacza to natychmiastowe zaznaczenie przycisku i nowej ceny, a dopiero potem przeliczenia, zapis do analityki czy doładowanie zdjęć. Do oddania sterowania służy funkcja scheduler.yield(), którą według web.dev obsługują Chrome i Edge od wersji 129 oraz Firefox od wersji 142, ale nie Safari, więc potrzebny jest wariant zastępczy oparty na setTimeout (stan na wrzesień 2026 - sprawdź aktualną dokumentację). Unikaj też odczytywania wymiarów elementów zaraz po zmianie ich stylów w tym samym zadaniu, bo wymusza to dodatkowe przeliczenie układu.

Fasady dla czatu, wideo i widżetów

Fasada to statyczny element, który wygląda jak widżet zewnętrzny, ale nie ładuje jego kodu, dopóki klient z niego nie skorzysta. Dokumentacja Chrome opisuje przykład odtwarzacza YouTube: fasada waży 3 KB, a właściwy odtwarzacz, około 540 KB, ładuje się dopiero po kliknięciu. Ten sam wzorzec stosuje się do okien czatu. Trzeba jednak pamiętać o koszcie: dokumentacja wskazuje, że przy fasadzie czatu część funkcji, np. oznaczenie nowej wiadomości, pojawia się z opóźnieniem. Warto też wiedzieć, że Lighthouse 13 usunął osobny audyt dotyczący fasad, ale sama technika nadal skraca pracę przeglądarki na starcie strony.

Duży DOM na liście produktów

Kategoria z kilkudziesięcioma kafelkami, rozbudowane menu i ukryte warianty w kodzie każdego kafelka tworzą tysiące elementów DOM. Web.dev wskazuje, że duży DOM wymaga więcej pracy przy każdym renderowaniu, także po interakcji. Pomagają: mniej zagnieżdżonych elementów w kafelku, ładowanie menu na żądanie i właściwość CSS content-visibility, która odkłada renderowanie elementów poza ekranem.

CLS - poprawki w szablonie, które usuwają przesunięcia

Przesunięcia układu mają w sklepie zwykle kilka powtarzalnych źródeł. Każde rozwiązuje się w kodzie szablonu, a nie w ustawieniach panelu:

Element sklepu	Dlaczego przesuwa układ	Poprawka w kodzie
Zdjęcia produktów i miniatury	brak wymiarów, przeglądarka nie zna proporcji	atrybuty width i height lub CSS aspect-ratio
Pasek promocji, odliczanie, komunikat o dostawie	wstawiany skryptem nad treścią	zarezerwowane miejsce w HTML albo nakładka poza układem
Baner zgody na cookies	doklejany na górze strony	nakładka, która nie przesuwa treści
Czcionki	zamiana czcionki zastępczej na docelową	font-display, dopasowanie size-adjust, preload kroju
Opinie i produkty polecane	doładowane pod ceną	kontener z min-height lub umieszczenie niżej na stronie
Animacje mini koszyka	zmiana top lub left	animacja przez transform

Przy czcionkach web.dev proponuje font-display: optional, dobór czcionki zastępczej i właściwości size-adjust, ascent-override, descent-override oraz line-gap-override, które zbliżają wymiary czcionki zastępczej do docelowej, a także wstępne ładowanie najważniejszego kroju. Warto też sprawdzić, czy strony sklepu mogą korzystać z pamięci wstecz i dalej przeglądarki (bfcache) - strona przywrócona z tej pamięci pojawia się od razu w pełnej postaci, bez ponownych przesunięć, co ma znaczenie, gdy klient wraca z karty produktu do listy.

Najczęstsze problemy Core Web Vitals w kodzie sklepu - objaw i poprawka

Ten sam słaby wynik może mieć różne przyczyny, dlatego zanim programista zacznie zmiany, warto dopasować objaw do grupy poprawek:

[#chart:wpr86b]

Jak wdrażać poprawki Core Web Vitals, żeby nie zepsuć sprzedaży

Poprawki wydajności dotykają motywu, kolejności ładowania skryptów i sposobu wyświetlania zdjęć, czyli elementów obecnych na każdej stronie. Dlatego każdą zmianę wprowadzaj najpierw na kopii sklepu - jak ją przygotować, opisujemy we wpisie środowisko testowe sklepu - jak zbudować staging. Na kopii porównujesz wynik laboratoryjny przed zmianą i po niej, przechodzisz ścieżkę zakupu i dopiero wtedy wdrażasz poprawkę. Przykładowy cykl pracy:

[#chart:wpr86c]

[#tip] Wdrażaj jedną grupę poprawek naraz i zapisuj datę wdrożenia. Dane terenowe z 28 dni zmieniają się powoli, więc gdy w jednym wdrożeniu zmienisz zdjęcia, czcionki i skrypty, nie dowiesz się, która zmiana pomogła, a która zaszkodziła.

Do zlecenia dla programisty dołącz listę adresów do testów, wyniki pomiaru wyjściowego i kryterium odbioru, np. LCP karty produktu na telefonie w teście laboratoryjnym poniżej ustalonej wartości przy działającym koszyku i płatnościach. Bez takiego kryterium trudno ocenić, czy prace są skończone.

Szablon na platformie SaaS i sklep na własnym serwerze

Na platformach abonamentowych, takich jak Shopify czy Shoper, serwer i CDN są po stronie dostawcy, więc pole do pracy to kod motywu, aplikacje i skrypty zewnętrzne. Na WooCommerce i PrestaShop dochodzą konfiguracja serwera, pamięci podręcznej i wtyczek optymalizacyjnych, które same potrafią wprowadzić problemy, np. leniwe ładowanie zdjęcia głównego. Konkretne kroki dla sklepu na WordPressie zebraliśmy w tekście szybkość sklepu WooCommerce - jak poprawić Core Web Vitals krok po kroku. Niezależnie od platformy zasada jest ta sama: poprawka w szablonie karty produktu działa na cały katalog, więc to tam warto zacząć.

Jak Vinson pomaga poprawić Core Web Vitals w sklepie

Zapewniamy wsparcie programistyczne dla sklepów i sprzedawców: integracje, automatyzacje, poprawki i rozwój sklepów oraz narzędzi. Przy Core Web Vitals zaczynamy od mapy szablonów i najsłabszego wskaźnika, a potem wdrażamy poprawki w kodzie motywu: kolejność i priorytety ładowania zdjęć, porządek w CSS i skryptach, fasady dla widżetów, podział długich zadań JavaScript i rezerwację miejsca na dynamiczne elementy. Każdą zmianę testujemy na kopii sklepu z zamówieniem testowym. Szczegóły znajdziesz na stronie Wsparcie programistyczne dla e-commerce.

Najczęściej zadawane pytania

Który wskaźnik Core Web Vitals poprawiać w sklepie najpierw?

Ten, który jest najsłabszy na szablonie z największym ruchem, zwykle na karcie produktu lub kategorii na telefonie. W wielu sklepach jest to LCP, bo największym elementem strony jest zdjęcie produktu. Jeśli LCP jest dobre, a INP słabe, zacznij od skryptów w filtrach, wariantach i widżetach.

Czy zdjęcie produktu może mieć atrybut loading="lazy"?

Zdjęcie główne widoczne od razu po wejściu na stronę - nie. Web.dev zaleca, by nigdy nie ładować leniwie obrazu LCP, a nadać mu wysoki priorytet atrybutem fetchpriority="high". Leniwe ładowanie sprawdza się przy zdjęciach niżej na stronie, np. w produktach polecanych.

Co najczęściej psuje INP w sklepie internetowym?

Długie zadania JavaScript, czyli trwające ponad 50 ms, uruchamiane przy kliknięciu filtra, wyborze wariantu lub dodaniu do koszyka, oraz skrypty zewnętrzne ładowane na starcie strony. Pomaga podział pracy na mniejsze zadania i ładowanie czatów czy wideo dopiero po interakcji klienta.

Jak usunąć przesunięcia układu (CLS) w sklepie?

Nadaj zdjęciom wymiary lub proporcje, zarezerwuj miejsce na paski promocji i bloki doładowywane skryptem, wyświetlaj baner zgód jako nakładkę i dopasuj czcionkę zastępczą do docelowej. Animacje w nagłówku i mini koszyku rób przez transform, a nie zmianę położenia elementu.

Po jakim czasie poprawki Core Web Vitals będą widoczne w Google?

Test laboratoryjny pokaże zmianę od razu, ale dane od użytkowników w raportach Google obejmują 28 dni, więc pełny efekt widać po kilku tygodniach. Dlatego warto zapisywać daty wdrożeń i porównywać wyniki po upływie tego okresu.

Core Web Vitals w sklepie poprawia się najskuteczniej w szablonach, od najsłabszego wskaźnika na stronach z największym ruchem. Jeśli chcesz ustalić kolejność prac i wdrożyć poprawki w kodzie bez ryzyka dla koszyka, sprawdź wsparcie programistyczne Vinson.

Core Web Vitals w sklepie - co poprawić najpierw w kodzie i szablonie