Największe malowanie treści (LCP)

TL;DR — Largest Contentful Paint (LCP) mierzy, ile czasu zajmuje pojawienie się największego elementu na ekranie — zwykle obrazu hero lub dużego bloku tekstu — po kliknięciu na Twoją stronę. Wynik poniżej 2,5 sekundy jest dobry. To jeden z trzech podstawowych wskaźników internetowych Google (Core Web Vitals) i to ten, z którym większość stron ma największe problemy.

Czym jest LCP

Pierwsze wrażenie, jakie ludzie mają o Twojej stronie, to to, jak szybko wydaje się ładować. LCP próbuje to ująć w liczbach. Mierzy czas potrzebny do załadowania pojedynczego największego widocznego elementu w obszarze widoku — części strony, którą widzisz bez przewijania.

Ten „największy element” to zwykle jedna z dwóch rzeczy:

• Duży obraz — baner hero, zdjęcie produktu, wyróżniony obraz.
• Duży blok tekstu — często spotykany na stronach artykułów, które nie zaczynają się od obrazu.

LCP to moment, w którym ten element kończy renderowanie, mierzony od momentu pierwszego rozpoczęcia ładowania strony. Im niższa liczba, tym szybciej Twoja strona się wydaje.

Wynik

Google dzieli LCP na trzy kategorie:

• Dobry: 2,5 sekundy lub mniej
• Wymaga poprawy: od 2,5 do 4 sekund
• Słaby: więcej niż 4 sekundy

Celujesz w ten wynik 2,5 sekundy. I jest oceniany na podstawie prawdziwych odwiedzających Twoją stronę, a nie testu, który przeprowadzasz raz — więc to doświadczenie, jakie otrzymują Twoi rzeczywiści odbiorcy na swoich prawdziwych telefonach i połączeniach.

Dlaczego to może być trudne

LCP to wskaźnik Core Web Vitals, z którym ludzie mają najwięcej problemów. To dlatego, że ma najwięcej ruchomych części: Twój serwer musi odpowiedzieć, przeglądarka musi znaleźć i pobrać obraz, a potem musi go faktycznie wyrenderować. Spowolnienie na którymkolwiek z tych etapów podnosi całą liczbę. Kompresowanie obrazów to częsty pierwszy pomysł — i czasami pomaga — ale często nie jest to prawdziwy wąski gardło.

Jest też trudniejszy na urządzeniach mobilnych niż na komputerach, ponieważ telefony mają wolniejsze połączenia i mniejszą moc obliczeniową.

Co zrobić najpierw

Trzy szybkie wygrane, które naprawiają najczęstsze błędy:

1. Nie stosuj leniwego ładowania głównego obrazu. „Leniwe ładowanie” mówi przeglądarce, aby czekała przed pobraniem obrazu. To świetne dla elementów daleko na dole strony — ale jeśli zrobisz to z obrazem hero, celowo opóźniasz najważniejszą rzecz na ekranie. Dowód potwierdzający to twierdzenie An LCP image should not be lazy-loaded, and reducing resource load delay is a primary LCP optimization. Zakres: web.dev guidance for image-based LCP elements. Poziom ufności: wysoki · Zweryfikowano: 2026-07-14 web.dev: Optimize LCP
2. Powiedz przeglądarce, że główny obraz jest ważny — istnieje atrybut (fetchpriority="high"), który robi dokładnie to. Umieść go na tym jednym obrazie, który faktycznie jest kandydatem do LCP; umieszczanie go na kilku obrazach osłabia sygnał.
3. Przyspiesz swój serwer. Jeśli serwer wolno odpowiada, nic innego, co robisz, nie ma większego znaczenia.

Chcesz pełny model mentalny — cztery podczęści LCP, jak znaleźć swój element LCP, kwestie renderowania i czcionek oraz jak bardzo to faktycznie wpływa na pozycje w wynikach wyszukiwania? Przełącz się na zakładkę Zaawansowane.

TL;DR — LCP to czas renderowania największego obrazu lub bloku tekstu widocznego w obszarze widoku, względem momentu rozpoczęcia ładowania strony. Dobry wynik to ≤ 2,5 s przy 75. percentylu prawdziwych użytkowników (podzielonych według urządzeń); 2,5–4 s wymaga pracy, powyżej 4 s jest słabe. To jeden z trzech wskaźników Core Web Vitals i dzieli się na cztery podczęści — TTFB, opóźnienie ładowania zasobu, czas trwania ładowania zasobu, opóźnienie renderowania elementu — gdzie TTFB i czas trwania ładowania zwykle dominują (wytyczne, nie stałe udziały — diagnozuj własną stronę). Najlepsze poprawki: nigdy nie stosuj leniwego ładowania obrazu LCP, dodaj fetchpriority="high" na faktycznym kandydacie, wstępnie ładuj go, gdy nie ma go w HTML, usuń blokujące renderowanie CSS/JS i napraw TTFB. To metryka polowa — narzędzia laboratoryjne tylko ją przybliżają — a element LCP może się zmieniać podczas ładowania. Google potwierdza, że Core Web Vitals wpływają na systemy rankingowe, ale nie publikuje dokładnej wagi LCP ani nie nazywa go tie-breakerem; trafność treści nadal dominuje.

Co dokładnie mierzy LCP

