LCP: co oznacza Largest Contentful Paint w sklepie

LCP, czyli Largest Contentful Paint, jest metryką opisującą moment, w którym największy istotny element treści widoczny w pierwszym widoku strony zostaje wyrenderowany. W sklepie internetowym ma to praktyczne znaczenie, ponieważ użytkownik może długo czekać nie na całą stronę, ale na konkretny element, który zajmuje dużą część ekranu. Może to być główne zdjęcie produktu, grafika banera, duży nagłówek albo blok tekstu.

Jeżeli zastanawiasz się, co to jest LCP, najprościej potraktować tę metrykę jako odpowiedź na pytanie: kiedy główna część widoku strony stała się faktycznie widoczna? Wynik podawany jest w sekundach, a jego interpretacja wymaga sprawdzenia nie tylko samej liczby, lecz także elementu wskazanego jako LCP i sposobu, w jaki przeglądarka musiała go pobrać oraz wyświetlić.

LCP w sklepie: co dokładnie mierzy ta metryka?

LCP mierzy czas od rozpoczęcia nawigacji do momentu wyrenderowania największego elementu treści znajdującego się w widocznym obszarze strony. Nie oznacza to czasu pełnego załadowania witryny. Strona może nadal pobierać skrypty, obrazy, fonty czy elementy dodatkowe, kiedy LCP został już osiągnięty.

To rozróżnienie jest szczególnie istotne w e-commerce. Sklep może mieć rozbudowany kod, rekomendacje produktów, czat, narzędzia analityczne i wiele innych elementów ładowanych w tle. Jeżeli główna treść widoczna po wejściu na stronę pojawi się odpowiednio wcześnie, użytkownik może zacząć korzystać ze strony jeszcze przed zakończeniem wszystkich procesów pobierania.

LCP jest jednym z Core Web Vitals. Obok LCP w tej grupie znajdują się INP, który dotyczy responsywności, oraz CLS, który opisuje stabilność wizualną. Jeżeli analizujesz całość wydajności sklepu, nie ograniczaj się więc do jednej liczby. Omówienie tego, czym są Core Web Vitals, pozwoli połączyć LCP z pozostałymi metrykami i spojrzeć na stronę szerzej.

Google wskazuje, że dla dobrego doświadczenia użytkownika należy dążyć do LCP na poziomie do 2,5 sekundy dla co najmniej 75 procent odwiedzin. Przedział powyżej 2,5 sekundy i do 4 sekund wymaga poprawy, natomiast wynik przekraczający 4 sekundy jest klasyfikowany jako słaby. Te progi odnoszą się do rzeczywistych doświadczeń użytkowników, dlatego przy analizie sklepu trzeba odróżnić dane terenowe od pojedynczego testu laboratoryjnego.

Co oznacza LCP na stronie?

W praktyce LCP odpowiada na pytanie, kiedy użytkownik zobaczył największą część głównej zawartości pierwszego widoku. Nie jest to więc bezpośredni pomiar całej szybkości strony.

Przykładowo na karcie produktu pierwszym kandydatem może być duże zdjęcie produktu. Na stronie kategorii może nim zostać duży baner albo blok tekstu znajdujący się nad listą produktów. Na stronie głównej sklepu kandydatem często będzie grafika hero, duży baner lub tekstowy nagłówek zajmujący znaczną część widocznego obszaru.

Trzeba też uważać na założenie, że największy element jest zawsze tym samym elementem. Przeglądarka może najpierw wyrenderować blok tekstu, a dopiero później główne zdjęcie. Jeżeli zdjęcie spełni warunki i będzie większym kandydatem, LCP może zostać ustalony właśnie na podstawie niego.

Jaki element strony może zostać uznany za LCP?

Lista potencjalnych elementów LCP jest ograniczona. W typowym przypadku mogą to być obrazy, elementy image wewnątrz SVG, wideo, element z obrazem tła oraz blok zawierający tekst. Nie każdy element DOM może więc automatycznie zostać kandydatem do LCP.

