INP, LCP i CLS: jak czytać wyniki PageSpeed Insights

PageSpeed Insights Core Web Vitals: od raportu do konkretnej poprawki

Jeżeli wpisujesz adres sklepu do PageSpeed Insights, dostajesz znacznie więcej niż jedną ocenę wydajności. Raport pokazuje dane laboratoryjne, dane rzeczywistych użytkowników, poszczególne metryki oraz listę diagnostyki. Dlatego fraza PageSpeed Insights Core Web Vitals nie powinna oznaczać sprawdzania wyłącznie zielonego lub czerwonego wyniku. Trzeba ustalić, która metryka wypada słabo, na jakiej wersji urządzenia, z jakiego powodu i jaki element strony może być za to odpowiedzialny.

W przypadku sklepu internetowego ma to szczególne znaczenie. Strona główna może mieć zupełnie inny profil wydajności niż karta produktu, koszyk albo kategoria z dużą liczbą zdjęć i filtrów. Jeden wynik PageSpeed nie opisuje więc całego sklepu.

Jeżeli chcesz sprawdzić zakres audytu technicznego sklepu, zacznij od ustalenia, które typy stron generują problem. Dopiero później przechodź do konkretnych plików, skryptów, obrazów czy ustawień serwera.

Jak czytać PageSpeed Insights bez patrzenia tylko na punktację

Pierwszy błąd polega na traktowaniu wyniku Performance jako oceny całej strony. Punktacja jest wygodnym skrótem, ale podczas optymalizacji ważniejsze są konkretne metryki i informacje diagnostyczne. Możesz mieć przyzwoity wynik ogólny, a jednocześnie problem z LCP na urządzeniach mobilnych. Możesz też zobaczyć niski wynik laboratoryjny, podczas gdy dane rzeczywistych użytkowników pokazują poprawne Core Web Vitals.

PageSpeed Insights korzysta z dwóch rodzajów danych. Dane laboratoryjne są generowane podczas kontrolowanego testu Lighthouse. Pozwalają odtworzyć określone warunki i sprawdzić, co dzieje się podczas ładowania strony. Dane rzeczywistych użytkowników pochodzą z Chrome User Experience Report, czyli CrUX. Pokazują doświadczenia użytkowników, o ile dla analizowanego adresu lub całej domeny dostępna jest wystarczająca ilość danych.

To rozróżnienie jest podstawą tego, jak czytać PageSpeed Insights. Dane laboratoryjne służą przede wszystkim do szukania przyczyn. Dane terenowe pokazują, jak strona faktycznie wypada wśród użytkowników.

W raporcie zwróć uwagę najpierw na sekcję dotyczącą rzeczywistych użytkowników. Sprawdź osobno urządzenia mobilne i komputery. Jeżeli wyniki są dostępne dla konkretnego adresu, zobacz je właśnie tam. Jeżeli PageSpeed Insights nie ma wystarczających danych dla URL, może pokazać dane na poziomie całej domeny. Nie oznacza to, że każdy adres w sklepie ma identyczną wydajność.

Dopiero po tym przejdź do danych laboratoryjnych. W nich szukaj elementów, które można technicznie powiązać z problemem. Jeżeli LCP jest słaby, sprawdzasz przede wszystkim sposób ładowania głównego elementu treści. Jeżeli problem dotyczy INP, analizujesz JavaScript i reakcję interfejsu. Przy CLS szukasz elementów, które zmieniają swoje położenie podczas ładowania lub interakcji.

Sekcja raportu	Co pokazuje	Jak ją wykorzystać
Dane rzeczywistych użytkowników	Doświadczenia użytkowników zebrane w CrUX	Sprawdź, czy problem występuje w realnym ruchu
Dane laboratoryjne	Wynik kontrolowanego testu Lighthouse	Szukaj technicznych przyczyn problemu
Core Web Vitals	LCP, INP i CLS	Ustal, który obszar doświadczenia użytkownika wymaga pracy
Diagnostyka	Konkretne ostrzeżenia i informacje techniczne	Znajdź elementy, zasoby lub procesy związane z metryką
Pozostałe metryki	Między innymi FCP, TTFB i TBT	Uzupełnij diagnozę i znajdź źródło opóźnienia
Performance	Zbiorcza punktacja Lighthouse	Traktuj jako wskaźnik pomocniczy, nie jako diagnozę