LCP raportuje czas renderowania największego obrazu lub bloku tekstu widocznego w viewport, mierzony względem momentu, w którym użytkownik po raz pierwszy przeszedł na stronę. Ujęcie Google: to najbliższy standaryzowany odpowiednik tego, kiedy główna treść pojawia się użytkownikowi. Zastąpiło wcześniejsze, bardziej rozmyte metryki, takie jak First Meaningful Paint i Speed Index.

Kilka rzeczy, które od razu sprawiają problemy:

• To nie jest „czas ładowania strony”. Strona może mieć pobrane wszystkie zasoby i nadal mieć wolny LCP, jeśli renderowanie największego elementu było zablokowane. LCP dotyczy tego jednego elementu, a nie całej strony.
• To nie to samo co FCP. First Contentful Paint jest wyzwalany, gdy pojawi się jakakolwiek treść; LCP czeka na największy element. Strona może mieć szybki FCP (pasek nawigacji się renderuje) i wolny LCP (obraz hero ładuje się późno).
• To dynamiczna metryka. Przeglądarka wysyła nowego kandydata LCP za każdym razem, gdy większy element staje się widoczny. Ostatni wpis przed interakcją użytkownika (dotknięcie, przewinięcie, naciśnięcie klawisza) lub zamknięciem strony to wartość, która się liczy — interakcja często zmienia to, co jest widoczne, więc raportowanie kończy się w tym miejscu. Kandydat, który później zostanie usunięty z DOM, nie kasuje swojego wpisu — pozostaje raportowanym elementem, chyba że jeszcze większy element wyrenderuje się przed zakończeniem raportowania.

Progi — i dlaczego 2,5 sekundy

Oceniane na 75. percentylu rzeczywistych ładowań stron przez użytkowników, podzielone według typu urządzenia. Więc trzy z czterech wizyt muszą zmieścić się poniżej 2,5 s, aby dany origin przeszedł test.

Dlaczego akurat 2,5? Metodologia progów Google opierała się na dwóch rzeczach: badaniach percepcji ludzkiej wskazujących na około 1–3 sekundy jako zakres, który wydaje się „natychmiastowy”, oraz danych o osiągalności w CrUX pokazujących, że 2,5 s było konsekwentnie osiągalne dla dobrze zoptymalizowanych witryn, bez bycia trywialnie łatwym. Bardziej rygorystyczne cele, takie jak 1,5 s czy 2,0 s, nie były konsekwentnie osiągalne w wystarczającej liczbie originów, więc nie przeszły.

Co liczy się jako element LCP

Typy elementów brane pod uwagę przy LCP:

• elementy <img>
• elementy <image> wewnątrz <svg>
• elementy <video> (czas ładowania obrazu plakatu lub pierwsza klatka, w zależności od tego, co nastąpi wcześniej)
• element z obrazem tła ładowanym przez funkcję CSS url()
• elementy blokowe zawierające węzły tekstowe lub inne tekstowe elementy podrzędne

Raportowany rozmiar to to, co faktycznie jest widoczne w viewport — części przycięte lub przewinięte poza ekran nie są liczone, a w przypadku obrazów jest to widoczny rozmiar lub rozmiar wewnętrzny, w zależności od tego, który jest mniejszy. Marginesy, padding i obramowania są ignorowane. Kilka elementów jest wykluczanych przez heurystyki: wszystko z opacity: 0, elementy pokrywające cały viewport (traktowane jako tła) oraz obrazy zastępcze o niskiej entropii.

Około trzech czwartych stron ma obraz jako element LCP — więc praca nad obrazami jest zwykle właściwym pierwszym krokiem. Ale nie zawsze i nie zawsze kompresja (więcej o tym dalej). Pozostała część to tekstowe LCP, gdzie dźwignia jest zupełnie inna: to ładowanie czcionek, a nie waga obrazów.

Cztery podczęści — część, którą większość artykułów pomija

To ramy, od których zacząłbym każdą diagnozę LCP. web.dev dzieli LCP na cztery sekwencyjne podczęści:

1. Time to First Byte (TTFB) — od momentu, gdy użytkownik zaczyna ładować stronę, do momentu, gdy przeglądarka otrzyma pierwszy bajt HTML. Typowy udział: ~40% całkowitego LCP.
2. Opóźnienie ładowania zasobu — luka między TTFB a momentem, gdy przeglądarka zaczyna ładować zasób LCP. To czas odkrywania. Typowy udział: poniżej 10%.
3. Czas ładowania zasobu — ile czasu zajmuje pobranie samego zasobu LCP. Typowy udział: ~40%.
4. Opóźnienie renderowania elementu — od momentu zakończenia ładowania zasobu do momentu, gdy element faktycznie się renderuje. Typowy udział: poniżej 10%.

Zasada stojąca za tabelą: zdecydowana większość czasu LCP powinna być poświęcona na ładowanie dokumentu HTML i zasobu LCP. Każdy odcinek, w którym żaden z nich się nie ładuje, to okazja do poprawy.

web.dev wyraźnie stwierdza, że te wartości procentowe to wytyczne, a nie ścisłe reguły — nie zamieniaj ich na cele w sekundach bezwzględnych i nie zmuszaj każdej strony do dopasowania się do tego podziału. Mają znaczenie tylko względem siebie, a jeśli Twój LCP już teraz mieści się w 2,5 sekundy, proporcje względne nie mają w ogóle znaczenia. Użyj tabeli, aby sprawdzić, która część składowa pochłania nieproporcjonalnie dużo na Twojej stronie, a następnie napraw właśnie tę — a nie dąż do dokładnego podziału 40/10/40/10.