W sklepie internetowym najczęściej trzeba sprawdzić kilka miejsc.

Zdjęcie produktu. Na karcie produktu duża fotografia może zajmować znaczną część pierwszego widoku. Jeżeli jej pobranie lub wyświetlenie jest opóźnione, bezpośrednio wpływa to na LCP.

Baner lub grafika hero. Na stronie głównej sklepu duży obraz promocyjny może być największym elementem widocznym po wejściu. Problemem może być jego rozmiar, sposób osadzenia, priorytet pobierania albo opóźnienie spowodowane JavaScriptem.

Duży blok tekstu. LCP nie jest wyłącznie metryką obrazów. Jeżeli największym kandydatem jest tekst, opóźnienie może wynikać między innymi z blokowania renderowania, sposobu dostarczenia CSS lub fontu internetowego.

Wideo. W przypadku elementu wideo znaczenie może mieć między innymi moment wyświetlenia obrazu poster lub pierwszej klatki.

Obraz tła. Obraz ustawiony przez CSS również może być kandydatem. Dlatego samo sprawdzenie znaczników img w kodzie nie zawsze wystarcza.

Element musi być widoczny w obszarze ekranu. Liczy się jego widoczna powierzchnia, a elementy znajdujące się poza viewportem nie są traktowane w taki sam sposób jak treść widoczna od razu po wejściu na stronę. Przy obrazach znaczenie ma również ich rozmiar widoczny dla użytkownika oraz rozmiar źródłowy.

Istotny jest jeszcze jeden szczegół. Kandydat LCP może się zmieniać w czasie ładowania strony. Najpierw przeglądarka może uznać tekst za największy wyrenderowany element, a później zastąpić go większym obrazem. Dlatego w analizie trzeba sprawdzić końcowy element LCP, a nie tylko pierwszy element, który pojawił się na ekranie.

Od czego zależy wynik LCP sklepu?

Sam element LCP nie mówi jeszcze, dlaczego pojawił się późno. Aby znaleźć przyczynę, trzeba rozłożyć jego czas na kolejne etapy.

Pierwszym z nich jest TTFB, czyli czas potrzebny na otrzymanie pierwszej części odpowiedzi HTML od serwera. Jeżeli serwer długo generuje stronę albo odpowiedź przechodzi przez kilka opóźnionych etapów, LCP ma gorszy punkt startowy.

Kolejny etap to opóźnienie rozpoczęcia pobierania zasobu LCP. Obraz może istnieć na stronie, ale przeglądarka nie musi od razu zacząć go pobierać z najwyższym priorytetem. Taka sytuacja może wystąpić między innymi wtedy, gdy zasób jest odkrywany dopiero po wykonaniu JavaScriptu.

Następnie trzeba sprawdzić sam czas pobierania zasobu. Duży plik graficzny, niewłaściwy format, brak odpowiedniego wariantu responsywnego albo wolne połączenie mogą wydłużyć ten etap.

Na końcu pozostaje czas potrzebny na wyrenderowanie elementu. Nawet pobrany obraz nie musi natychmiast pojawić się użytkownikowi, jeżeli przeglądarka jest zajęta inną pracą, musi przetworzyć CSS lub JavaScript albo czeka na inne zależności.

W przypadku obrazu LCP można więc myśleć o problemie jako o kilku następujących po sobie odcinkach: odpowiedź serwera, rozpoczęcie pobierania, pobieranie zasobu oraz renderowanie. Takie rozbicie jest znacznie bardziej użyteczne niż samo stwierdzenie, że LCP wynosi kilka sekund.

Jeżeli sklep działa na WooCommerce, przyczyny opóźnienia mogą znajdować się między innymi w motywie, wtyczkach, zapytaniach do bazy, sposobie generowania HTML lub konfiguracji cache. Przy PrestaShop i Shoper trzeba podobnie przeanalizować sposób generowania strony oraz zasoby ładowane na początku. Omówienie tego, co spowalnia WooCommerce, może być przydatne, gdy problem dotyczy właśnie sklepu opartego na tej platformie.

