Core Web Vitals w sklepie internetowym: LCP, INP i CLS

Co mierzą LCP, INP i CLS, progi dobre i słabe dla 75. percentyla, dane laboratoryjne a terenowe oraz typowe poprawki w sklepach Shopify i WooCommerce.

Redakcja FixReports12 min czytania

Core Web Vitals to trzy wskaźniki Google, które opisują, jak strona działa u prawdziwych odwiedzających: Largest Contentful Paint (LCP) mierzy wczytywanie, Interaction to Next Paint (INP) responsywność, a Cumulative Layout Shift (CLS) stabilność wizualną. Strona przechodzi ocenę, gdy co najmniej 75% wizyt mieści się w zakresie „dobrym”: LCP do 2,5 sekundy, INP do 200 milisekund i CLS nie większy niż 0,1, mierzone osobno dla urządzeń mobilnych i komputerów. W sklepach internetowych słabe wyniki zwykle wynikają z dużych lub leniwie ładowanych zdjęć w banerze głównym i na stronach produktów, skryptów aplikacji i śledzenia, fontów internetowych oraz pasków i widżetów opinii, które spychają treść w dół już po wyświetleniu strony.

Najważniejsze informacje

Jakie są progi Core Web Vitals?

Strona spełnia wymagania Core Web Vitals, gdy 75. percentyl jej wczytań mieści się w dobrym zakresie dla wszystkich trzech wskaźników.

WskaźnikCo mierzyDobryWymaga poprawySłaby
LCPCzas do wyrenderowania największego obrazu, filmu lub bloku tekstu w widocznym obszarze2,5 s lub mniejPowyżej 2,5 s do 4,0 sPowyżej 4,0 s
INPCzas od kliknięcia, dotknięcia lub naciśnięcia klawisza do narysowania następnej klatki200 ms lub mniejPowyżej 200 ms do 500 msPowyżej 500 ms
CLSJak bardzo widoczna treść nieoczekiwanie się przesuwa0,1 lub mniejPowyżej 0,1 do 0,25Powyżej 0,25

Progi pochodzą z przewodników web.dev dotyczących LCP (otwiera się w nowej karcie), INP (otwiera się w nowej karcie) i CLS (otwiera się w nowej karcie), według stanu z października 2026 r.

Ocena na podstawie 75. percentyla oznacza, że wynik odzwierciedla większość odwiedzających, a nie tylko najszybszych, a Google rozdziela urządzenia mobilne i komputery (otwiera się w nowej karcie). PageSpeed Insights zalicza stronę, gdy wszystkie trzy wskaźniki są dobre. Jeśli brakuje wystarczających danych o INP, ocenia tylko LCP i CLS (dokumentacja PageSpeed Insights (otwiera się w nowej karcie)). Google zapowiada, że stabilne wskaźniki Core Web Vitals nie będą zmieniane częściej niż raz w roku.

W sklepie elementem LCP jest często baner główny albo główne zdjęcie produktu, dlatego sposób obsługi obrazów ma tak duże znaczenie.

Dlaczego w marcu 2024 r. INP zastąpił FID?

INP zastąpił FID, ponieważ FID mierzył tylko pierwszą interakcję i tylko część jej opóźnienia, a INP uwzględnia interakcje z całej wizyty.

Google ogłosiło w maju 2023 r., że INP stanie się wskaźnikiem Core Web Vitals, a zmiana weszła w życie 12 marca 2024 r. (otwiera się w nowej karcie). FID raportował wyłącznie pierwszą interakcję, i to tylko opóźnienie danych wejściowych, bez czasu potrzebnego na wykonanie procedur obsługi zdarzeń i narysowanie wyniku. INP obserwuje kliknięcia, dotknięcia i naciśnięcia klawiszy przez całą wizytę i podaje najdłuższą interakcję, pomijając wartości odstające; przewijanie i najeżdżanie kursorem się nie liczą. Użytkownicy interfejsów API CrUX i PageSpeed Insights mieli czas na przejście do 9 września 2024 r. (web.dev (otwiera się w nowej karcie)).

