Core Web Vitals: czym są i jak sprawdzić je w sklepie

Core Web Vitals: co mierzą w sklepie internetowym

Core Web Vitals to zestaw trzech metryk opisujących konkretne elementy doświadczenia użytkownika: szybkość pojawienia się głównej treści, reakcję strony na działania użytkownika oraz stabilność układu. W sklepie internetowym przekłada się to na bardzo praktyczne sytuacje. LCP może pokazać, jak szybko klient zobaczy główną część karty produktu lub zawartość kategorii. INP pozwala sprawdzić, czy filtr, wyszukiwarka, wariant produktu albo koszyk reagują bez wyraźnego opóźnienia. CLS pokazuje, czy elementy strony nie przesuwają się w trakcie korzystania z niej.

Jeżeli chcesz wiedzieć, co to są Core Web Vitals w praktyce, nie zaczynaj od samego wyniku Performance w PageSpeed Insights. Wynik punktowy jest tylko jednym z elementów raportu. Dla sklepu ważniejsze jest sprawdzenie konkretnych metryk i ustalenie, czy problem występuje u realnych użytkowników, czy tylko w pojedynczym teście laboratoryjnym.

Obecny zestaw Core Web Vitals obejmuje LCP, INP i CLS. Każda z tych metryk opisuje inną część działania strony. Dla oceny danych rzeczywistych stosuje się 75. percentyl, osobno dla urządzeń mobilnych i komputerów. Przy takim sposobie oceny orientacyjne progi dobrego wyniku to LCP do 2,5 sekundy, INP do 200 milisekund oraz CLS do 0,1.

Nie oznacza to jednak, że każda wartość powyżej progu wskazuje na jeden konkretny błąd. Metryka mówi, co użytkownik odczuwa, ale dopiero analiza strony pokazuje, dlaczego tak się dzieje. W sklepie może to być ciężki obraz, wolny serwer, zewnętrzny skrypt, rozbudowany JavaScript, aplikacja czatu, moduł marketingowy albo sposób działania konkretnego motywu.

LCP, czyli jak szybko pojawia się główna treść

LCP, czyli Largest Contentful Paint, mierzy czas potrzebny do wyrenderowania największego elementu treści widocznego w obszarze ekranu podczas ładowania strony. Może nim być duże zdjęcie produktu, grafika banera, blok tekstu albo element wideo. Metryka nie odpowiada więc na pytanie, kiedy absolutnie wszystko na stronie zostało załadowane. Sprawdza moment, który lepiej odpowiada temu, kiedy użytkownik zaczyna widzieć główną zawartość.

W sklepie internetowym LCP często dotyczy elementu znajdującego się wysoko na stronie. Na stronie produktu może to być zdjęcie produktu lub duży blok tekstowy. Na kategorii może nim zostać główna grafika, nagłówek albo większy element prezentujący ofertę. Dlatego nie ma sensu analizować LCP bez sprawdzenia, jaki element został wskazany w raporcie.

Dobry wynik LCP to 2,5 sekundy lub mniej. Powyżej 4 sekund wynik jest klasyfikowany jako słaby. Pomiędzy tymi wartościami znajduje się zakres wymagający poprawy. Ocena danych rzeczywistych odbywa się na podstawie 75. percentyla, więc pojedynczy bardzo szybki test nie zastępuje danych zbieranych od użytkowników.

Jeżeli LCP jest słaby, zacznij od ustalenia, co dokładnie zostało zmierzone. W PageSpeed Insights raport może wskazać element LCP. Jeżeli jest nim zdjęcie produktu, sprawdź jego rozmiar, format, sposób dostarczenia i priorytet ładowania. Jeżeli jest nim tekst, przyjrzyj się CSS, fontom, zasobom blokującym renderowanie oraz czasowi odpowiedzi serwera.

Problemu z LCP nie powinno się automatycznie utożsamiać z dużymi zdjęciami. Obraz może być tylko jednym z elementów całego łańcucha. Jeżeli serwer długo odpowiada, przeglądarka później zaczyna pobierać kolejne zasoby. Jeżeli CSS lub JavaScript blokuje wyświetlenie zawartości, użytkownik również może długo czekać na pojawienie się głównego elementu.

W praktyce sprawdzaj więc kolejno: czas odpowiedzi serwera, zasoby potrzebne do wyświetlenia elementu LCP, wielkość i sposób dostarczenia obrazu, CSS blokujący renderowanie oraz skrypty uruchamiane przed wyświetleniem głównej treści. Dopiero potem decyduj, co optymalizować.