Jak sprawdzić LCP sklepu?

Jeżeli pytasz, jak sprawdzić LCP sklepu, zacznij od PageSpeed Insights i raportu Core Web Vitals w Google Search Console. Przydatne są również Lighthouse oraz narzędzia deweloperskie Chrome.

PageSpeed Insights pozwala zobaczyć dane laboratoryjne oraz, gdy są dostępne, dane pochodzące z rzeczywistych użytkowników. To ważne rozróżnienie. Test wykonany na jednym komputerze i jednym połączeniu nie opisuje wszystkich osób odwiedzających sklep.

W Search Console raport Core Web Vitals pozwala sprawdzić, jak adresy URL radzą sobie w rzeczywistych warunkach użytkowania. Jeżeli wiele podstron ma podobny problem, może to wskazywać na wspólną przyczynę techniczną, na przykład sposób działania szablonu albo wspólne zasoby ładowane na stronach.

Lighthouse jest natomiast przydatny podczas diagnostyki konkretnego adresu. Raport wskazuje LCP i może pokazać element, który został uznany za największy. Jeżeli LCP jest obrazem, można również przeanalizować poszczególne części czasu potrzebnego do osiągnięcia tego wyniku.

W Chrome DevTools można sprawdzić między innymi ślad ładowania strony i zobaczyć, co działo się przed pojawieniem się elementu LCP. To szczególnie przydatne wtedy, gdy sam wynik z PageSpeed Insights mówi tylko, że LCP jest zbyt późny, ale nie pokazuje jeszcze konkretnej przyczyny.

Podczas testu sklepu nie ograniczaj się do strony głównej. Sprawdź co najmniej stronę główną, kategorię, kartę produktu oraz, jeżeli ma znaczenie dla sprzedaży, stronę koszyka lub inne główne szablony. Różne typy stron mogą mieć zupełnie inne elementy LCP.

W sklepie z rozbudowanym katalogiem dobrze jest sprawdzić także kilka reprezentatywnych produktów. Jedna karta może mieć lekkie zdjęcie, a inna duże grafiki lub dodatkowe moduły. Wynik pojedynczego adresu nie musi więc reprezentować całego sklepu.

Jak interpretować wynik LCP?

Nie traktuj LCP jako oceny całej witryny. Jest to konkretna metryka określająca moment wyrenderowania największego kwalifikującego się elementu treści w viewportcie.

Wynik do 2,5 sekundy mieści się w zakresie uznawanym za dobry. Wynik pomiędzy 2,5 a 4 sekundami wymaga poprawy. Powyżej 4 sekund mówimy o słabym wyniku. Przy ocenie danych rzeczywistych znaczenie ma rozkład wyników, a nie pojedynczy pomiar wykonany podczas ręcznego testu.

Jeżeli PageSpeed Insights pokazuje dobry wynik dla komputera, ale problem na urządzeniach mobilnych, nie zakładaj, że problem nie istnieje. Mobilne połączenie, mniejsza moc urządzenia i inne warunki ładowania mogą ujawnić problemy niewidoczne w teście desktopowym.

Podobnie nie porównuj bezpośrednio LCP z czasem pełnego załadowania strony. Sklep może mieć wysoki czas całkowitego ładowania, ale stosunkowo szybki LCP. Może też wyglądać odwrotnie: większość strony ładuje się sprawnie, ale duży element główny pojawia się dopiero po długim oczekiwaniu.

Jeżeli jednocześnie analizujesz przesuwanie elementów podczas ładowania, sprawdź także CLS. Wyjaśnienie, co oznacza CLS w sklepie, pomoże rozdzielić problem późnego pojawienia się treści od problemu niestabilnego układu strony.

Najważniejsze pojęcia związane z LCP i ich znaczenie

