Core Web Vitals w sklepie internetowym – LCP, INP i CLS w praktyce

LCP w sklepie – jak przyspieszyć ładowanie głównej treści

Na karcie produktu elementem LCP jest zwykle główne zdjęcie, na stronie głównej baner, a na liście kategorii czasem nagłówek lub pierwszy rząd miniatur. Web.dev wymienia jako kandydatów do LCP m.in. obrazy, klatki wideo, elementy z obrazem w tle oraz bloki tekstu. Pierwszy krok to więc sprawdzenie w PageSpeed Insights lub DevTools, który element jest twoim LCP, bo od tego zależą dalsze działania.

• Zdjęcie główne o rozsądnej wadze – nowoczesny format, kompresja i rozmiar dopasowany do ekranu. Szczegóły opisujemy w artykule o zdjęciach produktów w Shoperze, a zasady są uniwersalne dla każdej platformy.

• Bez leniwego ładowania pierwszego zdjęcia – lazy loading jest dobry dla zdjęć poniżej pierwszego ekranu, ale opóźnia zdjęcie, które klient ma zobaczyć od razu.

• Wysoki priorytet dla elementu LCP – przeglądarka powinna wiedzieć, że to zdjęcie jest najważniejsze, i pobrać je przed mniej istotnymi zasobami.

• Krótki czas odpowiedzi serwera – jeśli pierwszy bajt strony przychodzi późno, wszystko inne też się opóźnia.

• Mniej zasobów blokujących renderowanie – ciężkie arkusze stylów i skrypty w nagłówku strony wstrzymują wyświetlanie treści.