Jeżeli pracujesz nad sklepem regularnie, nie porównuj bezpośrednio każdego wyniku z poprzednim testem bez sprawdzenia warunków. Wynik laboratoryjny może się zmieniać w zależności od sposobu testowania, wersji narzędzi, zasobów strony czy chwilowego zachowania serwera.

LCP: sprawdź, co użytkownik czeka zobaczyć

LCP, czyli Largest Contentful Paint, opisuje moment, w którym pojawia się największy istotny element widoczny w obszarze ekranu. W praktyce może nim być duże zdjęcie produktu, grafika w hero, nagłówek albo inny element dominujący w pierwszym widoku.

Dla Core Web Vitals dobry wynik LCP mieści się w granicy do 2,5 sekundy. Zakres powyżej 2,5 sekundy do 4 sekund oznacza potrzebę poprawy, a wynik powyżej 4 sekund jest klasyfikowany jako słaby. W danych rzeczywistych ocena Core Web Vitals jest oparta na 75. percentylu, osobno dla urządzeń mobilnych i komputerów.

Sama liczba nie mówi jednak, co należy zrobić. Jeżeli raport pokazuje słaby LCP, otwórz szczegóły i sprawdź, jaki element został uznany za LCP. To może zmienić kierunek całej optymalizacji.

Jeżeli LCP jest zdjęciem, sprawdź jego rozmiar, format, sposób kompresji, odpowiedź serwera i sposób dostarczenia zasobu. Nie wystarczy zmniejszyć zdjęcia w edytorze graficznym, jeżeli sklep nadal wysyła użytkownikowi znacznie większy plik niż potrzebny na konkretnym urządzeniu.

Jeżeli LCP jest tekstem, sprawdź między innymi sposób ładowania czcionek, CSS i zasobów blokujących renderowanie. Jeżeli element pojawia się dopiero po wykonaniu JavaScriptu, trzeba ustalić, dlaczego przeglądarka nie może wcześniej wyrenderować głównej części strony.

Przy LCP warto patrzeć również na TTFB i FCP. TTFB pokazuje, jak długo trzeba czekać na rozpoczęcie odpowiedzi serwera, a FCP wskazuje moment pojawienia się pierwszego elementu treści. Jeżeli serwer odpowiada wolno, nie rozwiążesz całego problemu przez zmianę obrazów. Jeżeli TTFB jest rozsądny, ale później długo nic istotnego się nie pojawia, szukaj problemu po stronie renderowania i zasobów.

W sklepie internetowym LCP trzeba sprawdzać na różnych typach stron. Dla strony głównej problemem może być duży baner. Na kategorii może to być grafika lub element nagłówkowy. Na karcie produktu często znaczenie ma główne zdjęcie produktu oraz sposób ładowania całej galerii.

Nie zaczynaj więc od masowego usuwania skryptów. Najpierw ustal, czym dokładnie jest LCP i na jakim etapie ładowania powstaje opóźnienie. Dopiero wtedy wybierz poprawkę.

INP: sprawdź, dlaczego sklep nie reaguje od razu

INP, czyli Interaction to Next Paint, dotyczy responsywności strony podczas interakcji. Metryka bierze pod uwagę reakcję strony na działania użytkownika, takie jak kliknięcie, dotknięcie ekranu czy wpisywanie danych.

Dobry INP to wartość do 200 milisekund. Zakres powyżej 200 do 500 milisekund oznacza potrzebę poprawy, a wynik powyżej 500 milisekund jest słaby.