Pojęcie	Znaczenie
LCP	Czas wyrenderowania największego kwalifikującego się elementu treści widocznego w viewportcie.
Largest Contentful Paint	Pełna nazwa metryki LCP.
LCP element	Element wskazany przez przeglądarkę jako aktualny największy kandydat do LCP.
Viewport	Obszar strony widoczny na ekranie użytkownika.
TTFB	Czas od rozpoczęcia żądania do otrzymania pierwszego bajtu odpowiedzi.
FCP	Moment, w którym po raz pierwszy zostaje wyrenderowany fragment treści.
Render delay	Czas pomiędzy zakończeniem pobierania zasobu a jego faktycznym wyrenderowaniem.
Core Web Vitals	Zestaw metryk dotyczących ładowania, responsywności i stabilności wizualnej.
Dane terenowe	Pomiary pochodzące z rzeczywistych użytkowników i ich warunków korzystania ze strony.
Dane laboratoryjne	Wyniki kontrolowanego testu wykonanego w określonych warunkach.

Elementy strony wpływające na moment wystąpienia LCP

Przy audycie szybkości dobrze rozłożyć LCP na oś ładowania strony: rozpoczęcie nawigacji, odpowiedź HTML i TTFB, moment odkrycia zasobu LCP, rozpoczęcie jego pobierania, czas pobierania, przetwarzanie po stronie przeglądarki oraz końcowy moment wyrenderowania elementu LCP.

Na przykładzie sklepu z dużym zdjęciem produktu wygląda to tak. Najpierw przeglądarka otrzymuje HTML, następnie odkrywa adres zdjęcia, rozpoczyna pobieranie pliku, pobiera go, a na końcu renderuje obraz w widocznym obszarze. Jeżeli opóźnienie powstaje pomiędzy odpowiedzią serwera a rozpoczęciem pobierania obrazu, problem wymaga innego podejścia niż sytuacja, w której obraz jest szybko odnaleziony, ale ma bardzo duży plik.

Pamiętaj też, że LCP może zmieniać się podczas ładowania. Początkowo największym elementem może być tekst, a po pojawieniu się zdjęcia produktu to właśnie ono może zostać końcowym kandydatem. Dlatego analiza samej kolejności pojawiania się elementów nie zawsze wystarcza.

Co zrobić, gdy LCP sklepu jest zbyt wysoki?

Najpierw ustal, jaki element został wskazany jako LCP. Bez tego łatwo optymalizować niewłaściwą część strony.

Jeżeli LCP jest obrazem, sprawdź jego rozmiar, format, wersję dostarczaną na urządzenia mobilne, sposób osadzenia oraz moment rozpoczęcia pobierania. Duże zdjęcie produktu nie powinno być bez potrzeby pobierane w rozmiarze znacznie większym niż potrzebny do jego wyświetlenia.

Sprawdź także, czy obraz LCP nie jest ładowany dopiero po wykonaniu skryptu. Jeżeli przeglądarka może poznać zasób wcześniej, może to zmienić moment rozpoczęcia jego pobierania. Trzeba jednak analizować konkretny przypadek, zamiast automatycznie dodawać kolejne mechanizmy preload do wszystkich grafik.

Jeżeli LCP jest tekstem, sprawdź CSS, fonty i sposób generowania treści. Szczególnie istotne może być to, czy przeglądarka może odpowiednio wcześnie rozpocząć renderowanie głównej części strony.

Jeżeli problem zaczyna się już na poziomie TTFB, optymalizacja samego obrazu może nie rozwiązać głównej przyczyny. Wtedy sprawdź hosting, cache, odpowiedź aplikacji, zapytania do bazy danych, przekierowania oraz sposób generowania strony.

Nie optymalizuj wszystkich elementów sklepu w ciemno. Jeżeli raport wskazuje konkretny element LCP, zacznij od niego i od etapów poprzedzających jego wyrenderowanie. Przegląd tego, co realnie skraca czas ładowania sklepu, pomoże uporządkować szerszą analizę szybkości, kiedy problem nie ogranicza się do jednego obrazu.

