Przejdź do treści
Lexiik
performance

Core Web Vitals: LCP, INP, CLS — metryki SEO Google wyjaśnione

Ostatnia aktualizacja : 17 lutego 2026

Core Web Vitals to trzy metryki zdefiniowane przez Google do pomiaru jakości doświadczenia użytkownika na stronie internetowej. Wprowadzone w 2020 roku i zintegrowane z algorytmem rankingowym Google w 2021 roku za pośrednictwem aktualizacji Page Experience, są dziś oficjalnym czynnikiem SEO. Dla sklepów e-commerce zrozumienie i optymalizacja tych trzech wskaźników — LCP, INP i CLS — stało się równie ważne jak praca nad treścią czy link building.

Czym są Core Web Vitals?

Przed Core Web Vitals szybkość strony internetowej mierzono za pomocą technicznych metryk, takich jak Time to First Byte (TTFB) czy First Contentful Paint (FCP) — wskaźniki przydatne dla programistów, ale nieodzwierciedlające wiernie tego, czego faktycznie doświadcza użytkownik. Google postanowiło wypełnić tę lukę, definiując trzy metryki skoncentrowane na postrzeganym doświadczeniu: jak szybko pojawia się główna treść? Czy strona szybko reaguje na interakcje? Czy treść przesuwa się w nieoczekiwany sposób?

Te trzy pytania odpowiadają dokładnie trzem Core Web Vitals: LCP dla szybkości ładowania, INP dla responsywności i CLS dla stabilności wizualnej. Google zbiera te dane w formie zbiorczej za pośrednictwem Chrome (Chrome User Experience Report, czyli CrUX) i wykorzystuje je w swoim algorytmie, aby nagradzać strony oferujące dobre doświadczenie użytkownika.

LCP — Largest Contentful Paint: szybkość wyświetlania głównej treści

LCP (Largest Contentful Paint) mierzy czas, jaki upływa od momentu rozpoczęcia ładowania strony do chwili, gdy jej największy widoczny element zostaje w pełni wyrenderowany na ekranie. Element ten może być obrazem, tagiem wideo, blokiem tekstu lub dowolną inną treścią widoczną bez przewijania strony (above the fold).

W sklepach e-commerce LCP jest niemal zawsze zdeterminowany przez główne zdjęcie produktu — fotografię packshot zajmującą dużą część ekranu w górnej części karty produktu. To zdjęcie jest zazwyczaj najcięższe na stronie i tym samym wymaga najwięcej czasu na załadowanie. Dlatego optymalizacja LCP w kontekście e-commerce skupia się przede wszystkim na poprawie dostarczania obrazów.

Dobry LCP

Poniżej 2,5 sekundy. Google uznaje doświadczenie użytkownika za zadowalające.

⚠️

LCP do poprawy

Od 2,5 do 4 sekund. Strona znajduje się w pomarańczowej strefie — konieczne są ulepszenia.

Słaby LCP

Powyżej 4 sekund. Google obniża pozycję strony w wynikach wyszukiwania.

Główne przyczyny słabego LCP w sklepach e-commerce to: zbyt ciężkie zdjęcia produktów (nieoptymalny JPEG), wolny hosting z wysokim TTFB, brak CDN powodujący opóźnienie geograficzne oraz nieprawidłowo zastosowane leniwe ładowanie (lazy loading) dla głównego obrazu. Ten ostatni błąd jest częsty: atrybut loading="lazy" nie powinien być nigdy stosowany do obrazu above the fold, ponieważ uniemożliwia przeglądarce szybkie załadowanie elementu, który Google używa do obliczenia LCP.

INP — Interaction to Next Paint: responsywność strony

INP (Interaction to Next Paint) zastąpił FID (First Input Delay) w marcu 2024 roku jako oficjalny Core Web Vital. Podczas gdy FID mierzył jedynie opóźnienie odpowiedzi na pierwszą interakcję, INP mierzy opóźnienie wszystkich interakcji użytkownika przez cały czas życia strony — kliknięcia, dotknięcia na urządzeniach mobilnych, wpisywanie na klawiaturze — i przyjmuje wartość z 98. percentyla.