Pomaga rozbicie LCP na cztery części: czas odpowiedzi serwera na żądanie HTML, opóźnienie, z jakim przeglądarka zaczyna pobierać zasób LCP, czas samego pobierania oraz opóźnienie jego wyrenderowania. Taki podział mówi znacznie więcej niż sama liczba końcowa, bo wskazuje, w którym miejscu łańcucha tracisz czas.

Częstym błędem jest leniwe ładowanie wszystkich obrazów bez rozróżnienia ich położenia. Lazy loading ma sens dla zdjęć niżej na stronie, ale opóźnianie obrazu, który jest elementem LCP, pogarsza wynik. Sprawdź też, kiedy przeglądarka w ogóle wykrywa ten zasób i jaki priorytet pobierania mu nadaje.

Jeżeli sklep działa na WooCommerce, przy analizie LCP przydatne będzie również zestawienie metryki z przyczynami charakterystycznymi dla tej platformy, dlatego przy problemach z czasem ładowania można sprawdzić typowe przyczyny wolnego WooCommerce. W przypadku PrestaShop lub Shoper mechanizm diagnozy będzie podobny, ale źródło obciążenia może znajdować się w innych modułach lub mechanizmach platformy.

LCP na karcie produktu

Na produkcie sprawdź przede wszystkim główne zdjęcie, nazwę, cenę, warianty oraz elementy ładowane razem z kartą. Jeżeli sklep pobiera rekomendacje, opinie, skrypty analityczne i widgety jeszcze przed pokazaniem podstawowej treści, mogą one konkurować o zasoby z głównym elementem strony.

Nie zakładaj, że problemem zawsze jest hosting. Jeżeli HTML odpowiada szybko, a główne zdjęcie zaczyna się ładować dopiero po wykonaniu kilku skryptów, przyczyna leży w kodzie frontendu. Samą metrykę dokładniej opisuje materiał o LCP w sklepie.

LCP na kategorii

Kategoria ma inną strukturę niż produkt. Problemem może być duża grafika nagłówkowa, rozbudowane menu, filtry, sortowanie i lista produktów. Sprawdź, czy pierwsze produkty są dostępne w HTML w sposób, który pozwala przeglądarce szybko rozpocząć ich renderowanie.

Jeżeli nad listą produktów znajduje się ciężki slider, kilka dużych grafik albo rozbudowany blok promocyjny, sprawdź, czy to właśnie on jest elementem LCP. Nie optymalizuj w ciemno całej strony.

INP, czyli reakcja sklepu na kliknięcie

INP, czyli Interaction to Next Paint, opisuje responsywność strony. Metryka sprawdza, jak szybko przeglądarka reaguje wizualnie na interakcje użytkownika. Nie chodzi więc tylko o samo załadowanie strony. INP zaczyna mieć znaczenie wtedy, gdy klient wykonuje działania.

W sklepie takich interakcji jest bardzo dużo. Użytkownik otwiera menu, wybiera filtr, zmienia wariant produktu, rozwija opis, wpisuje frazę w wyszukiwarce, otwiera koszyk, przechodzi przez formularz albo zmienia ilość produktu. Jeżeli po kliknięciu przez dłuższy czas nic się nie dzieje, strona może sprawiać wrażenie zawieszonej, nawet jeśli LCP jest dobry.

Dobry wynik INP wynosi 200 milisekund lub mniej. Wynik powyżej 500 milisekund jest klasyfikowany jako słaby. Podczas analizy danych rzeczywistych również stosuje się 75. percentyl.

INP jest szczególnie interesujący w sklepach opartych na JavaScript. Sam fakt używania JavaScript nie oznacza problemu. Problemem może być kod wykonywany przez przeglądarkę w momencie interakcji. Długie zadania na głównym wątku mogą opóźniać obsługę kliknięcia, wykonanie funkcji i pokazanie kolejnej klatki interfejsu.

Jeżeli INP jest słaby, nie zaczynaj od wyłączania przypadkowych skryptów. Najpierw ustal, która interakcja generuje problem. Następnie sprawdź, czy obciążenie pochodzi z kodu sklepu, biblioteki, modułu, integracji marketingowej lub zewnętrznego narzędzia.