W przypadku WooCommerce i PrestaShop można dodatkowo sprawdzić, czy motyw, moduły i wtyczki nie opóźniają wygenerowania głównej treści. Przy dużych sklepach istotne jest również porównanie różnych typów stron, ponieważ karta produktu może mieć inne źródło problemu niż strona kategorii.

Jeżeli po analizie chcesz przejść od samego wyniku do diagnozy przyczyny, audyt szybkości sklepu internetowego może być kolejnym krokiem. W takim audycie punktem wyjścia powinny być konkretne adresy, elementy LCP oraz dane pokazujące, na którym etapie powstaje opóźnienie.

LCP a dane z rzeczywistych użytkowników

Wynik laboratoryjny jest przydatny do diagnostyki, ale nie pokazuje wszystkich warunków, w jakich korzystają z witryny klienci. Użytkownicy mogą mieć inne urządzenia, połączenia internetowe, lokalizacje i ustawienia przeglądarek.

Dlatego przy ocenie Core Web Vitals należy patrzeć na dane terenowe, jeżeli są dostępne. Google wykorzystuje między innymi dane pochodzące z rzeczywistych wizyt do oceny doświadczenia użytkowników. W praktyce oznacza to, że sklep może mieć dobry wynik w pojedynczym teście Lighthouse, a jednocześnie część użytkowników może doświadczać znacznie wolniejszego LCP.

To również powód, dla którego nie należy wyciągać wniosków z jednego pomiaru. Powtórzony test może dać inny rezultat, szczególnie jeżeli zasoby zostały już zapisane w pamięci podręcznej albo zmieniły się warunki sieciowe.

Przy większym sklepie najlepiej połączyć kilka źródeł danych. Search Console pokazuje problemy widoczne w danych użytkowników, PageSpeed Insights pozwala spojrzeć na konkretny adres, a Lighthouse i DevTools pomagają znaleźć techniczną przyczynę opóźnienia.

LCP to punkt diagnostyczny, nie cała ocena sklepu

Dobre podejście do LCP zaczyna się od prostego pytania: co użytkownik powinien zobaczyć jako główną treść po wejściu na tę stronę? Następnie trzeba sprawdzić, który element faktycznie został wybrany jako LCP i dlaczego pojawił się właśnie w tym momencie.

Jeżeli największym elementem jest zdjęcie produktu, analizujesz przede wszystkim drogę tego obrazu od HTML do ekranu. Jeżeli jest nim tekst, szukasz opóźnień związanych z HTML, CSS, fontami i pracą przeglądarki. Jeżeli problem zaczyna się od wolnej odpowiedzi serwera, kierujesz analizę w stronę TTFB i zaplecza technicznego.

Takie podejście jest bardziej praktyczne niż poprawianie przypadkowych elementów tylko dlatego, że pojawiają się w raporcie Lighthouse. poznaj sposoby przyspieszania WooCommerce i PrestaShop przyda się wtedy, gdy analiza LCP prowadzi do szerszej optymalizacji platformy sklepowej.

LCP warto też analizować razem z pozostałymi Core Web Vitals. Szybkie pojawienie się głównej treści nie oznacza automatycznie, że strona działa dobrze pod każdym względem. Użytkownik może zobaczyć produkt szybko, ale chwilę później doświadczyć przesunięcia układu albo opóźnionej reakcji na kliknięcie.

Dlatego przy audycie sklepu potraktuj LCP jako jeden z punktów kontrolnych. Najpierw ustal wynik, potem zidentyfikuj element LCP, rozbij jego czas na etapy i dopiero wtedy wybierz konkretną zmianę techniczną. Tak przeprowadzona analiza pozwala przejść od samej liczby w raporcie do rzeczywistej przyczyny opóźnienia.