Każda interakcja składa się z trzech części: opóźnienia danych wejściowych (oczekiwanie na zajęte skrypty), czasu przetwarzania (wykonanie procedur obsługi) i opóźnienia prezentacji (narysowanie następnej klatki) (web.dev (otwiera się w nowej karcie)).

W sklepie takimi interakcjami są wybór wariantu, przyciski ilości, dodawanie do koszyka, wysuwany koszyk, filtry i menu. Strona mogła zaliczać FID przy szybkim pierwszym dotknięciu, a mimo to sprawiać wrażenie powolnej, gdy ktoś później otwierał filtry.

Czym różnią się dane laboratoryjne od danych terenowych?

Dane laboratoryjne pochodzą z jednego testu w stałych warunkach, a dane terenowe są zbierane od prawdziwych odwiedzających w dłuższym czasie. Google zaleca, by o tym, co poprawić najpierw, decydować na podstawie danych terenowych (web.dev (otwiera się w nowej karcie)).

Dane laboratoryjneDane terenowe
ŹródłoJedno symulowane wczytanie strony (Lighthouse, Chrome DevTools, sekcja laboratoryjna PageSpeed Insights)Prawdziwi użytkownicy Chrome (Chrome UX Report) albo Twój własny monitoring rzeczywistych użytkowników (RUM)
WarunkiStałe urządzenie i sieć. Domyślny test mobilny Lighthouse (otwiera się w nowej karcie) używa profilu „Slow 4G” (150 ms czasu odpowiedzi w obie strony, 1,6 Mb/s pobierania) i 4-krotnego spowolnienia CPUDowolne urządzenia, sieci i lokalizacje Twoich odwiedzających
INPNiemierzony przy zwykłym wczytaniu strony. Przybliżeniem jest Total Blocking Time (TBT)Mierzony na podstawie prawdziwych interakcji
Najlepsze doDebugowania i sprawdzenia zmiany przed wdrożeniemPoznania tego, czego naprawdę doświadczają odwiedzający

TBT sumuje część każdego zadania w wątku głównym przekraczającą 50 ms. web.dev sugeruje wartość poniżej 200 ms na przeciętnym sprzęcie mobilnym, ale zaznacza, że TBT nie zastępuje INP (web.dev (otwiera się w nowej karcie)).

Trzy cechy raportu Chrome UX Report (CrUX) mają znaczenie dla sklepów:

  • To średnia krocząca z 28 dni (otwiera się w nowej karcie), aktualizowana codziennie.
  • Obejmuje Chrome na komputerach i Androidzie u użytkowników, którzy spełniają warunki raportowania Chrome. Chrome na iOS jest wyłączony, więc sklep, w którym kupują głównie użytkownicy iPhone’ów, widzi dane terenowe tylko od części swoich klientów (metodologia (otwiera się w nowej karcie)).
  • Strony i domeny pojawiają się w raporcie tylko wtedy, gdy są publicznie wykrywalne i wystarczająco popularne, więc sklep z małym ruchem może mieć tylko dane na poziomie domeny albo nie mieć ich wcale.

Panel wydajności sieciowej (otwiera się w nowej karcie) Shopify również podaje LCP, INP i CLS od prawdziwych użytkowników dla 75. percentyla, ale z 30 dni, a nie z 28, więc licz się z pewnymi różnicami względem CrUX.

Co spowalnia LCP na stronach sklepu?