W praktyce INP mierzy czas między momentem, gdy użytkownik wchodzi w interakcję (np. klika przycisk «Dodaj do koszyka»), a momentem, gdy przeglądarka wyświetla wizualną odpowiedź na tę interakcję. Jeśli JavaScript jest ciężki i monopolizuje główny wątek przeglądarki, INP będzie wysoki: strona sprawia wrażenie «zamrożonej» lub wolno reagującej.

Dobry INP

Poniżej 200 milisekund. Interakcja wydaje się natychmiastowa dla użytkownika.

⚠️

INP do poprawy

Od 200 do 500 milisekund. Użytkownik odczuwa lekkie opóźnienie.

Słaby INP

Powyżej 500 milisekund. Interakcja wydaje się powolna i degradowana.

W sklepach e-commerce głównymi przyczynami słabego INP są: nadmierny JavaScript od podmiotów trzecich (widżety czatu, trackery analityczne, skrypty porównywarek cenowych), zbyt ciężkie handlery zdarzeń oraz obszerne biblioteki UI ładowane synchronicznie. Optymalizacja INP polega na audycie i ograniczeniu nieistotnego JavaScriptu oraz na opóźnieniu ładowania skryptów podmiotów trzecich do momentu po interakcji użytkownika.

CLS — Cumulative Layout Shift: stabilność wizualna strony

CLS (Cumulative Layout Shift) mierzy, w jakim stopniu widoczne elementy strony przesuwają się w nieoczekiwany sposób podczas ładowania. Za każdym razem, gdy widoczny element się przemieszcza — tekst, który skacze, bo obraz ładuje się bez zarezerwowanych wymiarów, baner reklamowy, który się wstawia i przesuwa treść w dół — CLS rośnie.

Wysoki CLS jest szczególnie frustrujący na urządzeniach mobilnych: użytkownik szykuje się do kliknięcia w link i w chwili, gdy palec dotyka ekranu, ładuje się obraz i przesuwa treść. Klika w inny link — czasem «Dodaj do koszyka», choć chciał przeczytać opis. To degradowane doświadczenie, które Google penalizuje.

Dobry CLS

Poniżej 0,1. Strona jest wizualnie stabilna podczas ładowania.

⚠️

CLS do poprawy

Od 0,1 do 0,25. Zauważalne przesunięcia wpływają negatywnie na doświadczenie.

Słaby CLS

Powyżej 0,25. Strona jest niestabilna i penalizowana przez Google.

Główną przyczyną wysokiego CLS w sklepach e-commerce jest brak jawnych wymiarów na obrazach (atrybuty width i height w HTML). Gdy przeglądarka przetwarza HTML i napotyka tag img bez wymiarów, nie może zarezerwować niezbędnego miejsca w układzie strony. Gdy obraz się ładuje i ujawnia swoje rzeczywiste wymiary, układ jest przeliczany i wszystko się przesuwa. Rozwiązanie jest proste: zawsze określaj width i height w tagach img lub używaj właściwości CSS aspect-ratio.

Jak Core Web Vitals wpływają na pozycję w Google

Google używa Core Web Vitals jako sygnału rankingowego od czerwca 2021 roku. Technicznie stanowią one część szerszego sygnału zwanego «Page Experience», który obejmuje również przyjazność dla urządzeń mobilnych, bezpieczeństwo HTTPS i brak natrętnych treści interstitial. Google wyjaśnił, że wartościowe treści pozostają dominującym sygnałem, ale Core Web Vitals mogą decydować między dwiema stronami o równoważnej jakości.

W praktyce Google ocenia Core Web Vitals za pomocą dwóch źródeł danych: danych terenowych (field data), anonimowo zbieranych przez Chrome z rzeczywistych wizyt użytkowników, oraz danych laboratoryjnych (lab data), obliczanych przez narzędzia takie jak Lighthouse w kontrolowanych warunkach. Dane terenowe — agregowane w Chrome User Experience Report (CrUX) — są tymi, które zasilają algorytm. Strona musi otrzymywać wystarczający ruch z Chrome, aby pojawić się w CrUX; strony z małym ruchem są oceniane na poziomie domeny lub głównego adresu URL.

Mobile-first: Core Web Vitals są oceniane priorytetowo na urządzeniach mobilnych