A oto fragment, który obala powszechne założenie: od lutego 2025 roku te cztery części składowe są dostępne w interfejsie API CrUX dla obrazów LCP, a analiza danych z HTTP Archive przeprowadzona przez zespół Chrome wykazała, że czas pobierania obrazu był często najmniejszą częścią czasu LCP. Innymi słowy, „po prostu skompresuj moje obrazy” często naprawia niewłaściwą część. TTFB i opóźnienie wykrycia są często ważniejszymi dźwigniami.

Jak znaleźć swój element LCP

Zanim cokolwiek zoptymalizujesz, dowiedz się, który element jest Twoim LCP i która część składowa jest wąskim gardłem:

• PageSpeed Insights — sekcja Diagnostics wskazuje element LCP, a zakładka danych terenowych pokazuje wynik rzeczywistych użytkowników.
• Chrome DevTools — panel Performance oznacza węzeł LCP na osi czasu.
• Biblioteka JS web-vitals — rejestruj LCP (i element) z własnego monitorowania rzeczywistych użytkowników.

Jak poprawić LCP

Przypisz każdą poprawkę do części, której dotyczy:

Napraw opóźnienie ładowania zasobu (wykrycie). To najważniejsza i najczęściej psuta część.

• Nigdy nie ładuj leniwie swojego obrazu LCP. loading="lazy" na elemencie LCP zawsze dodaje niepotrzebne opóźnienie ładowania. Zarezerwuj leniwe ładowanie dla obrazów poniżej linii zagięcia.
• Dodaj fetchpriority="high" do prawdopodobnego obrazu LCP, aby przeglądarka pobierała go wcześnie z wysokim priorytetem.
• Wstępnie załaduj go za pomocą <link rel="preload">, gdy obraz nie jest wykrywalny w początkowym HTML — na przykład, gdy jest ładowany przez CSS lub JavaScript. Ładowanie obrazu hero przez JS jest antywzorcem właśnie dlatego, że ukrywa URL przed skanerem wstępnego ładowania przeglądarki.
• Hostuj krytyczne zasoby w tej samej domenie, aby przeglądarka nie płaciła dodatkowo za konfigurację połączenia.

Preload i fetchpriority rozwiązują różne problemy, więc nie sięgaj po oba z przyzwyczajenia. Preload ujawnia zasób, który skaner wstępnego ładowania przeglądarki w przeciwnym razie wykryłby późno (na przykład obraz ładowany przez JS lub CSS); fetchpriority zmienia priorytet pobierania zasobu, który przeglądarka już znalazła. Jeśli wykrycie i priorytet są już poprawne — obraz jest zwykłym <img> w początkowym HTML — dodanie któregokolwiek z nich może niewiele zdziałać poza dodatkowymi żądaniami. Sprawdź ślad, zastosuj ten, który odpowiada rzeczywistemu problemowi, i potwierdź, że liczba terenowa się zmieniła.

Napraw opóźnienie renderowania elementu.

• Zmniejsz lub wbuduj blokujący renderowanie CSS; odrocz niekrytyczne style.
• Unikaj synchronicznych skryptów w <head>.
• Preferuj renderowanie po stronie serwera lub generowanie statyczne, aby znaczniki docierały gotowe do malowania, i rozbijaj długie zadania na głównym wątku.

Zmniejsz czas ładowania zasobu.

• Nowoczesne formaty obrazów (WebP, AVIF), rozsądna kompresja i CDN.
• Efektywny Cache-Control. I nie ignoruj rywalizacji o sieć — leniwe ładowanie innych obrazów poniżej linii zagięcia może zwolnić przepustowość, aby obraz LCP dotarł szybciej.

Zmniejsz TTFB.

• Zminimalizuj przekierowania, usuń niepotrzebne unikalne parametry URL i zoptymalizuj czas odpowiedzi serwera. Zauważ, że LCP obejmuje czas rozładowania poprzedniej strony, konfigurację połączenia i czas przekierowania — wszystko to wlicza się do TTFB.

Przypadek szczególny: LCP oparty na tekście. Gdy największym elementem jest tekst, krytyczna ścieżka to ładowanie czcionek, a nie waga obrazu. font-display: optional lub czcionki systemowe eliminują opóźnienie renderowania spowodowane czcionkami; font-display: swap bez wcześniejszego wczytywania pliku czcionki może je wprowadzić.

Laboratorium a pole — to rozróżnienie ma znaczenie

LCP jest zasadniczo metryką polową. Google ocenia ją na prawdziwych użytkownikach za pomocą CrUX, prezentowaną w zakładce pola w PageSpeed Insights oraz w raporcie Core Web Vitals w Search Console. To właśnie te dane polowe zasilają rankingi.

Narzędzia laboratoryjne — Lighthouse, Chrome DevTools, WebPageTest — tylko przybliżają ją w symulowanych warunkach i nie używają nawet tego samego punktowania. Lighthouse stosuje ostrzejsze progi dla komputerów stacjonarnych (dobrze ≤ 1,2 s) niż standard polowy (≤ 2,5 s). Tak więc wynik pozytywny w Lighthouse nie gwarantuje pozytywnego wyniku w CrUX i odwrotnie. Używaj narzędzi laboratoryjnych do debugowania i odtwarzania; ufaj danym polowym w kwestii faktycznej oceny.