W WooCommerce przyczyną może być rozbudowany motyw, kreator stron, filtr produktów, dodatkowe moduły albo wiele skryptów ładowanych na każdej podstronie. W PrestaShop podobną rolę mogą pełnić moduły front office, rozbudowane filtry, systemy rekomendacji czy integracje zewnętrzne. Nie zakładaj jednak z góry, że winna jest platforma. Ten sam sklep może mieć dobry INP na jednej stronie i słaby na innej.

Przy analizie INP przydaje się rozdzielenie problemu na trzy etapy. Pierwszy to opóźnienie przed rozpoczęciem obsługi interakcji. Drugi to czas wykonywania kodu obsługującego zdarzenie. Trzeci to czas potrzebny na przygotowanie i wyświetlenie kolejnej klatki. Taki podział pozwala zawęzić poszukiwania zamiast traktować cały JavaScript jako jeden problem.

Jak przetestować INP na produkcie, kategorii i w koszyku

Zacznij od działań, które kupujący wykonuje najczęściej. Na produkcie wybierz wariant, zmień liczbę sztuk i dodaj produkt do koszyka. Na kategorii otwórz filtry, zaznacz kilka parametrów, zmień sortowanie i przejdź na kolejną stronę wyników. W koszyku zwiększ ilość, usuń pozycję i zmień dane potrzebne do zamówienia.

Jeżeli po kliknięciu strona przestaje reagować, otwórz Chrome DevTools i sprawdź aktywność głównego wątku. Szukaj długich zadań JavaScript, ciężkich funkcji obsługi zdarzeń i operacji, które po jednej interakcji wykonują zbyt dużo pracy. Częstym źródłem jest kod firm trzecich: czaty, systemy reklamowe, rekomendacje i moduły opinii. Nie każdy taki skrypt trzeba usuwać. Trzeba ustalić, który wykonuje kosztowne operacje i czy musi startować tak wcześnie.

W WooCommerce i PrestaShop sprawdź również, jak moduły modyfikują frontend. Dwa moduły mogą robić pozornie różne rzeczy, a oba podpinać własny JavaScript pod ten sam przycisk. Samą metrykę dokładniej opisuje materiał o INP w sklepie.

Laboratorium nie mierzy INP tak jak użytkownik

Lighthouse nie zmierzy rzeczywistego INP, bo test laboratoryjny nie klika jak kupujący. W laboratorium używa się Total Blocking Time jako wskaźnika pomocniczego związanego z pracą głównego wątku. Nie traktuj TBT jako zamiennika INP. Jeżeli laboratorium pokazuje dużo długich zadań, sprawdź JavaScript. Jeżeli dane użytkowników pokazują problem z INP, ustal, przy której konkretnej interakcji kupujący czeka najdłużej.

CLS, czyli czy strona nie przesuwa się podczas zakupów

CLS, czyli Cumulative Layout Shift, mierzy stabilność wizualną strony. Problem pojawia się wtedy, gdy widoczny element zmienia swoje położenie w sposób, którego użytkownik się nie spodziewa.

W sklepie łatwo wyobrazić sobie taki scenariusz. Klient próbuje kliknąć przycisk dodania do koszyka, ale w tym samym momencie nad przyciskiem pojawia się baner i cała zawartość przesuwa się w dół. Innym przykładem może być zdjęcie produktu bez wcześniej określonego miejsca, które po załadowaniu zmienia układ strony. Podobnie może działać reklama, widget, komunikat promocyjny albo element ładowany asynchronicznie.

Dobry CLS to 0,1 lub mniej. Wynik powyżej 0,25 jest słaby. W praktyce przy diagnozie nie wystarczy zobaczyć liczbę. Trzeba znaleźć elementy, które się przesuwają.

Jeżeli CLS jest wysoki, sprawdź przede wszystkim obrazy i multimedia bez określonych wymiarów, dynamicznie dodawane elementy, banery, popupy, fonty oraz skrypty firm zewnętrznych. Sprawdź także, czy komponenty ładowane po czasie rezerwują miejsce jeszcze przed pobraniem właściwej zawartości.

Nie każdy ruch elementu oznacza błąd CLS. Przesunięcie wynikające bezpośrednio z działania użytkownika może być traktowane inaczej niż nieoczekiwany ruch strony. Dlatego analizując CLS, patrz na źródło zmiany, a nie tylko na samą liczbę.