LCP w sklepach jest zwykle wolny, ponieważ główny obraz jest za ciężki, przeglądarka wykrywa go za późno albo jest celowo opóźniany przez leniwe ładowanie lub animację.

  • Leniwe ładowanie obrazu LCP. web.dev zaleca, by nigdy tego nie robić (web.dev (otwiera się w nowej karcie)). Analiza stron na WordPressie wykazała wolniejszy LCP w 75. percentylu na stronach korzystających z natywnego leniwego ładowania, a rezygnacja z leniwego ładowania obrazów widocznych bez przewijania usunęła ten spadek (web.dev (otwiera się w nowej karcie)).
  • Obraz wykrywany za późno. Baner ustawiony jako CSS background-image albo wstawiany przez skrypt slidera nie występuje w kodzie HTML, który przeglądarka skanuje na początku. Shopify odradza tła CSS dla treści w banerze głównym oraz efekty pojawiania się na obrazie LCP (Shopify (otwiera się w nowej karcie)).
  • Niski priorytet. Obrazy wczytują się z niskim priorytetem, dopóki układ strony nie zostanie ustalony, dlatego Shopify zaleca fetchpriority="high" na obrazie LCP (Shopify (otwiera się w nowej karcie)). web.dev zauważa, że ustawienie go na więcej niż jednym lub dwóch obrazach zmniejsza jego skuteczność (web.dev (otwiera się w nowej karcie)).
  • CSS i skrypty blokujące renderowanie. Duże arkusze stylów i synchroniczne skrypty w <head> opóźniają renderowanie nawet wtedy, gdy obraz już dotarł (web.dev (otwiera się w nowej karcie)).
  • Rozmiar plików i fonty. Stosuj nowoczesne formaty, srcset i sizes oraz CDN. W przypadku fontów internetowych używaj wartości font-display innej niż auto lub block.
<!-- Main product image: real src in the HTML, eager, high priority -->
<img src="/images/linen-shirt-1200.webp"
     srcset="/images/linen-shirt-600.webp 600w, /images/linen-shirt-1200.webp 1200w"
     sizes="(min-width: 990px) 50vw, 100vw"
     width="1200" height="1500"
     fetchpriority="high"
     alt="Natural linen shirt, front view">

<!-- Gallery images below the first screen: lazy -->
<img src="/images/linen-shirt-back-600.webp" loading="lazy"
     width="600" height="750" alt="Natural linen shirt, back view">

Co spowalnia INP na stronach sklepu?

Wolny INP w sklepie zwykle oznacza zbyt dużo JavaScriptu w wątku głównym, w dużej części z aplikacji, tagów śledzących i funkcji motywu, przez co dotknięcia muszą czekać.

Jeśli klient dotknie przycisku „Dodaj do koszyka”, gdy skrypty opinii, czatu i analityki wciąż działają, dotknięcie czeka. Wybór wariantu, który ponownie renderuje cały formularz produktu, wydłuża czas przetwarzania. Ogromne menu i siatki kolekcji z wieloma próbnikami kolorów zwiększają opóźnienie prezentacji.

web.dev zaleca dzielenie długich zadań i oddawanie sterowania wątkowi głównemu, aktualizowanie ekranu w pierwszej kolejności i odkładanie reszty na później oraz utrzymywanie mniejszego DOM (web.dev (otwiera się w nowej karcie)). Shopify dodaje kroki typowe dla sklepów: przejrzyj każdą aplikację, piksel i skrypt motywu, odrocz to, co nie jest niezbędne, wczytuj funkcje dopiero przy interakcji i wyłączaj fragmenty kodu zapobiegające migotaniu w testach A/B, gdy żaden test nie trwa (Shopify (otwiera się w nowej karcie)).

Co powoduje przesunięcia układu na stronach produktów i kolekcji?

Przesunięcia układu w sklepach biorą się głównie z treści, które pojawiają się lub zmieniają rozmiar po pierwszym renderowaniu: obrazów bez wymiarów, pasków z ogłoszeniami i plików cookie, widżetów opinii, bloków aplikacji i podmiany fontów.

web.dev wymienia jako typowe przyczyny multimedia o nieznanych wymiarach, treść dodawaną nad istniejącą treścią, widżety zewnętrzne, które same zmieniają rozmiar, oraz fonty internetowe o innym rozmiarze niż font zastępczy (web.dev (otwiera się w nowej karcie)). W sklepach oznacza to pasek darmowej dostawy wstawiany na górze strony, gwiazdki ocen wczytywane po tytule, informację o ratach pod ceną i karuzele z rekomendacjami. Shopify zaznacza, że przesunięcia mogą powodować także wyskakujące okna (Shopify (otwiera się w nowej karcie)).