Istnieje drugi powód, dla którego liczby laboratoryjne i polowe mogą się różnić, warto go znać, aby dziwny odczyt nie skłonił cię do ścigania widmowego błędu: obecny interfejs API przeglądarki LargestContentfulPaint (nadal szkic roboczy W3C) jest ograniczony do pojedynczego ładowania dokumentu. Sam nie resetuje się przy przywracaniu z pamięci podręcznej wstecz/do przodu (bfcache) ani przy nawigacjach SPA w obrębie tego samego dokumentu, a strony zaczynające poza ekranem — karty w tle, strony wstępnie renderowane — mogą raportować zawyżone wartości, ponieważ czas jest mierzony od załadowania, a nie od momentu, gdy strona faktycznie stała się widoczna. Algorytm raportowania wstrzymuje się również przy kwalifikującym się wejściu użytkownika, więc jeśli użytkownik wejdzie w interakcję przed wyświetleniem głównej treści, LCP tego nie wychwyci. Żadne z tych nie zmienia powyższej tabeli progów; wyjaśnia to, dlaczego liczba z konkretnej sesji może wyglądać na błędną, gdy podstawowa nawigacja nie jest zwykłym pierwszym ładowaniem.

Czy LCP wpływa na rankingi?

Tak, w tym sensie, że Google potwierdza, iż Core Web Vitals zasilają jego systemy rankingowe i zaleca osiąganie dobrych wyników. Ale obecna dokumentacja Search Central nie publikuje dokładnej wagi LCP i nie opisuje jej jako tiebreakera — własne ujęcie Google jest takie, że doświadczenie strony “can contribute to success in Search” (tłumaczenie) „może przyczynić się do sukcesu w wyszukiwarce” w przypadku zapytań, gdzie wiele stron już oferuje porównywalną, istotną treść, a dobry wynik nie gwarantuje wzmocnienia rankingu. Trafność i jakość treści nadal dominują. Optymalizuj LCP, ponieważ strona sprawiająca wrażenie szybszej jest naprawdę lepsza dla użytkowników (i konwersji) — nie dlatego, że mechanizm jest udokumentowany jako tiebreaker rankingów, bo nie jest.

Kilka rzeczywistości z danych: spośród Core Web Vitals, LCP jest tym, który stronom najtrudniej poprawić, i jest zauważalnie trudniejszy na mobile niż na desktopie — wolniejsze procesory i połączenia. Przy 3G i wolniejszych, próg 2,5 s może wydawać się prawie niemożliwy do osiągnięcia.

Gdzie to pasuje

LCP jest jednym z trzech Core Web Vitals, obok Interaction to Next Paint i Cumulative Layout Shift. Jego pierwsza podczęść, Time to First Byte, jest osobną metryką diagnostyczną, a First Contentful Paint znajduje się tuż obok na osi czasu ładowania. Wszystkie te zobaczysz w PageSpeed Insights, Lighthouse i Chrome User Experience Report (CrUX). Każda z nich to osobne szczegółowe omówienie w tym klastrze.

Podsumowanie AI

Skrócona wersja wersji zaawansowanej:

• LCP = czas renderowania największego widocznego obrazu lub bloku tekstu, względem momentu rozpoczęcia ładowania strony. To najbliższy standaryzowany odpowiednik pytania „kiedy pojawia się główna treść”.
• Progi: Dobry ≤ 2,5 s, Wymaga poprawy 2,5–4 s, Słaby > 4 s — na 75. percentylu rzeczywistych użytkowników, z podziałem na urządzenia. To jedna z trzech podstawowych wskaźników internetowych (Core Web Vitals).
• To nie czas ładowania strony ani FCP. FCP = pierwszy piksel dowolnej treści; LCP = największy element. LCP jest też dynamiczny — największy kandydat może się zmienić podczas ładowania; liczy się ostatni przed interakcją użytkownika.
• Elementy LCP: <img>, <image> w <svg>, plakat <video>, CSS background-image: url() lub blokowy element tekstowy. ~3 na 4 strony mają obraz jako LCP; reszta to tekst (gdzie czcionki, a nie waga obrazu, są dźwignią).
• Cztery podczęści: TTFB (~40 %), opóźnienie ładowania zasobu (<10 %), czas ładowania zasobu (~40 %), opóźnienie renderowania elementu (<10 %) — web.dev nazywa to wytycznymi, a nie stałymi udziałami; diagnozuj per strona, zamiast gonić za dokładnym podziałem. Dane CrUX 2025: pobieranie obrazu jest często najmniejszą częścią — więc „po prostu skompresuj obrazy” często naprawia niewłaściwą rzecz.
• Najlepsze poprawki: nigdy nie ładuj leniwie obrazu LCP; dodaj fetchpriority="high" na faktycznym kandydacie; wstępnie go załaduj, gdy nie ma go w HTML (preload i fetchpriority rozwiązują różne problemy — nie sięgaj po oba z przyzwyczajenia); ogranicz blokujący renderowanie CSS/JS; zmniejsz TTFB.
• Pole, nie laboratorium. CrUX/Search Console wpływają na rankingi; Lighthouse tylko przybliża i używa ostrzejszych progów dla komputerów (≤ 1,2 s). Obecny interfejs LargestContentfulPaint API jest ograniczony do ładowania dokumentów i sam nie resetuje się dla przywróceń bfcache ani nawigacji SPA w tym samym dokumencie.
• Rankingi: Google potwierdza, że systemy rankingowe korzystają z CWV, ale nie publikuje dokładnej wagi LCP i nie nazywa go tiebreakerem; trafność treści nadal dominuje. Najtrudniejszy CWV do poprawy i trudniejszy na mobile.

Oficjalna dokumentacja