W praktyce problem z INP często pojawia się w miejscach, które właściciel sklepu uważa za normalne. Klikasz filtr kategorii i interfejs przez chwilę nie reaguje. Otwierasz menu mobilne, ale ekran nie zmienia się od razu. Wpisujesz dane w formularzu, a pole reaguje z opóźnieniem. Klikasz przycisk dodania produktu do koszyka i przez moment nie wiesz, czy kliknięcie zostało zarejestrowane.

Tutaj samo patrzenie na czas ładowania strony niewiele daje. INP dotyczy interakcji, dlatego trzeba znaleźć kod wykonywany w momencie działania użytkownika.

W danych laboratoryjnych INP nie jest mierzony tak jak w danych rzeczywistych, ponieważ test laboratoryjny nie wykonuje normalnych interakcji użytkownika. Dlatego podczas analizy laboratoryjnej przydatny jest TBT, czyli Total Blocking Time. Nie jest on tym samym co INP, ale pomaga wykryć blokowanie głównego wątku podczas ładowania.

Jeżeli TBT jest wysoki, sprawdź JavaScript. Szczególnie interesują Cię duże paczki skryptów, długie zadania głównego wątku, niepotrzebne biblioteki i funkcje wykonywane przy starcie strony.

W sklepie problem może powodować również kilka niezależnych elementów. Filtry produktów, wyszukiwarka AJAX, konfiguratory wariantów, popupy, czaty, narzędzia analityczne, systemy rekomendacji i dodatkowe skrypty marketingowe mogą wykonywać kod w tym samym czasie.

Nie usuwaj jednak skryptu tylko dlatego, że pojawia się w raporcie. Sprawdź, co robi, kiedy się uruchamia i czy jego działanie ma związek z konkretną interakcją. Jeżeli sklep potrzebuje danego mechanizmu, lepszym rozwiązaniem może być ograniczenie zakresu jego działania, opóźnienie uruchomienia albo zmiana sposobu obsługi zdarzeń.

Jeżeli chcesz sprawdzić Core Web Vitals w sklepie, patrz na INP jak na problem konkretnej reakcji interfejsu, a nie ogólnej szybkości strony. To pomaga uniknąć optymalizacji, która poprawia wynik laboratoryjny, ale nie rozwiązuje problemu odczuwanego przez użytkownika.

CLS: znajdź element, który przesuwa stronę

CLS, czyli Cumulative Layout Shift, mierzy stabilność wizualną strony. Problem występuje wtedy, gdy widoczne elementy zmieniają położenie bez oczekiwanej akcji użytkownika.

Dobry wynik CLS to 0,1 lub mniej. Wynik powyżej 0,1 do 0,25 oznacza potrzebę poprawy, a powyżej 0,25 jest klasyfikowany jako słaby.

W sklepie internetowym typowym przykładem jest zdjęcie bez zarezerwowanego miejsca. Strona zaczyna się ładować, tekst jest już widoczny, a chwilę później pojawia się zdjęcie. Obraz zajmuje miejsce i przesuwa treść w dół. Podobny problem może wystąpić przy banerze, pasku promocyjnym, reklamie, osadzonym materiale albo dynamicznym elemencie dodawanym przez JavaScript.

Przy CLS nie wystarczy sprawdzić, czy strona po pełnym załadowaniu wygląda stabilnie. Trzeba sprawdzić, co działo się podczas ładowania oraz później, gdy użytkownik korzysta ze strony. Dane laboratoryjne mogą nie wychwycić przesunięć, które pojawiają się dopiero po interakcji albo po zakończeniu początkowego ładowania.

Zacznij od znalezienia elementu powodującego przesunięcie. Następnie sprawdź, czy element ma określone wymiary, czy miejsce na niego jest zarezerwowane i czy jego zawartość nie jest wstrzykiwana w sposób zmieniający układ strony.

