LCP (Largest Contentful Paint) - co to jest i jak poprawić czas ładowania? | Critical - Strategiczny Partner Marketingu Cyfrowego

Largest Contentful Paint (LCP) to jedna z trzech metryk Core Web Vitals, które Google wykorzystuje w swoich systemach rankingowych. Mierzy czas od rozpoczęcia nawigacji do wyrenderowania największego obrazu, bloku tekstu lub filmu widocznego w obszarze ekranu. W praktyce LCP odpowiada na pytanie: jak szybko użytkownik widzi główną treść strony?

Dla właścicieli sklepów internetowych i stron firmowych to metryka o bezpośrednim przełożeniu na biznes. Wolne ładowanie oznacza wyższy współczynnik odrzuceń, niższą konwersję i potencjalnie gorsze pozycje w wynikach wyszukiwania.

Który element zostaje LCP?

Google nie patrzy na całą stronę - analizuje tylko największy element widoczny w viewporcie (czyli w obszarze ekranu bez przewijania). Jako największy element mogą zostać zakwalifikowane:

elementy <img> — najczęstszy przypadek, szczególnie zdjęcia hero i banery,
elementy <image> osadzone wewnątrz SVG,
elementy <video> — obraz plakatu albo pierwsza klatka filmu,
elementy z tłem ustawionym przez background-image w CSS — obrazy ładowane przez url(), ale nie gradienty,
bloki tekstu — na przykład <p> lub <h1>, jeśli zajmują największą powierzchnię.

W sklepach internetowych największym elementem jest niemal zawsze główne zdjęcie produktu lub baner na stronie głównej. Na blogach często jest to zdjęcie wyróżniające artykułu lub sam blok tekstu.

Warto wiedzieć, że przeglądarka może kilkukrotnie zmieniać “kandydata” na largest element w trakcie ładowania. Początkowo może to być blok tekstu, który zostanie zastąpiony przez obraz po jego załadowaniu. LCP rejestruje ostatni taki element przed momentem interakcji użytkownika ze stroną.

Progi oceny LCP

Google stosuje trzy przedziały do oceny wyniku LCP:

dobry - maksymalnie 2,5 sekundy
wymaga poprawy - powyżej 2,5 do 4 sekund włącznie
słaby - powyżej 4 sekund

Docelowo Google oczekuje, że co najmniej 75% wizyt na stronie osiągnie wynik nie wyższy niż 2,5 sekundy. To ważne rozróżnienie - nie chodzi o pojedynczy test, lecz o dane zagregowane z rzeczywistych użytkowników.

Jak mierzyć LCP?

Pomiar LCP można wykonać na dwa sposoby, a każdy z nich dostarcza innych informacji.

Pomiary laboratoryjne

Narzędzia takie jak Google Lighthouse, PageSpeed Insights (w trybie symulacji) czy Chrome DevTools mierzą LCP w kontrolowanych warunkach. Wynik zależy od ustawień testu - prędkości połączenia, mocy procesora symulowanego urządzenia. Dane laboratoryjne są powtarzalne i przydatne do debugowania, ale nie odzwierciedlają doświadczeń rzeczywistych użytkowników.

Dane z rzeczywistych wizyt

To pomiary z prawdziwych wizyt, zbierane przez Chrome User Experience Report (CrUX) i widoczne w PageSpeed Insights w sekcji „Ocena korzystania ze stron w rzeczywistości”. Uwzględniają różnorodność urządzeń, połączeń i lokalizacji odwiedzających. To właśnie te dane Google wykorzystuje w swoich algorytmach rankingowych.

Do monitorowania LCP na bieżąco warto korzystać z Google Search Console (raport Core Web Vitals), który agreguje pomiary rzeczywistych użytkowników i wskazuje konkretne grupy adresów URL z problemami.

Dane z prawdziwych wizyt

Sprawdź Core Web Vitals swojej domeny

Wpisz domenę, a otworzymy jej raport w oficjalnym narzędziu CrUX Vis. Zobaczysz pomiary z rzeczywistych wizyt użytkowników Chrome, a nie wynik symulacji jednego urządzenia i łącza.

Jak czytać raport? CrUX Vis aktualizuje się co tydzień. Każdy punkt obejmuje poprzednie 28 dni, dlatego sąsiednie tygodnie częściowo opisują te same wizyty. Brak wyniku nie oznacza, że strona jest szybka — domena może po prostu nie mieć wystarczającej próbki w CrUX.

Potrzebujesz surowych danych? Publiczny zbiór CrUX w BigQuery pozwala porównywać wiele domen, urządzenia, kraje i historię od 2017 roku. Dane są publikowane co miesiąc dla całej domeny w danym protokole, bez wyników pojedynczych URL-i.