Podstawowe wytyczne od zespołów Chrome i Search w Google.

web.dev (zespół Chrome)

• Largest Contentful Paint (LCP) — kanoniczna definicja: co liczy się jako element LCP, jak obliczany jest rozmiar, kiedy kończy się raportowanie i interfejsy pomiarowe.
• Optimize Largest Contentful Paint — ramy czterech podczęści i pełny podręcznik optymalizacji.
• Core Web Vitals — gdzie LCP plasuje się wśród trzech podstawowych wskaźników internetowych.
• Jak zdefiniowano progi metryk Core Web Vitals — badania i dane o osiągalności stojące za progiem 2,5 s.

Chrome for Developers

• Podczęści obrazu LCP i RTT są już dostępne w CrUX — wydanie danych terenowych z lutego 2025 dotyczące czterech podczęści (tylko obrazy LCP).
• Largest Contentful Paint | Lighthouse — metryka laboratoryjna i jej punktacja zależna od urządzenia.

Google Search Central

• Jak rozumieć Core Web Vitals i wyniki wyszukiwania Google — jak Core Web Vitals wpływają na wyniki wyszukiwania.

Cytaty ze źródła

Oficjalne wypowiedzi z dokumentacji i zespołu Google. Każdy link to link bezpośredni, który przeskakuje do cytowanego fragmentu.

web.dev — definicja i zachowanie (Philip Walton & Barry Pollard, Google)

• “LCP reports the render time of the largest image, text block, or video visible in the viewport, measured relative to when the user first navigated to the page.” (tłumaczenie) „LCP raportuje czas renderowania największego obrazu, bloku tekstu lub wideo widocznego w viewporcie, mierzony względem momentu, w którym użytkownik po raz pierwszy przeszedł na stronę.” Przejdź do cytatu
• Jeśli chodzi o to, co jest mierzone: “LCP doesn’t consider margins, paddings, or borders applied using CSS.” (tłumaczenie) „LCP nie uwzględnia marginesów, dopełnień ani obramowań zastosowanych za pomocą CSS.” Przejdź do cytatu
• Jeśli chodzi o moment zakończenia raportowania: “The browser will stop reporting new entries as soon as the user interacts with the page (via a tap, scroll, or keypress), as user interaction often changes what’s visible to the user.” (tłumaczenie) „Przeglądarka przestanie raportować nowe wpisy, gdy tylko użytkownik wejdzie w interakcję ze stroną (poprzez dotknięcie, przewinięcie lub naciśnięcie klawisza), ponieważ interakcja użytkownika często zmienia to, co jest dla niego widoczne.” Przejdź do cytatu
• Jeśli chodzi o to, co jest uwzględnione w pomiarze czasu: “It is important to note that LCP includes any unload time from the previous page, connection set up time, redirect time, and other Time To First Byte (TTFB) delays.” (tłumaczenie) „Należy zauważyć, że LCP obejmuje czas wyładowania poprzedniej strony, czas nawiązywania połączenia, czas przekierowań oraz inne opóźnienia Time To First Byte (TTFB).” Przejdź do cytatu

web.dev — optymalizacja (Philip Walton i Barry Pollard, Google)

• Najważniejsza zasada leniwego ładowania: “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay.” (tłumaczenie) „Nigdy nie stosuj leniwego ładowania dla obrazu LCP, ponieważ zawsze prowadzi to do niepotrzebnego opóźnienia ładowania zasobów.” Przejdź do cytatu
• Zasada stojąca za celami podczęści: “The vast majority of the LCP time should be spent loading the HTML document and LCP source.” (tłumaczenie) „Zdecydowana większość czasu LCP powinna być poświęcona na ładowanie dokumentu HTML i źródła LCP.” Przejdź do cytatu

Google Search Central — rankingi

• “We highly recommend site owners achieve good Core Web Vitals for success with Search and to ensure a great user experience generally.” (tłumaczenie) „Zdecydowanie zalecamy właścicielom witryn osiągnięcie dobrych wyników Core Web Vitals, aby odnieść sukces w wyszukiwarce i zapewnić ogólnie świetne doświadczenia użytkowników.” (Przekazane z dokumentu Search Central Core Web Vitals; przed potraktowaniem jako ostateczne zweryfikuj na żywej stronie.)

Lista kontrolna naprawy LCP

Przejdź przez nią mniej więcej od góry do dołu — najpierw wykrywanie i TTFB, ponieważ zwykle są to największe i najczęściej zepsute dźwignie.

• Znaleziono rzeczywisty element LCP (Diagnostyka PageSpeed Insights, panel Performance w DevTools lub biblioteka web-vitals) — nie optymalizuj na ślepo.
• Sprawdzono cztery podczęści, aby zobaczyć, która jest wąskim gardłem, zanim cokolwiek zmienisz.
• Obraz LCP nie ma loading="lazy" (ładowanie leniwe należy tylko do treści poniżej linii widoczności).
• Obraz LCP ma fetchpriority="high".
• Obraz LCP jest wykrywalny w początkowym HTML — lub wstępnie wczytany (<link rel="preload">), jeśli jest ładowany przez CSS/JS.
• Obraz hero nie jest ładowany przez JavaScript (ukrywa go to przed skanerem wstępnego ładowania).
• CSS blokujący renderowanie jest zminimalizowany/wbudowany; style niekrytyczne są odroczone.
• Brak synchronicznych skryptów w <head>; długie zadania są podzielone.
• Nowoczesny format obrazu (WebP/AVIF), rozsądna kompresja, serwowany przez CDN z dobrym Cache-Control.
• Obrazy poniżej linii widoczności są ładowane leniwie, aby nie konkurowały o przepustowość z obrazem LCP.
• TTFB rozwiązany: zminimalizowane przekierowania, zoptymalizowana odpowiedź serwera, odrzucone zbędne parametry URL.
• Tekstowy LCP? Użyj font-display: optional lub czcionek systemowych i wstępnie wczytaj dowolny zamieniany plik czcionki.
• Zweryfikowano na podstawie danych terenowych (CrUX / Search Console), a nie tylko laboratoryjnego uruchomienia Lighthouse.