Przesunięcia w ciągu 500 ms od działania użytkownika się nie liczą, ale przesunięcia podczas przewijania już tak, a narzędzia laboratoryjne często ich nie wychwytują (web.dev (otwiera się w nowej karcie)). Nadaj obrazom width i height albo CSS aspect-ratio, zarezerwuj miejsce na widżety, wyświetlaj banery jako nakładki, ogranicz przesunięcia przy podmianie fontów za pomocą size-adjust i animuj właściwością transform zamiast top lub left.

/* Reserve space for a reviews summary that loads after the page */
.product-reviews-summary { min-height: 24px; }

/* Keep product cards from jumping while images load */
.product-card img { width: 100%; height: auto; aspect-ratio: 4 / 5; }

Jak poprawić Core Web Vitals w Shopify?

W Shopify największe korzyści daje wczytywanie pierwszego obrazu od razu i z wysokim priorytetem, ograniczenie skryptów aplikacji i sprawdzanie wyników w raportach wydajności w panelu administracyjnym.

Sprawdź dane w panelu administracyjnym

Podsumowanie znajdziesz na stronie Online Store > Themes, a pełne raporty LCP, INP i CLS w sekcji Analytics > Reports. Dane mogą pojawiać się z opóźnieniem do 36 godzin, a tryb prywatny sklepu musi być wyłączony (Shopify Help Center (otwiera się w nowej karcie)).

Kontroluj wczytywanie obrazów w Liquid

Filtr image_tag wczytuje leniwie obrazy w sekcjach znajdujących się niżej na stronie, chyba że ustawisz preload (dokumentacja image_tag (otwiera się w nowej karcie)): od razu w sekcjach od 1 do 3, leniwie od sekcji 4. Ponieważ w edytorze motywu section.index ma wartość nil, w warunku używaj > 3, a nie <= 3:

{%- if section.index == 1 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'eager', fetchpriority: 'high', widths: '600, 900, 1200, 1600', sizes: '100vw' }}
{%- elsif section.index > 3 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'lazy', sizes: '100vw' }}
{%- else -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: sizes: '100vw' }}
{%- endif -%}

W siatkach produktów Shopify sugeruje wczytywanie od razu tylko kilku pierwszych kart (na przykład forloop.index <= 4) (Shopify (otwiera się w nowej karcie)). Z preload: true korzystaj oszczędnie: Shopify zaleca wstępne wczytywanie tylko jednego lub dwóch zasobów wykrywanych późno.

Usuń to, co zostawiają po sobie aplikacje

Wyłącz nieużywane osadzenia aplikacji w Online Store > Edit theme > App embeds (Shopify Help Center (otwiera się w nowej karcie)). Odinstalowanie aplikacji usuwa jej bloki, ale aplikacje, które bezpośrednio edytowały pliki motywu, mogą zostawić „martwy kod” (ghost code), który według Shopify może powodować problemy z jakością i wydajnością (Shopify (otwiera się w nowej karcie)). Shopify podaje też, że tagi skryptów (script tags) przestaną działać 1 marca 2027 r. W przypadku fontów Shopify zaleca własny CDN lub fonty systemowe zamiast zewnętrznych usług z fontami (Shopify (otwiera się w nowej karcie)).

Jak poprawić Core Web Vitals w WooCommerce?