W przypadku zdjęć zadbaj o określenie wymiarów. Przy reklamach i banerach sprawdź, czy kontener ma zarezerwowaną przestrzeń. Przy elementach dynamicznych sprawdź, czy pojawienie się komunikatu, paska lub modułu nie przesuwa już widocznej treści.

CLS wymaga też ostrożności przy interpretacji wartości. Niewielka zmiana może wyglądać niegroźnie w pojedynczym teście, ale dane rzeczywistych użytkowników mogą pokazać inny obraz. Dlatego porównuj dane laboratoryjne z danymi terenowymi zamiast wybierać jeden wynik jako jedyną prawdę.

Wyniki Core Web Vitals: jak ustalić priorytet poprawek

Gdy masz już wyniki LCP, INP i CLS, nie poprawiaj wszystkiego jednocześnie. Najpierw przypisz każdemu problemowi konkretny element strony i określ, czy dotyczy danych rzeczywistych, laboratoryjnych, czy obu źródeł.

Przykładowo, jeżeli LCP jest słaby w danych rzeczywistych, a w laboratorium również widzisz opóźnienie głównego elementu, problem ma mocne potwierdzenie. Wtedy analizujesz element LCP, TTFB, FCP i zasoby potrzebne do jego wyświetlenia.

Jeżeli LCP wygląda dobrze w laboratorium, ale słabo w danych rzeczywistych, nie zakładaj automatycznie, że raport jest błędny. Różnica może wynikać z urządzeń użytkowników, sieci, lokalizacji, pamięci podręcznej, sposobu korzystania ze strony albo różnic między środowiskiem testowym a prawdziwym ruchem.

Podobnie z CLS. Jeżeli laboratorium pokazuje dobry wynik, ale dane terenowe są słabsze, szukaj przesunięć występujących po początkowym ładowaniu. Przy INP szczególnie ważne są realne interakcje, których standardowy test laboratoryjny nie odwzorowuje w pełni.

Dopiero po określeniu źródła problemu przejdź do zmian. W praktyce możesz przyjąć prostą kolejność: najpierw Core Web Vitals w danych rzeczywistych, następnie konkretna metryka, później element lub proces powodujący problem, a na końcu konkretna poprawka.

Takie podejście jest znacznie bardziej użyteczne niż gonienie za wynikiem 100 punktów. Jeżeli raport wskazuje problem z obrazem LCP, optymalizujesz dostarczenie obrazu. Jeżeli wskazuje blokujący JavaScript, analizujesz wykonywany kod. Jeżeli wskazuje przesunięcie layoutu, szukasz elementu, który nie ma stabilnie zarezerwowanego miejsca.

Jeżeli przygotowujesz audyt techniczny przed działaniami SEO, PageSpeed powinien być jednym z elementów szerszego sprawdzenia sklepu, a nie jedynym źródłem informacji o stanie technicznym witryny.

PageSpeed SEO: co z wyników wynika dla widoczności sklepu

PageSpeed SEO nie oznacza, że istnieje jedna punktacja, którą trzeba osiągnąć, aby sklep zaczął się pozycjonować. PageSpeed Insights jest narzędziem diagnostycznym. Raport pozwala znaleźć problemy z wydajnością i doświadczeniem użytkownika, ale nie zastępuje analizy technicznego SEO, treści, indeksowania, linkowania wewnętrznego ani dopasowania strony do intencji wyszukiwania.

Core Web Vitals są wykorzystywane przez Google jako element oceny doświadczenia strony. Nie oznacza to jednak, że poprawienie jednej metryki automatycznie przełoży się na wzrost pozycji. W SEO liczy się cały zestaw sygnałów i jakość strony w kontekście zapytania użytkownika.

Dlatego pytanie PageSpeed Insights a SEO najlepiej rozdzielić na dwie części. Pierwsza brzmi: czy strona działa technicznie poprawnie i zapewnia odpowiednią jakość doświadczenia? Druga: czy strona odpowiada na potrzeby użytkownika i może być prawidłowo crawlowana, indeksowana oraz oceniana w kontekście wyników wyszukiwania?