Ściąga LCP

Progi (75. percentyl prawdziwych użytkowników, według urządzenia)

Cztery podczęści — co każda oznacza i jak ją naprawić

Co może być elementem LCP

• <img> · <image> wewnątrz <svg> · plakat <video> · CSS background-image: url() · tekst blokowy

Wykluczone przez heurystykę: opacity: 0, elementy „tła” na całym widoku, placeholdery o niskiej entropii.

Szybkie fakty

• LCP to metryka terenowa (CrUX / Search Console wpływają na rankingi); Lighthouse tylko przybliża i używa ostrzejszego dobrego wyniku dla komputerów ≤ 1,2 s.
• Element LCP może się zmieniać podczas ładowania; liczy się ostatni kandydat przed interakcją użytkownika.
• ~3 na 4 strony mają obraz jako LCP; reszta to tekst (czcionki są dźwignią).
• Czas pobierania obrazu jest często najmniejszą podczęścią — kompresja nie zawsze jest rozwiązaniem.
• LCP ≠ FCP; LCP ≠ całkowity czas ładowania strony.

Narzędzia do pomiaru i naprawy LCP

Dane terenowe (te, które wpływają na rankingi)

• PageSpeed Insights — zakładka terenowa pokazuje Twoje dane CrUX od prawdziwych użytkowników; Diagnostyka wskazuje element LCP.
• Search Console — raport Core Web Vitals — status LCP dla Twoich adresów URL, pogrupowany, na danych od prawdziwych użytkowników.
• Chrome User Experience Report (CrUX) — bazowy zbiór danych terenowych; od lutego 2025 obejmuje cztery podczęści LCP dla obrazów przez API.
• Biblioteka JS web-vitals — loguj LCP i element LCP z własnego monitorowania prawdziwych użytkowników.

Dane laboratoryjne (do debugowania)

• Lighthouse — szybkie laboratoryjne LCP i lista możliwości (pamiętaj: ostrzejsze progi dla komputerów niż w danych terenowych).
• Chrome DevTools — panel Performance — oznacza węzeł LCP i pełną oś czasu renderowania.
• WebPageTest — widok kaskadowy do ustalenia, która podczęść jest wolna.

Crawler SEO

• Ahrefs Site Audit — wykrywa problemy z Core Web Vitals / wydajnością w całej witrynie na dużą skalę.

Jak same narzędzia są oceniane

Przykład na żywo metryki opisanej na tej stronie — dobrze znane usługi szybkości stron i monitorowania uszeregowane według własnego mobilnego LCP od prawdziwych użytkowników (dane terenowe Chrome UX Report):

Poprawki LCP, które celują w zły problem

Leniwe ładowanie obrazu hero

loading="lazy" opóźnia wykrycie obrazu nad linią zagięcia, który prawdopodobnie stanie się LCP. Załaduj go z wyprzedzeniem, nadaj prawdopodobnemu kandydatowi fetchpriority="high" i zarezerwuj leniwe ładowanie dla obrazów poniżej linii zagięcia.

Kompresowanie każdego obrazu przed znalezieniem wąskiego gardła

Czas pobierania obrazu to tylko jedna z czterech części składowych LCP i może być najmniejsza. Zidentyfikuj element LCP i sprawdź TTFB, opóźnienie ładowania, czas ładowania i opóźnienie renderowania przed wyborem rozwiązania.

Ładowanie obrazu hero przez JavaScript

Obraz wstrzykiwany przez JS ukrywa swój URL przed skanerem wstępnego ładowania przeglądarki i tworzy opóźnienie ładowania zasobu. Umieść obraz w początkowym HTML lub wstępnie go załaduj, gdy CSS lub JS musi go obsługiwać.

Ogłaszanie zwycięstwa na podstawie jednego uruchomienia Lighthouse

Lighthouse to kontrolowana diagnostyka, podczas gdy werdykt Google CWV pochodzi z danych terenowych CrUX. Użyj testów laboratoryjnych, aby zweryfikować mechanizm, i poczekaj na dane od prawdziwych użytkowników, aby sprawdzić, czy wynik p75 się poprawił.

Zasób LCP zaczyna się późno

Objaw: długa przerwa pojawia się między TTFB a żądaniem zasobu LCP. Prawdopodobna przyczyna: leniwe ładowanie, wykrywanie przez JS, obraz tła CSS lub niski priorytet pobierania. Rozwiązanie: spraw, aby zasób był wykrywalny w początkowym HTML, usuń leniwe ładowanie, zastosuj fetchpriority="high" lub wstępnie go załaduj. Potwierdź, że żądanie przesuwa się wcześniej w śladzie.

Zasób się ładuje, ale LCP nadal odpala późno