Google priorytetowo traktuje dane mobilne przy ocenie Core Web Vitals w swoim algorytmie. Połączenia mobilne są wolniejsze, a procesory mniej wydajne niż na komputerach stacjonarnych. Sklep, który uzyskuje dobre wyniki na desktopie, może mieć słabe wyniki na mobile, jeśli jego obrazy nie są zoptymalizowane pod kątem sieci 4G/5G.

Wyzwania specyficzne dla e-commerce

Sklepy internetowe stoją przed kilkoma wyzwaniami, które sprawiają, że optymalizacja Core Web Vitals jest szczególnie trudna. Po pierwsze, wolumen zdjęć: sklep z 1000 produktami i 5 zdjęciami na produkt musi zarządzać 5000 obrazami, z których każdy wymaga optymalizacji pod względem rozmiaru, formatu i wymiarów. Następnie złożoność stron: karty produktów z galeriami, karuzelami, zoomem, zakładkami opisów, widżetami opinii klientów, konfiguratorem wariantów — to wszystko komponenty JavaScript, które mogą degradować INP.

  • Ciężkie zdjęcia produktów bez optymalizacji formatu (nieoptymalny JPEG zamiast WebP/AVIF)
  • Karuzele i galerie z JavaScriptem podmiotów trzecich blokującym główny wątek
  • Nieprawidłowo skonfigurowane lazy loading zastosowane do obrazu hero (degraduje LCP)
  • Obrazy bez jawnych atrybutów width/height w szablonach (degraduje CLS)
  • Skrypty śledzące analytics i remarketing ładowane synchronicznie (degraduje INP)
  • Wolny hosting współdzielony z wysokim TTFB wpływający na wszystkie Core Web Vitals

Jak Lexiik poprawia Twoje Core Web Vitals

Lexiik działa głównie na LCP i CLS — dwa Core Web Vitals najbardziej bezpośrednio związane z obrazami. Dla LCP, CDN Cloudflare drastycznie skraca czas dostarczania głównego zdjęcia produktu, serwując je z węzła geograficznie bliskiego odwiedzającemu, z nagłówkami cache na rok. Dla CLS, Lexiik gwarantuje, że obrazy serwowane przez CDN zachowują swoje oryginalne wymiary, umożliwiając przeglądarce zarezerwowanie odpowiedniego miejsca przed pełnym załadowaniem.

Automatyczna konwersja do WebP i AVIF zmniejsza rozmiar obrazów o 30 do 50% bez widocznej utraty jakości, co nie tylko przyspiesza LCP, ale poprawia również ogólne odczuwalne metryki wydajności. Na mobilnych połączeniach 4G przejście od obrazu JPEG o rozmiarze 400 KB do obrazu WebP o rozmiarze 120 KB może obniżyć LCP z 3,5 sekundy do poniżej 1,5 sekundy.

Jak sprawdzić swoje wyniki Core Web Vitals

Kilka narzędzi pozwala mierzyć i monitorować Core Web Vitals. Google Search Console to narzędzie referencyjne dla rzeczywistych danych terenowych (CrUX): sekcja «Wrażenia na stronie» wyświetla procent adresów URL Twojej witryny sklasyfikowanych jako «Dobre wrażenia», «Do poprawy» lub «Słabe wrażenia», ze szczegółowym podziałem na metryki. To właśnie to narzędzie odzwierciedla to, co Google faktycznie widzi.

  • Google Search Console (search.google.com/search-console): rzeczywiste dane terenowe, według adresu URL lub grupy adresów URL
  • PageSpeed Insights (pagespeed.web.dev): dane terenowe + dane laboratoryjne dla konkretnego adresu URL
  • Google Lighthouse (wbudowany w Chrome DevTools): wyłącznie dane laboratoryjne, przydatne podczas tworzenia
  • Chrome DevTools > zakładka Wydajność: szczegółowa analiza zdarzeń renderowania i interakcji
  • web.dev/measure: narzędzie Google do szybkiej analizy online

Dane terenowe vs. dane laboratoryjne

Dane laboratoryjne (Lighthouse) mierzą stronę w symulowanych warunkach w symulowanej sieci. Dane terenowe (CrUX) odzwierciedlają rzeczywiste wizyty prawdziwych użytkowników. Te dwa źródła mogą się znacznie od siebie różnić. Dla SEO liczą się dane terenowe. Do diagnozowania problemów bardziej przydatne są dane laboratoryjne, ponieważ dostarczają precyzyjnych szczegółów na temat przyczyn.