[#przyklad] Sklep z obuwiem ma na kartach produktów karuzelę z pięcioma zdjęciami w wysokiej rozdzielczości, ładowanymi przez skrypt po wczytaniu strony. W PageSpeed Insights elementem LCP jest pierwsze zdjęcie karuzeli. Po zmianie pierwszego zdjęcia na zwykły obraz w kodzie HTML, dopasowaniu jego rozmiaru do telefonów i wyłączeniu dla niego leniwego ładowania LCP w danych laboratoryjnych wyraźnie spada. Dane z terenu w Search Console potwierdzają poprawę dopiero po kilku tygodniach.

INP w sklepie – jak poprawić reakcję na kliknięcia

INP mierzy czas od interakcji do momentu, w którym przeglądarka może wyświetlić następną klatkę z reakcją strony. W sklepie najczęściej cierpią interakcje, za którymi stoi dużo JavaScriptu: filtry bez przeładowania strony, wybór wariantu z przeliczeniem ceny i dostępności, otwieranie koszyka bocznego, wyszukiwarka z podpowiedziami. Web.dev rozkłada opóźnienie na trzy części: czas oczekiwania na rozpoczęcie obsługi zdarzenia, czas wykonania kodu i czas do wyświetlenia kolejnej klatki.

1. Policz skrypty zewnętrzne – piksele reklamowe, czaty, widżety opinii, narzędzia do nagrywania sesji i testów A/B konkurują o ten sam wątek główny przeglądarki. Usuń te, z których nikt nie korzysta.

2. Opóźnij to, co nie jest potrzebne od razu – czat czy widżet z rekomendacjami mogą ładować się po interakcji lub po wczytaniu najważniejszej treści.

3. Dziel długie zadania – jeśli po kliknięciu filtra wykonuje się jeden duży blok kodu, programista może podzielić go na mniejsze części, tak by przeglądarka szybciej pokazała reakcję.

4. Daj natychmiastową informację zwrotną – stan ładowania przycisku czy wyszarzenie listy podczas filtrowania pokazują klientowi, że kliknięcie zadziałało.

Szczególną uwagę zwróć na koszyk i proces zamówienia, bo tam każde opóźnienie po kliknięciu kosztuje najwięcej. Jak uprościć ten etap, opisujemy w artykule o koszyku i składaniu zamówienia w Shoperze. W sklepach na platformach abonamentowych wpływ na kod jest ograniczony, ale liczba aplikacji, wtyczek i skryptów marketingowych zależy od ciebie. Z naszej praktyki wynika, że przegląd tagów i aplikacji to często najszybszy sposób na poprawę responsywności, bez ingerencji w szablon.

CLS w sklepie – jak zatrzymać skaczący układ strony

CLS liczy nieoczekiwane przesunięcia widocznych elementów. Web.dev wymienia typowe przyczyny: obrazy i filmy bez znanych wymiarów, czcionki, które po załadowaniu mają inną wielkość niż zastępcze, oraz treści dodawane dynamicznie nad istniejącymi elementami. Przesunięcia, które następują w ciągu 500 ms od interakcji użytkownika, nie są liczone, więc rozwinięcie opisu po kliknięciu nie szkodzi wynikowi.

• Wymiary zdjęć i miniatur – atrybuty szerokości i wysokości lub zarezerwowane miejsce w stylach sprawiają, że przeglądarka zostawia miejsce, zanim obraz się wczyta.

• Belki promocyjne i banery – pasek z kodem rabatowym doładowany nad menu przesuwa całą stronę. Lepiej zarezerwować dla niego miejsce lub wyświetlać go jako nakładkę.

• Baner zgody na cookies – powinien przykrywać treść, a nie wypychać ją w dół.

• Bloki doładowywane skryptem – rekomendacje, opinie i informacje o dostawie powinny mieć z góry określoną wysokość.

• Czcionki – dobrze dobrana czcionka zastępcza ogranicza przeskok tekstu po wczytaniu właściwej.

Wykres – typowe problemy z Core Web Vitals w sklepie i sposoby ich naprawy. [#chart:se27b]

Najczęstsze błędy przy poprawie Core Web Vitals

• Optymalizacja wyłącznie pod wynik punktowy – wynik z testu laboratoryjnego to wskazówka diagnostyczna, a nie ocena, którą widzi Google. Liczą się dane z terenu.

• Testowanie tylko na komputerze – większość problemów wychodzi na telefonach, dlatego zawsze sprawdzaj wersję mobilną. Podpowiedzi znajdziesz w artykule o wersji mobilnej sklepu na Shoperze.

• Poprawianie pojedynczych adresów zamiast szablonów – w sklepie problem prawie zawsze tkwi w szablonie produktu, kategorii lub w elemencie wspólnym dla całej witryny.

• Dokładanie kolejnych aplikacji bez kontroli – każda nowa wtyczka może pogorszyć INP i LCP, nawet jeśli pojedynczo wydaje się lekka.

• Brak pomiaru efektów w ruchu – po wdrożeniu zmian porównaj nie tylko wskaźniki, ale też kliknięcia i wyświetlenia w raporcie Skuteczność oraz konwersję na urządzeniach mobilnych.

Pamiętaj też, że wydajność to tylko jeden z elementów, które składają się na widoczność sklepu. Szerszy obraz tego, jak działa pozycjonowanie e-commerce, przedstawiamy w przewodniku SEO dla sklepu internetowego.

Core Web Vitals krok po kroku – plan działań dla sklepu

Najlepsze efekty daje praca według typów stron i według wpływu na sprzedaż. Zacznij od szablonów, które generują najwięcej wejść z wyszukiwarki i najwięcej transakcji: zwykle są to karty produktów i kategorie. Strona regulaminu ze słabym CLS może poczekać.

1. Otwórz raport Podstawowe wskaźniki internetowe w Search Console i zanotuj, które grupy adresów mają status słaby lub wymagający poprawy na urządzeniach mobilnych.

2. Dla każdej grupy wybierz reprezentatywny adres i sprawdź go w PageSpeed Insights, porównując dane z terenu i z laboratorium.

3. Ustal element LCP, najwolniejsze interakcje i źródła przesunięć układu.

4. Przygotuj listę poprawek w podziale na zmiany w treści (zdjęcia, banery), w konfiguracji (aplikacje, skrypty) i w kodzie szablonu.

5. Wdrażaj zmiany pojedynczo i sprawdzaj ich efekt w teście laboratoryjnym, a po kilku tygodniach w danych z terenu.

6. Ustal zasady na przyszłość, np. maksymalną wagę banera czy obowiązek akceptacji nowych skryptów marketingowych.

[#checklista] Element LCP zidentyfikowany na kartach produktów, kategoriach i stronie głównej; pierwsze zdjęcie bez lazy loading; zdjęcia i banery z wymiarami; baner cookies jako nakładka; lista skryptów zewnętrznych przejrzana; dane z terenu sprawdzone osobno dla telefonów i komputerów; zmiany wdrażane pojedynczo; raport w Search Console kontrolowany co miesiąc.

Jeśli prowadzisz sklep na Shoperze lub planujesz wdrożenie sklepu na tej platformie, praktyczne ustawienia opisujemy w artykule o szybkości sklepu na Shoperze. Warto też pamiętać, że szybkość serwera wpływa nie tylko na użytkowników, ale i na to, ile stron może przeskanować Google, o czym piszemy w artykule o crawl budget w dużym sklepie. Wydajność to również stały punkt naszego audytu SEO sklepu.

Najczęściej zadawane pytania

Jakie są dobre wartości Core Web Vitals?

Według web.dev dobre wartości to LCP do 2,5 sekundy, INP do 200 milisekund i CLS do 0,1. Ocenia się je dla 75. percentyla wizyt, osobno na urządzeniach mobilnych i komputerach.

Czy słabe Core Web Vitals mogą obniżyć pozycje sklepu?

Google potwierdza, że Core Web Vitals są używane przez systemy rankingowe, ale najważniejsza pozostaje trafność treści. Słabe wskaźniki rzadko są jedyną przyczyną niskich pozycji, a dobre wyniki nie gwarantują miejsca na szczycie wyników.

Dlaczego PageSpeed Insights pokazuje inne wyniki niż Search Console?

PageSpeed Insights pokazuje dane dla konkretnego adresu i dodatkowo wynik testu laboratoryjnego, a Search Console grupuje podobne adresy i opiera się na danych z ostatnich 28 dni. Wynik punktowy w PageSpeed Insights pochodzi z testu laboratoryjnego i nie jest oceną Core Web Vitals.

Co to jest INP i czym różni się od FID?

INP mierzy opóźnienie reakcji na wszystkie interakcje w trakcie wizyty i zwykle raportuje najgorszą z nich. FID mierzył tylko opóźnienie pierwszej interakcji. INP zastąpił FID w zestawie Core Web Vitals w 2024 roku.

Dlaczego mój sklep nie ma danych w raporcie Core Web Vitals?

Raport pokazuje tylko grupy adresów, dla których jest wystarczająco dużo danych z prawdziwych wizyt w Chrome. Nowe lub małe sklepy często ich nie mają. Wtedy warto korzystać z testów laboratoryjnych i własnego pomiaru.

Ile trwa poprawa Core Web Vitals w Search Console?

Zmiana w kodzie działa od razu, ale raport opiera się na danych z 28 dni, więc pełny efekt widać po kilku tygodniach. Przy weryfikacji poprawki Search Console obserwuje adresy przez dłuższy czas, zanim potwierdzi rozwiązanie problemu.

Podsumowanie

Core Web Vitals to trzy wskaźniki jakości strony: LCP dla ładowania, INP dla responsywności i CLS dla stabilności układu. Dobre wartości to odpowiednio do 2,5 s, do 200 ms i do 0,1 dla 75% wizyt. W sklepie najczęstsze problemy to ciężkie zdjęcie główne, nadmiar skryptów i banery przesuwające treść. Google używa tych wskaźników w rankingu, ale nie są one ważniejsze od trafnych treści, za to bezpośrednio wpływają na wygodę zakupów.

Jeśli chcesz sprawdzić, które szablony twojego sklepu mają problem z Core Web Vitals, i zaplanować poprawki w kolejności od największego wpływu na sprzedaż, zobacz, jak prowadzimy SEO dla sklepów internetowych.