Objaw: czas ładowania kończy się znacznie przed zdarzeniem LCP. Prawdopodobna przyczyna: CSS blokujące renderowanie, synchroniczny JavaScript, długie zadanie lub renderowanie czcionek dla tekstowego LCP. Rozwiązanie: zmniejsz pracę blokującą i przetestuj strategię czcionek dla tekstu; potwierdź, że opóźnienie renderowania elementu się zmniejsza.

LCP w laboratorium jest dobre, ale LCP w terenie jest słabe

Objaw: Lighthouse przechodzi, podczas gdy CrUX lub Search Console nie. Prawdopodobna przyczyna: prawdziwi użytkownicy mają różne urządzenia, sieci, stany pamięci podręcznej, lokalizacje geograficzne lub elementy LCP. Rozwiązanie: segmentuj dane terenowe, przechwytuj szczegóły elementów/części RUM i odtwórz wolny segment, zamiast dostrajać tylko domyślny profil laboratoryjny.

Zgłaszany element LCP zmienia się między uruchomieniami

Objaw: DevTools identyfikuje różne obrazy lub bloki tekstu. Prawdopodobna przyczyna: responsywne punkty przerwania, personalizacja, późne zmiany DOM lub konkurujący kandydaci. Rozwiązanie: przetestuj reprezentatywne widoki i stany, a następnie zoptymalizuj każdego powtarzającego się kandydata, zamiast zakładać, że jeden obraz hero na desktopie obejmuje wszystkich użytkowników.

Wykrywanie obrazu hero: opóźnione vs wczesne

Uproszczona opóźniona implementacja ukrywa obraz za JavaScriptem:

<div id="hero"></div>
<script>
  document.querySelector('#hero').innerHTML = '<img src="hero.webp" alt="">';
</script>

Przeglądarka może wykryć i nadać priorytet tej wersji podczas parsowania HTML:

<img src="hero.webp" alt="" fetchpriority="high" width="1200" height="675">

Obraz tła CSS: nieujawniony vs wstępnie załadowany

Gdy obraz LCP musi pozostać tłem CSS, ujawnij go przed zakończeniem arkusza stylów:

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

Wstępne ładowanie pomaga tylko wtedy, gdy jego URL i atrybuty żądania pasują do rzeczywistego zasobu.

Lista ostatnich kandydatów LCP w Chrome DevTools

Wklej to do konsoli Chrome DevTools, przeładuj stronę i obserwuj każdego kandydata, którego zgłasza przeglądarka. Ostatni kandydat przed interakcją jest istotny.

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.table({
      lcp: Math.round(entry.startTime),
      element: entry.element?.tagName,
      url: entry.url || '',
      size: entry.size,
    });
  }
}).observe({ type: 'largest-contentful-paint', buffered: true });

Znajdź prawdopodobne leniwie ładowane obrazy nad linią zagięcia

Uruchom to w konsoli DevTools. Wyświetla leniwe obrazy, których górna krawędź zaczyna się w bieżącym widoku; zweryfikuj prawdziwego kandydata LCP przed usunięciem atrybutu.

[...document.querySelectorAll('img[loading="lazy"]')]
  .filter((img) => img.getBoundingClientRect().top < innerHeight)
  .map((img) => ({ src: img.currentSrc || img.src, top: img.getBoundingClientRect().top }));

Wyodrębnij atrybuty priorytetu obrazu w crawlerze

Użyj tego XPath w niestandardowej ekstrakcji Screaming Frog, aby zwrócić obrazy oznaczone jako wysoki priorytet:

//img[@fetchpriority='high']/@src

Udowodnij, że poprawka LCP została wdrożona

Test kolejności wykrywania

Test do wykonania: nagraj ślad wydajności DevTools po zmianie obrazu hero. Oczekiwany wynik: żądanie LCP zaczyna się wcześniej i nie jest leniwie ładowane. Interpretacja porażki: zasób pozostaje ukryty, ma obniżony priorytet lub jest zablokowany za inną zależnością. Okno monitorowania: natychmiastowy wynik laboratoryjny. Wyzwalacz wycofania: zmiana opóźnia inny krytyczny zasób lub sprawia, że LCP w laboratorium jest konsekwentnie gorsze.

Test opóźnienia renderowania

Test do wykonania: porównaj czas ukończenia zasobu LCP i zdarzenie LCP w równoważnych śladach przed/po. Oczekiwany wynik: opóźnienie renderowania elementu maleje bez nowego układu lub regresji wizualnej. Interpretacja niepowodzenia: CSS, JavaScript lub czcionki nadal blokują malowanie. Okno monitorowania: natychmiastowe na reprezentatywnych widokach. Wyzwalacz wycofania: zepsute renderowanie, brakujące style lub gorsze powtarzające się LCP.

Test wyniku w terenie

Test do wykonania: monitoruj LCP p75 na poziomie URL w CrUX lub RUM pierwszej strony po wdrożeniu. Oczekiwany wynik: p75 przesuwa się w kierunku progu Dobry lub pozostaje w nim bez regresji INP lub CLS. Interpretacja niepowodzenia: przypadek laboratoryjny nie był reprezentatywny lub inny podkomponent dominuje w rzeczywistych wizytach. Okno monitorowania: RUM może prowadzić; CrUX potrzebuje swojego 28-dniowego okna kroczącego, aby się odwrócić. Wyzwalacz wycofania: stała regresja w terenie powiązana z wydaniem.

Metryki LCP, które warto śledzić

LCP p75 w terenie