Jeżeli chcesz dokładniej przeanalizować ten konkretny problem, przydatny będzie materiał opisujący CLS w sklepie i jego najczęstsze przyczyny. Dzięki temu łatwiej przełożyć wynik metryki na konkretny element interfejsu.

CLS na karcie produktu, w filtrach i w checkoutcie

Na karcie produktu sprawdź, czy galeria ma określone wymiary i czy po wczytaniu wariantu nie zmienia się wysokość sekcji z ceną, dostępnością albo formularzem zakupu. Jeżeli komunikat o dostępności pojawia się dopiero po odpowiedzi serwera, zarezerwuj na niego miejsce wcześniej.

Na kategorii przejrzyj filtry, banery i listę produktów. Jeżeli filtr wysuwa panel i jednocześnie przesuwa całą zawartość strony, sprawdź, czy takie zachowanie jest zamierzone.

Najbardziej delikatny jest koszyk i checkout. Komunikat o błędzie, kodzie rabatowym, metodzie dostawy albo płatności może zmienić wysokość formularza, a kupujący kliknie nie ten element, który zamierzał. Sprawdź też fonty: zmiana kroju pisma po wczytaniu fontu potrafi przesunąć całe bloki tekstu.

Jak sprawdzić Core Web Vitals sklepu

Najprostszym punktem wyjścia jest PageSpeed Insights. Wpisujesz pełny adres strony i uruchamiasz analizę. Nie ograniczaj się jednak do strony głównej. Sklep internetowy ma kilka typów podstron i każdy z nich może zachowywać się inaczej.

Sprawdź przynajmniej stronę główną, kategorię, kartę produktu oraz stronę, na której znajduje się rozbudowany formularz lub koszyk. Jeżeli sklep ma wyszukiwarkę, filtry albo niestandardowy konfigurator produktu, przetestuj również podstronę, na której użytkownik z tych funkcji korzysta.

Po uruchomieniu testu zwróć uwagę na sekcję danych dotyczących rzeczywistych użytkowników. PageSpeed Insights korzysta z danych Chrome User Experience Report, czyli CrUX. Dane te pokazują doświadczenia realnych użytkowników, a nie pojedynczego komputera wykonującego test. Raport obejmuje między innymi LCP, INP i CLS.

Druga część raportu to dane laboratoryjne generowane przez Lighthouse. Test jest wykonywany w kontrolowanych warunkach. Dzięki temu można łatwiej odtworzyć określone problemy i przeanalizować rekomendacje techniczne.

Te dwa rodzaje danych trzeba czytać razem, ale nie należy ich utożsamiać. Jeżeli dane rzeczywiste są słabe, a test laboratoryjny wygląda dobrze, nie oznacza to automatycznie błędu raportu. Użytkownicy mogą korzystać z innych urządzeń, połączeń sieciowych i konfiguracji przeglądarki niż środowisko laboratoryjne.

Podobnie działa sytuacja odwrotna. Jeżeli test laboratoryjny pokazuje problem, ale dane rzeczywiste są dobre, sprawdź, czy problem dotyczy konkretnego scenariusza testowego. Nie każdy sygnał z Lighthouse oznacza, że większość klientów sklepu doświadcza tego samego problemu.

Trzecim źródłem jest raport Podstawowe wskaźniki internetowe w Search Console. Grupuje on podobne adresy i pokazuje, które grupy mają problem w danych użytkowników. Jeżeli kilkadziesiąt kart produktów trafia do tej samej grupy, szukaj wspólnego źródła w szablonie, zamiast poprawiać każdy URL osobno.

Jak czytać wynik PageSpeed Insights

Najpierw sprawdź, czy raport zawiera dane rzeczywiste. Jeżeli ich nie ma, nie próbuj na ich podstawie oceniać zachowania wszystkich użytkowników. Brak danych może oznaczać niewystarczającą ilość danych dla danej strony lub po prostu brak odpowiedniej reprezentacji adresu w zbiorze.

Następnie sprawdź trzy metryki: LCP, INP i CLS. Zobacz, która z nich wypada najsłabiej. Potem przejdź do diagnostyki odpowiadającej tej metryce.

Przy LCP szukaj elementu, który został uznany za największy element treści. Przy INP szukaj wolnych interakcji i kodu blokującego główny wątek. Przy CLS szukaj elementów zmieniających położenie.