Jeżeli sklep ma problemy z LCP, INP lub CLS, rozwiązuj je z myślą o konkretnej stronie i jej użytkownikach. Nie usuwaj istotnych funkcji tylko po to, aby zwiększyć punktację. Nie zamieniaj dobrego zdjęcia produktu na słabsze wyłącznie dlatego, że raport wskazał jego rozmiar. Sprawdź, czy problem można rozwiązać przez właściwe wymiary, format, kompresję, priorytet ładowania lub sposób dostarczania zasobu.

Tak samo nie warto wyłączać całego systemu filtrów tylko dlatego, że JavaScript wpływa na INP. Najpierw ustal, który fragment kodu blokuje interakcję i czy można zmienić sposób jego wykonania.

Co oznaczają wyniki PageSpeed sklepu w praktyce

Właściciel sklepu często zaczyna od strony głównej. To dobry punkt startowy, ale nie powinien być końcem testów. Sklep może mieć inną wydajność na stronie produktu, kategorii, wynikach wyszukiwania i koszyku.

Dla każdego typu strony sprawdź przede wszystkim, czy występują te same problemy. Jeżeli wszystkie kategorie mają podobny LCP, prawdopodobnie warto szukać wspólnego elementu szablonu, sposobu dostarczania obrazów albo problemu po stronie serwera. Jeżeli problem występuje tylko na jednym szablonie produktu, zawężasz analizę do tego widoku.

Na stronie kategorii zwróć uwagę na zdjęcia, filtry i skrypty odpowiadające za dynamiczne filtrowanie. Na karcie produktu sprawdź główne zdjęcie, galerię, warianty, rekomendacje oraz dodatkowe moduły. Na koszyku i checkout szczególnie interesuje Cię responsywność interfejsu, ponieważ użytkownik wykonuje tam wiele interakcji.

Testuj również osobno mobile i desktop. Jeżeli problem występuje głównie na mobile, nie zakładaj, że wystarczy zmienić jedną regułę CSS. Urządzenie mobilne może mieć słabszy procesor, wolniejsze połączenie i inne warunki ładowania zasobów. Skrypt, który na komputerze wykonuje się niemal niezauważalnie, może być znacznie bardziej odczuwalny na telefonie.

Jeżeli po zmianach wykonujesz kolejny test, zachowaj informacje o tym, co zostało zmienione. Inaczej trudno będzie ustalić, czy poprawa lub pogorszenie wyniku ma związek z konkretną modyfikacją. Przy większym sklepie dobrze jest testować ten sam URL i porównywać te same elementy raportu.

Od ostrzeżenia w PageSpeed do elementu strony

Najbardziej praktyczny sposób pracy z raportem można sprowadzić do kilku pytań. Najpierw sprawdź, czy problem jest widoczny w danych rzeczywistych. Następnie określ, której metryki dotyczy. Później znajdź element wskazany w diagnostyce i sprawdź jego zależności.

Przy LCP pytanie brzmi: co jest największym elementem treści i dlaczego pojawia się tak późno? Przy INP: jaka interakcja jest opóźniona i jaki kod blokuje reakcję strony? Przy CLS: który element zmienia położenie i dlaczego przeglądarka nie zna jego wymiarów lub stabilnego miejsca wcześniej?

Dopiero po odpowiedzi na te pytania wybierasz rozwiązanie.

Jeżeli problemem jest duży obraz, analizujesz obraz. Jeżeli problemem jest odpowiedź serwera, analizujesz serwer, cache, zapytania i sposób generowania strony. Jeżeli problemem jest JavaScript, analizujesz skrypt, jego rozmiar, kolejność uruchamiania i zadania wykonywane na głównym wątku. Jeżeli problemem jest przesunięcie layoutu, analizujesz wymiary elementów i sposób ich dynamicznego dodawania.