Metryka: LCP na 75. percentylu według typu urządzenia. Co ci mówi: czy prawdziwi użytkownicy spełniają próg ładowania Core Web Vitals. Jak to pobrać: CrUX, Search Console lub RUM pierwszej strony. Punkt odniesienia / realistyczny zakres: Dobry to co najwyżej 2,5 sekundy; segmentuj urządzenia mobilne i stacjonarne. Częstotliwość: co tydzień, z zapisanym kroczącym oknem CrUX.

Rozkład podkomponentów LCP

Metryka: TTFB, opóźnienie ładowania zasobu, czas ładowania i opóźnienie renderowania elementu dla LCP. Co ci mówi: który etap odpowiada za oczekiwanie. Jak to pobrać: reprezentatywne ślady laboratoryjne i podkomponenty obrazu LCP z CrUX/RUM, jeśli dostępne. Punkt odniesienia / realistyczny zakres: użyj przybliżonego podziału diagnostycznego 40/10/40/10 z artykułu jako wskazówki, a nie uniwersalnej obietnicy wydajności. Częstotliwość: po wydaniach szablonów i co miesiąc dla szablonów priorytetowych.

Pokrycie URL z dobrym LCP

Metryka: ważne grupy URL z dobrym LCP w terenie. Co ci mówi: czy poprawa jest szeroka, czy ograniczona do przykładowej strony. Jak to pobrać: grupy CWV w Search Console plus CrUX na poziomie URL dla stron priorytetowych. Punkt odniesienia / realistyczny zakres: ustal punkt wyjściowy według szablonu; URL o niskim ruchu mogą nie mieć indywidualnych danych terenowych. Częstotliwość: co tydzień.

Sprawdź się: Largest Contentful Paint

Pięć szybkich pytań o pomiar i diagnozowanie LCP. Wybierz odpowiedź na każde, a następnie sprawdź.

Zasoby warte Twojego czasu

Moje powiązane teksty

• Czym jest Largest Contentful Paint (LCP) i jak go poprawić — mój pełny przewodnik po LCP na blogu Ahrefs.
• Czym są Core Web Vitals i jak je poprawić — jak LCP współgra z INP i CLS oraz dlaczego jest najtrudniejsze do naprawienia.
• The Beginner’s Guide to Technical SEO — gdzie wydajność strony wpisuje się w szerszy obraz.

Oficjalne (Google / Chrome)

• Largest Contentful Paint (LCP) i Optimize LCP — kanoniczna para.
• How CWV thresholds were defined — powód stojący za 2,5 s.

Od innych

• Napraw Largest Contentful Paint swojej strony, optymalizując ładowanie obrazów — podejście MDN skoncentrowane na programistach, mocne w kwestii rywalizacji o pasmo i antywzorca z obrazami JS.
• Performance — 2025 Web Almanac — coroczne szczegółowe analizy HTTP Archive; źródło statystyk adopcji fetchpriority, użycia preload, podziału LCP na obrazy i tekst oraz wskaźników zdawalności według urządzeń.
• Largest Contentful Paint (LCP) — dokumentacja DebugBear obejmuje analizę wodospadu do wskazywania podczęści, uwagi dotyczące progresywnych JPEG oraz przypadki brzegowe z iframe i miękką nawigacją.
• Largest Contentful Paint (LCP): Co to jest, jak mierzyć i optymalizować — corewebvitals.io; rzeczywiste benchmarki RUM, studia przypadków wpływu na biznes (Vodafone Italy) oraz wynik fetchpriority od Google Flights.
• Largest Contentful Paint | MDN Web Docs — referencja MDN dla API LargestContentfulPaint, typy elementów i zgodność przeglądarek.

Statystyki, które warto cytować

• LCP to najtrudniejsza do osiągnięcia metryka Core Web Vitals. Ma najwięcej komponentów, dlatego strony mają z nią większe problemy niż z INP czy CLS. Źródło
• Mobile jest trudniejsze niż desktop. Wolniejsze procesory i połączenia podnoszą LCP, a przy 3G/wolnych połączeniach próg 2,5 s jest prawie niemożliwy do osiągnięcia. Źródło
• Czas pobierania obrazu to często najmniejsza część LCP. Analiza danych HTTP Archive przeprowadzona przez Chrome wykazała, że czas pobierania często nie jest wąskim gardłem — zwykle są nimi TTFB i opóźnienie wykrycia. Źródło
• Zasięg CrUX jest cienki. W naszym badaniu 42 milionów stron tylko ~11,4 % miało powiązane dane terenowe CrUX — większość stron nie otrzymuje wystarczającego ruchu od prawdziwych użytkowników, aby być mierzona. Źródło
• 62 % stron mobilnych vs 74 % stron desktopowych osiąga dobre LCP (Web Almanac 2025). Różnica na mobile odzwierciedla wolniejsze procesory i połączenia sieciowe. Źródło
• Tylko 2,1 % stron mobilnych preloaduje swój obraz LCP, mimo że 76 % ma obraz jako element LCP — to znacząca niewykorzystana okazja optymalizacyjna (Web Almanac 2025). Źródło
• Adopcja fetchpriority="high" wzrosła z 0,03 % stron mobilnych w 2022 do 17,3 % w 2025, głównie dzięki dodaniu go przez rdzeń WordPressa (Web Almanac 2025). Google Flights zyskało 700 ms poprawy LCP dzięki temu pojedynczemu atrybutowi. Źródło

Filmy

• Google Search Central (YouTube) — wyjaśnienia dotyczące Core Web Vitals i doświadczenia strony, w tym prezentacje zespołu Chrome dotyczące optymalizacji LCP. Kanał

Dziennik zmian