W WooCommerce upewnij się, że wtyczki nie nadpisują ustalania priorytetów obrazów przez WordPressa, buforuj wszystko oprócz koszyka i kasy oraz usuń skrypty, które bez potrzeby wczytują się na każdej stronie.

  • Zachowaj obsługę obrazów z rdzenia. Od WordPressa 6.3 (wydanego 8 sierpnia 2023 r.) rdzeń dodaje fetchpriority="high" do obrazu, który najpewniej jest elementem LCP (domyślnie co najmniej 50 000 pikseli kwadratowych), i nie stosuje leniwego ładowania do pierwszych trzech obrazów w treści (Make WordPress Core (otwiera się w nowej karcie)). Jeśli wtyczka optymalizacyjna dodaje własne leniwe ładowanie, sprawdź, czy wyklucza z niego baner główny i główne zdjęcie produktu.
  • Buforuj strony, nie koszyki. Przewodnik WooCommerce zaleca buforowanie stron na serwerze lub za pomocą wtyczki oraz CDN, przy czym strony koszyka i kasy mają pozostać niebuforowane (dokumentacja dla deweloperów WooCommerce (otwiera się w nowej karcie)).
  • Sprawdź fragmenty koszyka. Od WooCommerce 7.8 skrypt cart fragments wczytuje się tylko tam, gdzie jest widżet koszyka, ale niektóre motywy mają ten widżet wpisany na stałe. Blok Mini-Cart nie korzysta z cart fragments (blog deweloperski WooCommerce (otwiera się w nowej karcie)).
  • Znajdź ciężkie wtyczki. WooCommerce sugeruje wtyczkę Query Monitor do wyszukiwania wolnych wtyczek oraz odraczanie niekrytycznego JavaScriptu.

Jeśli w Twoim układzie nad linią przewijania widać więcej niż trzy obrazy, możesz podnieść próg w WordPressie:

// functions.php: skip lazy loading for the first 4 content images (default is 3)
add_filter( 'wp_omit_loading_attr_threshold', function () {
    return 4;
} );

Po jakim czasie widać efekty poprawek?

Testy laboratoryjne pokazują efekt poprawki od razu, ale dane terenowe potrzebują do około czterech tygodni, by w pełni go odzwierciedlić, ponieważ CrUX uśrednia poprzednie 28 dni.

Przed zmianą i po niej uruchom test laboratoryjny kilka razy, bo pojedyncze pomiary się różnią, a potem obserwuj dane terenowe w PageSpeed Insights, raporcie Core Web Vitals w Search Console lub raportach Shopify. Bezpłatny skan daje pierwszy obraz sytuacji w mniej więcej minutę. Raport wydajności przeprowadza test laboratoryjny na urządzeniu mobilnym z ograniczeniem przepustowości (slow 4G, 4-krotne spowolnienie CPU) i dodaje dane terenowe z Chrome UX Report, w tym INP, jeśli Google ma wystarczająco dużo danych o Twoim sklepie.

Najczęściej zadawane pytania

Czy Core Web Vitals wpływają na pozycje w Google?

Google podaje, że Core Web Vitals są wykorzystywane przez jego systemy rankingowe, ale dobre wyniki nie gwarantują najwyższych pozycji, a wyszukiwarka nadal pokazuje najtrafniejsze treści nawet wtedy, gdy wrażenia z korzystania ze strony są słabe (Google Search Central (otwiera się w nowej karcie)).

Dlaczego PageSpeed Insights nie pokazuje danych terenowych dla mojego sklepu?

CrUX obejmuje tylko strony i domeny, które są publicznie wykrywalne i mają wystarczająco wielu kwalifikujących się użytkowników Chrome. Sklep z małym ruchem może mieć tylko dane na poziomie domeny albo nie mieć ich wcale, więc opieraj się na testach laboratoryjnych i raportach własnej platformy.

Czy do zaliczenia oceny potrzebny jest wynik Lighthouse 90 lub wyższy?

Nie. Wynik wydajności Lighthouse to rezultat testu laboratoryjnego, a ocena Core Web Vitals korzysta z danych terenowych dla 75. percentyla, więc strona może zaliczyć ocenę przy przeciętnym wyniku Lighthouse i nie zaliczyć jej przy wysokim.

Czy wszystkie zdjęcia produktów ładować leniwie?

Nie. Ładuj leniwie obrazy poniżej pierwszego ekranu, ale baner główny i główne zdjęcie produktu wczytuj od razu, z fetchpriority="high" na jednym z nich.

Dlaczego wyniki mobilne są gorsze niż na komputerze?

Google mierzy urządzenia mobilne i komputery osobno, a telefony mają wolniejsze procesory i sieci. Test mobilny Lighthouse symuluje to profilem Slow 4G i 4-krotnym spowolnieniem CPU.

Źródła

Wszystkie poradniki