Nie zaczynaj od poprawiania wszystkiego naraz. Jeżeli raport pokazuje słaby LCP, a INP i CLS są dobre, skoncentruj analizę na ładowaniu głównej treści. Jeżeli problem dotyczy INP, analiza samych obrazów niewiele wyjaśni. Jeżeli problemem jest CLS, zwiększenie wydajności serwera może nie usunąć przesuwania elementów.

Dane rzeczywiste a test laboratoryjny

To jeden z najczęstszych powodów nieporozumień przy analizie wydajności strony. Ten sam adres może mieć inne wyniki w danych laboratoryjnych i rzeczywistych.

Dane laboratoryjne powstają podczas kontrolowanego testu. Możesz je wykorzystać do debugowania, porównywania zmian i szukania konkretnych elementów obciążających stronę. Są szczególnie przydatne wtedy, gdy chcesz sprawdzić, co dzieje się podczas ładowania konkretnej podstrony.

Dane rzeczywiste pochodzą z doświadczeń użytkowników. Pokazują szerszy zakres urządzeń, sieci i sposobów korzystania ze strony. To właśnie dlatego mogą wyglądać gorzej niż wynik uzyskany na szybkim komputerze podczas ręcznego testu.

Przykładowo możesz wykonać kilka testów PageSpeed Insights i otrzymać dobry wynik laboratoryjny. Jednocześnie dane rzeczywiste mogą wskazywać słaby LCP. Nie oznacza to, że narzędzie się pomyliło. Oznacza to, że kontrolowany test i realne wizyty mierzą inne sytuacje.

Podobnie zmienność wyników pojedynczego testu nie powinna być traktowana jako dowód, że sklep raz działa dobrze, a raz źle. Warunki testu mogą się zmieniać. Dlatego przy decyzjach technicznych patrz na powtarzalny wzorzec, dane rzeczywiste oraz konkretną diagnostykę.

W przypadku Core Web Vitals szczególne znaczenie ma 75. percentyl. Nie chodzi o średnią wszystkich wizyt. Taki sposób prezentowania danych pozwala ocenić doświadczenie dużej części użytkowników, w tym osób korzystających ze słabszych urządzeń lub mniej korzystnych warunków sieciowych.

Jak odróżnić problem techniczny od błędu pomiaru

Pierwszy sygnał ostrzegawczy to sprzeczność między różnymi źródłami danych. Jeżeli jeden test pokazuje bardzo słaby wynik, a dane rzeczywiste są dobre, nie zaczynaj od przebudowy sklepu. Powtórz test i sprawdź, czy problem jest powtarzalny.

Drugi sygnał to brak danych rzeczywistych. W takim przypadku nie można traktować wyniku laboratoryjnego jako dokładnego obrazu doświadczenia wszystkich klientów. Można natomiast użyć go do znalezienia potencjalnych problemów.

Trzeci sygnał to różnica między urządzeniami. Sklep może działać sprawnie na desktopie, a mieć problemy na telefonach. W przypadku e-commerce jest to szczególnie istotne, ponieważ mobilny interfejs może korzystać z innych komponentów, zdjęć, menu i skryptów niż wersja desktopowa.

Czwarty sygnał to różnica między typami stron. Strona główna może mieć dobre Core Web Vitals, a karta produktu słabe. Powodem może być większa liczba zdjęć, wariantów, rekomendacji, opinii, skryptów analitycznych lub elementów dynamicznych.

Piąty sygnał to zmiana wyników po wdrożeniu nowego modułu albo skryptu. Jeżeli po dodaniu narzędzia marketingowego pogarsza się INP lub CLS, sprawdź jego wpływ, zamiast zakładać, że problem leży w serwerze.

Dobrą praktyką jest prowadzenie prostego dziennika zmian. Zapisuj datę wdrożenia większych zmian, typ podstrony i wyniki metryk. Nie potrzebujesz skomplikowanego systemu. Chodzi o możliwość zestawienia pogorszenia lub poprawy z konkretną zmianą w sklepie.

Jeżeli potrzebujesz szerszej diagnozy, analiza Core Web Vitals powinna zostać połączona z analizą całej wydajności strony. Przy sklepie opartym na różnych technologiach przydatne jest również porównanie elementów wspólnych dla platform, dlatego podczas diagnozy można zestawić wyniki z materiałem o wydajności PrestaShop i Shoper albo z analizą WooCommerce.

Sklep mobilny wymaga osobnego sprawdzenia