Do zbudowania bezpośredniego linku potrzebny jest JavaScript. Możesz też otworzyć CrUX Vis i wpisać domenę ręcznie.

Najczęstsze przyczyny złego LCP w e-commerce

Sklepy internetowe są szczególnie narażone na problemy z LCP. Oto najczęstsze przyczyny:

Nieskompresowane zdjęcia produktów. Zdjęcia w formacie JPEG o wadze 2–5 MB nadal spotykamy w sklepach. Przy wolniejszym połączeniu mobilnym takie pliki potrafią ładować się przez wiele sekund.

Wolny czas odpowiedzi serwera (TTFB). Jeśli sam serwer potrzebuje 1-2 sekund na wygenerowanie odpowiedzi HTML, to LCP nie może być krótki. Problem ten dotyka szczególnie sklepów na współdzielonym hostingu lub z rozbudowanymi bazami danych.

Render-blocking CSS i JavaScript. Przeglądarka nie wyrenderuje strony, dopóki nie pobierze i nie przetworzy krytycznych plików CSS. Każdy dodatkowy arkusz stylów lub skrypt w <head> opóźnia moment renderowania.

Kaskadowe ładowanie zasobów. Sytuacja, w której przeglądarka musi najpierw pobrać HTML, potem CSS, a dopiero z CSS wynika, że trzeba pobrać obraz tła - każdy taki krok dodaje opóźnienie.

Zewnętrzne fonty bez optymalizacji. Niestandardowe czcionki pobierane z zewnętrznych serwerów mogą blokować renderowanie tekstu, co opóźnia LCP w przypadkach, gdy największym elementem jest blok tekstowy.

Jak poprawić LCP?

Cztery kolejne składowe czasu LCP: TTFB, opóźnienie pobierania, pobieranie zasobu i opóźnienie renderowania — Każdy pomiar LCP można rozłożyć na cztery następujące po sobie odcinki. Skrócenie samego pobierania obrazu nie wystarczy, jeśli przeglądarka późno odkrywa zasób albo długo czeka na jego wyrenderowanie.

Zanim zmienisz hosting albo zaczniesz kompresować wszystkie obrazy, sprawdź wykres żądań (waterfall) w Chrome DevTools lub WebPageTest. Cztery składowe LCP wskazują cztery różne rodzaje problemu:

Składowa	Co oznacza wysoki wynik	Od czego zacząć
TTFB	przeglądarka długo czeka na pierwszy bajt HTML-a	backend, baza danych, cache dokumentu, CDN
opóźnienie rozpoczęcia pobierania	przeglądarka zbyt późno odkrywa zasób LCP	HTML, `src`/`srcset`, `fetchpriority`, ewentualnie preload
czas pobierania zasobu	obraz lub font jest ciężki albo wolno dostarczany	format, rozmiar, kompresja, CDN
opóźnienie renderowania	zasób jest gotowy, ale strona nadal go nie pokazuje	CSS, JavaScript, fonty i pracę głównego wątku

Nie wiesz, która część ładowania psuje LCP?

Sprawdzimy dane CrUX, wykres żądań i kod kluczowych szablonów, a potem oddzielimy problemy serwera, obrazów i renderowania.

Porozmawiajmy o audycie wydajności

Optymalizacja obrazów

Konwersja zdjęć do WebP lub AVIF często zmniejsza wagę pliku o 25–50% względem JPEG przy porównywalnej jakości. Rzeczywisty wynik zależy od rodzaju obrazu i ustawień kodera, dlatego porównujemy jakość oraz wagę gotowych wariantów, zamiast konwertować bibliotekę w ciemno. Atrybut srcset pozwala serwować różne rozmiary obrazu zależnie od urządzenia — nie ma sensu wysyłać zdjęcia 2000 px na telefon z ekranem 400 px.

Nadaj właściwy priorytet zasobowi LCP

Jeśli obraz LCP jest obecny jako <img> w początkowym HTML-u, nie ustawiaj na nim loading="lazy". Zadbaj o prawidłowe src i srcset, a najważniejszemu obrazowi nadaj wysoki priorytet:

obraz-lcp.html

 1
 2
 3
 4
 5
 6
 7
 8
 9
10



<img
  src="/images/hero.webp"
  srcset="/images/hero-800.webp 800w, /images/hero-1600.webp 1600w"
  sizes="100vw"
  width="1600"
  height="900"
  fetchpriority="high"
  alt="Nowa kolekcja sklepu"
>

Preload przydaje się wtedy, gdy przeglądarka nie może wcześnie odkryć zasobu, na przykład gdy obraz pochodzi z CSS-u albo jest dodawany przez JavaScript:

preload-obrazu-lcp.html