Tak wygląda użyteczna interpretacja PageSpeed Insights. Raport nie jest listą poleceń do bezrefleksyjnego odhaczenia. Jest punktem wyjścia do diagnozy.

Jeżeli analiza pokazuje kilka niezależnych problemów, sprawdzenie Core Web Vitals krok po kroku pozwala uporządkować metryki i przejść od samego wyniku do źródła problemu.

Jak przygotować własną checklistę po analizie PageSpeed

Po zakończeniu testu zapisz osobno problemy dotyczące LCP, INP i CLS. Przy każdym dopisz adres strony, urządzenie, źródło danych oraz element, którego dotyczy problem.

Dla LCP możesz zapisać nazwę elementu LCP, jego typ, adres zasobu, TTFB, FCP i informacje o ładowaniu zasobu. Przy INP zanotuj problematyczną interakcję, powiązany skrypt oraz informacje o długich zadaniach JavaScript. Przy CLS zapisz element powodujący przesunięcie i moment, w którym następuje zmiana układu.

Następnie oddziel poprawki techniczne od zmian wymagających decyzji biznesowej. Usunięcie nieużywanego skryptu jest decyzją techniczną. Rezygnacja z funkcji sklepu tylko po to, aby zmienić wynik PageSpeed, może już wpływać na sprzedaż i sposób korzystania z witryny. Te decyzje trzeba podejmować osobno.

Nie traktuj też wyniku z jednego URL jako diagnozy całej platformy. WooCommerce, PrestaShop, Shoper i inne systemy mogą mieć wspólne mechanizmy, ale każdy sklep ma własny zestaw modułów, integracji, skryptów i konfiguracji serwera.

Jeżeli po analizie nadal nie potrafisz wskazać elementu strony odpowiedzialnego za problem, to znak, że sam wynik PageSpeed nie wystarcza do dalszej diagnozy. Wtedy potrzebujesz analizy kodu, waterfallu zasobów, narzędzi deweloperskich i danych rzeczywistych.

W przypadku sklepu internetowego właśnie na tym etapie raport przestaje być zwykłym testem szybkości, a staje się materiałem do konkretnej pracy technicznej. Audyt szybkości sklepu internetowego może wtedy służyć jako kolejny krok, gdy potrzebujesz przejść od raportu do ustalenia, co faktycznie wymaga poprawy.

Podsumowanie: PageSpeed Insights jako narzędzie diagnostyczne

PageSpeed Insights warto czytać od danych do przyczyny, a nie od punktacji do przypadkowej optymalizacji. Najpierw sprawdź dane rzeczywistych użytkowników i rozdziel mobile od desktopu. Następnie zobacz LCP, INP i CLS, a potem przejdź do diagnostyki, która pomaga znaleźć konkretny element strony.

LCP odpowiada na pytanie, kiedy użytkownik otrzymuje główną treść. INP pokazuje, jak szybko strona reaguje na działania użytkownika. CLS pozwala znaleźć nieoczekiwane przesunięcia elementów. Każda z tych metryk opisuje inny problem i wymaga innego sposobu diagnozy.

Dane laboratoryjne są bardzo przydatne do szukania przyczyn, ale nie zastępują danych rzeczywistych. Szczególnie przy INP i CLS różnica między kontrolowanym testem a zachowaniem prawdziwych użytkowników może mieć duże znaczenie.

Jeżeli więc zastanawiasz się, co oznaczają wyniki PageSpeed sklepu, nie zaczynaj od pytania, jak zdobyć wyższą punktację. Zacznij od pytania, który element strony powoduje konkretny problem, w jakich warunkach występuje i jakie dane to potwierdzają. Dopiero wtedy wybierz poprawkę i ponownie sprawdź efekt.

To podejście pozwala wykorzystać PageSpeed Insights zgodnie z jego przeznaczeniem: jako narzędzie do diagnozowania wydajności, a nie prosty ranking stron.