Właściciel sklepu zwykle testuje na komputerze, bo tak jest wygodniej. Kupujący na telefonach mają jednak słabsze procesory, wolniejsze łącza i mniej zasobów dla JavaScriptu. W danych terenowych analizuj więc osobno telefony i komputery, a w laboratorium wykonuj testy w warunkach mobilnych.

Na telefonie sprawdź szczególnie menu, filtry, galerię produktu, wybór wariantów, przyklejone elementy i przycisk dodania do koszyka. To te części sklepu wykonują najwięcej pracy w JavaScript. Oceniaj też CLS w prawdziwym układzie mobilnym. Element, który na dużym monitorze zajmuje mały fragment ekranu, na telefonie potrafi przesunąć większość widocznej treści.

Co sprawdzić przed poprawą Core Web Vitals

Zanim zaczniesz optymalizację, określ problem możliwie dokładnie. Samo hasło “Core Web Vitals są słabe” jest zbyt ogólne, żeby na jego podstawie podejmować decyzje.

Przy LCP sprawdź element LCP, czas odpowiedzi serwera, obrazy, CSS i zasoby blokujące renderowanie. Przy INP sprawdź wolne interakcje, długie zadania JavaScript, event listenery oraz skrypty ładowane przez sklep i usługi zewnętrzne. Przy CLS sprawdź elementy bez zarezerwowanego miejsca, obrazy, fonty, popupy, banery, reklamy i dynamicznie wstawiane komponenty.

Potem określ, czy problem występuje w danych rzeczywistych, laboratoryjnych, czy w obu miejscach. To zmienia sposób dalszej diagnozy.

Jeżeli problem występuje przede wszystkim w danych laboratoryjnych, szukaj możliwości odtworzenia go w kontrolowanym środowisku. Jeżeli występuje w danych rzeczywistych, sprawdź, czy dotyczy całego originu, konkretnej podstrony, urządzeń mobilnych lub desktopowych. Dane zbiorcze nie zawsze pokazują, gdzie dokładnie znajduje się źródło problemu.

W sklepie warto też testować różne typy stron. Nie zakładaj, że wynik strony głównej reprezentuje kartę produktu. Karta produktu może mieć cięższe galerie, warianty, rekomendacje i dodatkowe skrypty. Kategoria może mieć filtry i sortowanie. Koszyk może mieć elementy aktualizowane dynamicznie.

Każda poprawka powinna przejść tę samą drogę: wynik, źródło problemu, test techniczny, zmiana i ponowny pomiar. Trzy metryki mierzą co innego, więc każda wymaga własnej diagnozy.

Tabela: najważniejsze metryki Core Web Vitals, ich znaczenie i źródła danych

Metryka	Co mierzy	Dobry wynik	Gdzie sprawdzać	Co analizować przy problemie
LCP	Czas pojawienia się największego elementu treści w obszarze widocznym dla użytkownika	do 2,5 s	PageSpeed Insights, dane CrUX, Lighthouse	element LCP, serwer, obrazy, CSS, zasoby blokujące renderowanie
INP	Responsywność strony podczas interakcji użytkownika	do 200 ms	PageSpeed Insights, dane CrUX, narzędzia laboratoryjne	JavaScript, długie zadania, obsługa zdarzeń, opóźnienie prezentacji
CLS	Stabilność wizualna i nieoczekiwane przesunięcia elementów	do 0,1	PageSpeed Insights, dane CrUX, Lighthouse	obrazy, banery, popupy, fonty, dynamiczne elementy

Źródło danych ma znaczenie przy interpretacji. PageSpeed Insights łączy dane rzeczywiste z danymi laboratoryjnymi. Dane rzeczywiste są oparte na Chrome User Experience Report, natomiast test laboratoryjny korzysta z Lighthouse. Dlatego dwa wyniki dotyczące tego samego adresu mogą się różnić bez tego, że którykolwiek z nich jest automatycznie błędny.

Jak poprawić Core Web Vitals w sklepie

Poprawa Core Web Vitals zaczyna się od konkretnej metryki i jej źródła. Nie ma jednego ustawienia, które naprawia LCP, INP i CLS jednocześnie.

Przy LCP sprawdź, czy główny element strony jest dostarczany odpowiednio szybko. Duże zdjęcie może wymagać optymalizacji, ale równie istotny może być czas odpowiedzi serwera lub sposób ładowania CSS. Nie usuwaj elementów tylko dlatego, że są widoczne w raporcie. Najpierw ustal ich funkcję i wpływ na LCP.