1
2
3
4
5
6
7
8



<link
  rel="preload"
  as="image"
  href="/images/hero.webp"
  type="image/webp"
  fetchpriority="high"
>

Nie dodawaj fetchpriority="high" i preload do wielu obrazów naraz. Jeśli każdy zasób jest „najważniejszy”, przeglądarka traci użyteczną wskazówkę, a niepotrzebne pobrania mogą konkurować o łącze z prawdziwym elementem LCP. Efekt zawsze potwierdź na wykresie żądań.

Szybszy serwer i CDN

Oficjalna strona web.dev podaje, że 0,8 s to dobry wynik, ale w nowoczesnych wdrożeniach headless i na stronach statycznych obsługiwanych z edge’a/CDN oczekujemy TTFB liczonego raczej w niskich setkach milisekund — wynik powinien być bliski czasowi potrzebnemu na samo połączenie i przesłanie odpowiedzi. Renderowanie po stronie serwera również powinno mieć ustalony budżet czasu, cache i przewidywalną ścieżkę awaryjną. Regularne wyniki zbliżone do 0,8 s są dla nas sygnałem do sprawdzenia architektury, nawet jeżeli mieszczą się jeszcze w ogólnej rekomendacji web.dev.

W WooCommerce, PrestaShopie lub innym rozbudowanym systemie generującym HTML dynamicznie, zejście poniżej tej wartości może wymagać większej pracy, ale nie należy traktować ograniczeń starszej platformy jako wzorca dla nowoczesnego sklepu. Sprawdź czas generowania dokumentu, zapytania do bazy, cache HTML-a i drogę przez CDN. Pamiętaj też, że szybki shell lub skeleton nie rozwiązuje problemu, jeżeli właściwa treść i obraz LCP pojawiają się dopiero po hydracji albo kolejnym żądaniu do API.

Eliminacja zasobów blokujących renderowanie

Krytyczny CSS (potrzebny do wyrenderowania widocznej części strony) powinien być osadzony inline w <head>. Reszta stylów może być ładowana asynchronicznie. Skrypty JavaScript, które nie są potrzebne do renderowania, powinny mieć atrybut defer lub async.

Optymalizacja fontów

Użycie font-display: swap w regułach @font-face pozwala przeglądarce wyrenderować tekst systemową czcionką, zanim pobierze niestandardowy font. Dzięki temu tekst pojawia się natychmiast, a font podmienia się po załadowaniu.

FAQ

Czy LCP wpływa na pozycje w Google?

Tak. LCP jest jedną z trzech metryk Core Web Vitals, które Google oficjalnie włączył do czynników rankingowych. Nie jest to czynnik dominujący - treść i linki nadal mają większe znaczenie - ale przy porównywalnej jakości merytorycznej dwóch stron, lepsza wydajność może przechylić szalę.

Czy LCP mierzy się osobno dla mobile i desktop?

Tak. Pomiary rzeczywistych użytkowników i próg 75. percentyla analizuje się osobno dla urządzeń mobilnych i komputerów. Wyniki mobilne często są gorsze z powodu wolniejszych połączeń i słabszych urządzeń, dlatego w e-commerce zwykle wymagają szczególnej uwagi. Nie należy jednak mylić tego z mobile-first indexing: ten mechanizm dotyczy wersji treści używanej przez Google do indeksowania, a nie zasady, według której tylko mobilny wynik LCP ma znaczenie.

Jaki jest najszybszy sposób na poprawę LCP?

Najpierw rozłóż LCP na cztery składowe. Jeśli największy udział ma TTFB, zacznij od serwera i cache. Jeśli obraz LCP jest odkrywany późno albo długo się pobiera, wtedy największy efekt może dać poprawne srcset, brak lazy loadingu, fetchpriority=high, kompresja lub — dla zasobu odkrywanego dopiero z CSS-u albo JavaScriptu — preload. W naszych projektach, gdy właśnie obraz był głównym problemem, taki pakiet zmian skracał LCP nawet o 1–3 sekundy; nie będzie jednak lekarstwem na wolny backend albo długie wykonywanie JavaScriptu.

Czy lazy loading pomaga w poprawie LCP?

Nie dla elementu LCP — wręcz przeciwnie. Lazy loading obrazów poza viewportem jest korzystny, ale zastosowany do obrazu hero opóźnia jego pobranie. Obraz LCP powinien być wykrywalny w początkowym HTML-u, ładować się bez lazy loadingu i może otrzymać fetchpriority=high. Preload dodawaj przede wszystkim wtedy, gdy zasobu nie da się wcześnie odkryć z HTML-a.

LCP (Largest Contentful Paint) - co to jest i jak poprawić czas ładowania?