Przy INP ograniczaj niepotrzebną pracę JavaScriptu podczas interakcji. Sprawdź, czy skrypty wykonują zadania, które nie są potrzebne do obsłużenia kliknięcia. Analizuj też moduły i integracje, które dodają kod do każdej strony.

Przy CLS rezerwuj miejsce na elementy, których rozmiar jest znany dopiero po pobraniu zasobu. Dotyczy to przede wszystkim obrazów i części dynamicznych komponentów. Sprawdź również banery, popupy i inne elementy, które mogą pojawić się po załadowaniu podstawowej treści.

Przy większym sklepie nie rób optymalizacji wyłącznie na podstawie strony głównej. Przetestuj różne typy podstron i różne urządzenia. Jeżeli problem powtarza się na wielu adresach, szukaj wspólnego elementu. Jeżeli występuje tylko na jednej grupie stron, analiza powinna być bardziej szczegółowa.

W praktyce przydatne jest również spojrzenie na ogólną wydajność sklepu, ponieważ pojedyncza metryka nie pokazuje całej architektury ładowania strony. Jeżeli chcesz przejść od samego wyniku do diagnozy technicznej, pomocny będzie materiał o tym, co realnie skraca czas ładowania sklepu.

Co zwykle sprawdzić najpierw

Gdy problemów jest kilka, kolejność ma znaczenie. Najpierw sprawdź cache strony i czas odpowiedzi serwera, szczególnie przy wysokim TTFB. Potem obrazy: zdjęcia produktów potrafią stanowić dużą część przesyłanych danych, a nie każde wymaga tej samej jakości i rozdzielczości.

Następnie CSS i JavaScript. Usuń nieużywany kod, ogranicz zasoby blokujące renderowanie i sprawdź, czy skrypty nie ładują się tam, gdzie nie są potrzebne. Moduł galerii nie musi działać na stronie regulaminu, a skrypt filtra nie musi obciążać każdej podstrony. Potem skrypty zewnętrzne: zapisz, które narzędzia są naprawdę potrzebne i kiedy startują. Przy CLS zadbaj o wymiary obrazów i stabilne kontenery dla treści, która pojawia się później.

Na końcu ponów pomiar. Usunięcie skryptu albo zmniejszenie zdjęcia nie gwarantuje poprawy, dlatego sprawdź konkretne wskaźniki jeszcze raz i upewnij się, że nie powstał nowy problem.

Czego nie robić przy optymalizacji

Nie dokładaj kolejnych wtyczek optymalizacyjnych bez zrozumienia problemu. Jeżeli sklep zwalnia przez ciężki motyw, słaby serwer albo nadmiar skryptów, sama wtyczka cache niczego nie załatwi, a może dołożyć kolejną warstwę do diagnozowania.

Nie wycinaj funkcji, które sprzedają, tylko po to, żeby podbić wynik testu. Jeżeli opinie, raty albo wyszukiwarka produktów realnie pomagają klientom, zoptymalizuj ich ładowanie, zamiast usuwać je w ciemno.

Nie dopieszczaj wyłącznie strony głównej i nie pomijaj telefonów. Najważniejsze są ścieżki zakupowe: kategoria, karta produktu, koszyk i checkout.

Core Web Vitals a pozycja sklepu w Google

Core Web Vitals to element technicznej jakości strony, a nie samodzielny sposób na wysokie pozycje. Google wykorzystuje te wskaźniki w systemach rankingowych, ale dobra ocena nie gwarantuje miejsca w wynikach. Liczy się razem z jakością treści, dopasowaniem do intencji, indeksowaniem i linkowaniem wewnętrznym. Nie ma sensu dopieszczać wyniku, jeżeli sklep ma problemy z indeksowaniem, duplikacją stron albo brakuje mu treści.

Wydajności nie warto jednak odkładać na później. Kupujący, który czeka na główną treść, nie może wygodnie użyć filtrów albo trafia w inny przycisk przez przesunięcie układu, dostaje realnie gorsze doświadczenie niezależnie od tego, co pokazuje ranking.

Core Web Vitals a codzienna praca właściciela sklepu

Nie musisz codziennie wykonywać testów PageSpeed Insights. Taki sposób pracy może prowadzić do skupienia na przypadkowych zmianach wyniku zamiast na rzeczywistym stanie sklepu.

Lepszy schemat jest prosty. Po większej zmianie w sklepie sprawdź strony, których zmiana dotyczyła. Jeżeli wdrażasz nowy motyw, moduł, filtr, system rekomendacji albo narzędzie marketingowe, porównaj wyniki przed i po wdrożeniu. Jeżeli zauważysz zmianę w danych rzeczywistych, sprawdź ją ponownie i poszukaj przyczyny w kodzie lub zasobach strony.

Po większym wdrożeniu powtórz testy laboratoryjne dla produktu, kategorii i koszyka, a przy zmianach w checkoutcie przejdź cały proces zakupowy. W danych terenowych patrz na trend, a nie na pojedynczy dzień, bo dane potrzebują czasu, żeby odzwierciedlić zachowanie użytkowników. Jeżeli problem pojawia się w kilku podobnych szablonach naraz, szukaj wspólnej zmiany w kodzie lub konfiguracji.

Nie traktuj wyniku 100 w PageSpeed Insights jako celu samego w sobie. Właściciel sklepu potrzebuje informacji, czy użytkownik może szybko zobaczyć ofertę, sprawnie wykonać działanie i korzystać ze stabilnego interfejsu. Core Web Vitals pomagają te trzy obszary mierzyć, ale nie zastępują analizy całego procesu zakupowego.

Dlatego wynik powinien prowadzić do pytania: co dokładnie powoduje problem na tej stronie? Dopiero po znalezieniu odpowiedzi można zdecydować, czy potrzebna jest optymalizacja obrazu, zmiana sposobu ładowania zasobów, ograniczenie JavaScriptu, poprawa konfiguracji serwera, modyfikacja modułu czy przebudowa konkretnego komponentu.

Jeżeli nie chcesz ograniczać analizy do pojedynczego wyniku z PageSpeed Insights, możesz zlecić audyt szybkości sklepu internetowego, w którym punktem wyjścia jest identyfikacja konkretnych problemów technicznych i ich źródeł.

Core Web Vitals sklepu: praktyczna checklista

Przed zamknięciem analizy przejdź przez kilka pytań.

• Czy sprawdziłeś dane rzeczywistych użytkowników, a nie tylko wynik Lighthouse, osobno dla telefonów i komputerów?
• Czy test obejmuje produkt, kategorię, koszyk i checkout?
• Czy wiesz, który element jest LCP, i czy główne zdjęcie produktu nie jest opóźniane przez JavaScript albo lazy loading?
• Czy sprawdziłeś TTFB i moment, w którym przeglądarka zaczyna pobierać zasób LCP?
• Czy przetestowałeś filtry, warianty, dodawanie do koszyka i zmianę ilości, a w DevTools szukałeś długich zadań?
• Czy obrazy, banery i elementy dynamiczne mają zarezerwowane miejsce, a fonty nie przesuwają układu?
• Czy po wdrożeniu zmian wykonasz ponowny pomiar i potrafisz wskazać konkretną przyczynę problemu?

Taka lista jest bardziej użyteczna niż pogoń za jednym wynikiem punktowym. W sklepie trzeba patrzeć na stronę tak, jak korzysta z niej kupujący: wejść na kategorię, znaleźć produkt, wybrać wariant, dodać go do koszyka i przejść przez formularz.

Podsumowanie

Core Web Vitals pozwalają spojrzeć na wydajność sklepu przez trzy konkretne zachowania użytkownika. LCP pokazuje, jak szybko pojawia się główna treść, INP opisuje reakcję strony na interakcje, a CLS mierzy stabilność wizualną.

Jeżeli chcesz wiedzieć, jak sprawdzić Core Web Vitals sklepu, zacznij od PageSpeed Insights i analizuj zarówno dane rzeczywiste, jak i laboratoryjne. Następnie porównuj wyniki między typami podstron i urządzeniami. Nie traktuj pojedynczego testu jako pełnej diagnozy.

Gdy wynik jest słaby, szukaj przyczyny odpowiadającej konkretnej metryce. LCP kieruje uwagę na ładowanie głównej treści, INP na responsywność i JavaScript, a CLS na nieoczekiwane przesunięcia elementów. Taki sposób pracy pozwala przejść od ogólnego komunikatu o wydajności strony do konkretnego problemu, który można sprawdzić w kodzie, konfiguracji sklepu lub sposobie dostarczania zasobów.