Szczegółowy przewodnik, który pomoże Ci podzielić LCP na części i określić kluczowe obszary wymagające poprawy.
Data publikacji: 30 kwietnia 2020 r., ostatnia aktualizacja: 31 marca 2025 r.
Największe wyrenderowanie treści (LCP) to jeden z 3 Core Web Vitals, który określa, jak szybko wczytuje się główna treść strony internetowej. W szczególności LCP mierzy czas od momentu, w którym użytkownik rozpoczyna wczytywanie strony, do momentu, w którym w widocznym obszarze zostanie wyrenderowany największy obraz lub blok tekstu.
Aby zapewniać użytkownikom dobre wrażenia, witryny powinny dążyć do tego, aby w przypadku co najmniej 75% wizyt LCP wynosiło 2,5 sekundy lub mniej.
Na szybkość wczytywania i renderowania strony internetowej przez przeglądarkę może wpływać wiele czynników, a opóźnienia w którymkolwiek z nich mogą mieć znaczący wpływ na LCP.
Rzadko się zdarza, by poprawa jednego elementu strony spowodowała istotny wzrost wskaźnika LCP. Aby poprawić LCP, musisz wziąć pod uwagę cały proces ładowania i zadbać o zoptymalizowanie każdego etapu.
Interpretowanie danych LCP
Zanim deweloperzy zaczną optymalizować LCP, powinni sprawdzić, czy w ogóle występuje problem z tym wskaźnikiem i jak jest on poważny.
LCP można mierzyć za pomocą różnych narzędzi, ale nie wszystkie mierzą LCP w ten sam sposób. Aby poznać wartość LCP rzeczywistych użytkowników, powinniśmy sprawdzić, jakie są ich wrażenia, a nie to, co pokazują narzędzia laboratoryjne, takie jak Lighthouse, czy testy lokalne. Te narzędzia laboratoryjne mogą dostarczyć wielu informacji, które pomogą Ci zrozumieć i ulepszyć LCP, ale pamiętaj, że same testy laboratoryjne mogą nie w pełni odzwierciedlać wrażenia rzeczywistych użytkowników.
Dane LCP oparte na rzeczywistych użytkownikach można uzyskać z narzędzi do monitorowania rzeczywistych użytkowników (RUM) zainstalowanych w witrynie lub za pomocą Raportu na temat użytkowania Chrome (CrUX), który zbiera anonimowe dane od rzeczywistych użytkowników Chrome w przypadku milionów witryn.
Korzystanie z danych LCP z CrUX w Narzędziach deweloperskich w Chrome
Panel Wydajność w Narzędziach deweloperskich w Chrome pokazuje lokalne dane LCP obok danych LCP strony lub origin z CrUX w widoku danych na żywo oraz w statystykach śladu wydajności, w tym zestawienie czasów podrzędnych części LCP (które wyjaśnimy za chwilę).
Nakładając dane z pól na panel Wydajność, możesz sprawdzić, czy na stronie występują problemy z LCP u prawdziwych użytkowników, i dostosować ustawienia środowiska lokalnego, aby lepiej odtwarzać i debugować te problemy.
Korzystanie z danych LCP z raportu na temat użytkowania Chrome w PageSpeed Insights
PageSpeed Insights udostępnia dane CrUX w górnej sekcji oznaczonej Dowiedz się, jakie są wrażenia użytkowników. Bardziej szczegółowe dane laboratoryjne są dostępne w sekcji u dołu o nazwie Diagnozowanie problemów z wydajnością. Jeśli dla Twojej witryny dostępne są dane CrUX, zawsze w pierwszej kolejności skupiaj się na danych o prawdziwych użytkownikach.
PageSpeed Insights wyświetla maksymalnie 4 rodzaje danych z raportu na temat użytkowania Chrome:
- Dane urządzeń mobilnych dla tego adresu URL
- Dane komputera dla tego adresu URL
- Dane mobilne dla całego źródła
- Dane komputerów z całego źródła
Możesz je włączać i wyłączać za pomocą elementów sterujących u góry i w prawym górnym rogu tej sekcji. Jeśli dany adres URL nie ma wystarczającej ilości danych, aby można było go wyświetlić na poziomie adresu URL, ale ma dane dotyczące źródła, narzędzie PageSpeed Insights zawsze wyświetla dane źródła.
Wartość LCP dla całej domeny może się znacznie różnić od wartości LCP poszczególnych stron w zależności od tego, jak element LCP jest wczytywany na danej stronie w porównaniu z innymi stronami w tej domenie. Może na nią wpływać też sposób, w jaki użytkownicy przechodzą do tych stron. Strony główne są zwykle odwiedzane przez nowych użytkowników, więc często są wczytywane „na zimno”, bez żadnych treści w pamięci podręcznej, i dlatego są często najwolniejszymi stronami w witrynie.
Analiza 4 różnych kategorii danych CrUX może pomóc Ci określić, czy problem z LCP dotyczy tylko tej strony, czy jest to bardziej ogólny problem w całej witrynie. Może też pokazywać, na których typach urządzeń występują problemy z LCP.
Korzystanie z dodatkowych danych CrUX w PageSpeed Insights
Osoby, które chcą zoptymalizować LCP, powinny też korzystać z czasów pierwszego wyrenderowania treści (FCP) i czasu do pierwszego bajtu (TTFB), które są dobrymi wskaźnikami diagnostycznymi i mogą dostarczać cennych informacji o LCP.
TTFB to czas od momentu, gdy użytkownik zaczyna przechodzić do strony (np. klikając link), do momentu otrzymania pierwszych bajtów dokumentu HTML. Wysoki TTFB może utrudnić lub nawet uniemożliwić osiągnięcie wartości LCP wynoszącej 2, 5 sekundy.
Długi czas TTFB może być spowodowany wieloma przekierowaniami serwera, użytkownikami znajdującymi się daleko od najbliższego serwera witryny, użytkownikami korzystającymi z sieci o słabych parametrach lub niemożnością użycia treści z pamięci podręcznej z powodu parametrów zapytania.
Gdy strona zacznie się renderować, może nastąpić pierwsze wyrenderowanie (np. kolor tła), a następnie pojawienie się treści (np. nagłówka witryny). Pojawienie się początkowej treści jest mierzone za pomocą wskaźnika FCP. Różnica między FCP a innymi danymi może być bardzo wymowna.
Duża różnica między TTFB a FCP może wskazywać, że przeglądarka musi pobrać wiele zasobów blokujących renderowanie. Może to też oznaczać, że musi wykonać dużo pracy, aby wyrenderować jakiekolwiek znaczące treści – to klasyczny objaw witryny, która w dużej mierze opiera się na renderowaniu po stronie klienta.
Duża różnica między FCP a LCP oznacza, że zasób LCP nie jest od razu dostępny dla przeglądarki, aby mogła mu nadać priorytet (np. tekst lub obrazy zarządzane przez JavaScript, a nie dostępne w początkowym kodzie HTML), lub że przeglądarka wykonuje inne zadania, zanim będzie mogła wyświetlić treść LCP.
Korzystanie z danych Lighthouse w PageSpeed Insights
Sekcja Lighthouse w PageSpeed Insights zawiera wskazówki dotyczące poprawy LCP, ale najpierw sprawdź, czy podana wartość LCP jest w dużej mierze zgodna z danymi użytkownika dostarczanymi przez raport CrUX. Jeśli Lighthouse i CrUX się nie zgadzają, to prawdopodobnie CrUX daje dokładniejszy obraz wrażeń użytkowników. Zanim podejmiesz jakiekolwiek działania, upewnij się, że dane CrUX dotyczą Twojej strony, a nie całej domeny.
Jeśli zarówno Lighthouse, jak i CrUX wskazują, że wartości LCP wymagają poprawy, sekcja Lighthouse może zawierać cenne wskazówki dotyczące sposobów poprawy LCP. Użyj filtra LCP, aby wyświetlić tylko audyty związane z LCP:
Oprócz możliwości ulepszeń dostępne są też informacje diagnostyczne, które mogą pomóc w zdiagnozowaniu problemu. Diagnostyka elementu największego wyrenderowania treści zawiera przydatny podział różnych czasów, które składają się na LCP:
Typy zasobów LCP i ich części składowe są też dostępne w CrUX.
Omówimy je w dalszej części.
Zestawienie LCP
Optymalizacja LCP może być bardziej skomplikowana, jeśli PageSpeed Insights nie podaje odpowiedzi na pytanie, jak poprawić ten wskaźnik. W przypadku skomplikowanych zadań lepiej jest podzielić je na mniejsze, łatwiejsze części i zająć się nimi oddzielnie.
W tej sekcji znajdziesz metodologię dzielenia LCP na najważniejsze części składowe, a następnie konkretne rekomendacje i sprawdzone metody optymalizacji każdej z nich.
Większość wczytań strony zwykle obejmuje kilka żądań sieciowych, ale aby zidentyfikować możliwości poprawy LCP, zacznij od sprawdzenia tylko 2 z nich:
- Początkowy dokument HTML
- Zasób LCP (jeśli dotyczy)
Chociaż inne żądania na stronie mogą wpływać na LCP, te 2 żądania – a zwłaszcza czas rozpoczęcia i zakończenia wczytywania zasobu LCP – pokazują, czy strona jest zoptymalizowana pod kątem LCP.
Aby zidentyfikować zasób LCP, możesz użyć narzędzi deweloperskich (takich jak omówione wcześniej PageSpeed Insights, Narzędzia deweloperskie w Chrome lub WebPageTest), aby określić element LCP. Możesz tam dopasować adres URL (ponownie, jeśli to możliwe) wczytany przez element na wykresie kaskadowym sieci wszystkich zasobów wczytanych przez stronę.
Na przykład poniższa wizualizacja pokazuje te zasoby wyróżnione na diagramie kaskadowym sieci z typowego wczytywania strony, gdzie element LCP wymaga żądania obrazu do renderowania.
W przypadku dobrze zoptymalizowanej strony żądanie zasobu LCP powinno rozpocząć ładowanie jak najwcześniej, a element LCP powinien być renderowany jak najszybciej po zakończeniu ładowania zasobu LCP. Aby sprawdzić, czy dana strona jest zgodna z tą zasadą, możesz podzielić całkowity czas LCP na te części:
- Czas do pierwszego bajtu (TTFB)
- Czas od zainicjowania wczytywania strony przez użytkownika do momentu, w którym przeglądarka otrzyma pierwszy bajt odpowiedzi w postaci dokumentu HTML.
- Opóźnienie ładowania zasobów
- Czas między TTFB a momentem, w którym przeglądarka zaczyna wczytywać zasób LCP. Jeśli element LCP nie wymaga wczytania zasobu do renderowania (np. jeśli element jest węzłem tekstowym renderowanym za pomocą czcionki systemowej), ten czas wynosi 0.
- Czas wczytywania zasobu
- Czas potrzebny na załadowanie zasobu LCP. Jeśli element LCP nie wymaga wczytania zasobu do renderowania, ten czas wynosi 0.
- Opóźnienie renderowania elementu
- Czas między zakończeniem wczytywania zasobu LCP a pełnym wyrenderowaniem elementu LCP.
Wartość LCP każdej strony można podzielić na te 4 podczęści. Nie ma między nimi żadnych nakładających się ani pustych miejsc. Łącznie dają one pełny czas LCP.
Podczas optymalizacji LCP warto spróbować zoptymalizować poszczególne części. Pamiętaj jednak, że musisz zoptymalizować wszystkie te elementy. W niektórych przypadkach optymalizacja zastosowana w jednej części nie poprawi wskaźnika LCP, tylko przesunie zaoszczędzony czas na inną część.
Jeśli na przykład w poprzednim wodospadzie sieci zmniejszysz rozmiar pliku obrazu, kompresując go bardziej lub przechodząc na bardziej optymalny format (np. AVIF lub WebP), skróci to czas wczytywania zasobu, ale nie poprawi LCP, ponieważ czas po prostu przesunie się na podczęść opóźnienie renderowania elementu:
Dzieje się tak, ponieważ na tej stronie element LCP jest ukryty do momentu zakończenia wczytywania kodu JavaScript, a potem wszystko jest wyświetlane jednocześnie.
Ten przykład ilustruje, że aby uzyskać najlepsze wyniki w zakresie LCP, musisz zoptymalizować wszystkie te podczęści.
Optymalne czasy podzadań
Aby zoptymalizować każdą część LCP, warto wiedzieć, jak wygląda idealne zestawienie tych części na dobrze zoptymalizowanej stronie.
Z 4 podsekcji 2 mają w nazwie słowo „opóźnienie”. To wskazówka, że chcesz, aby te czasy były jak najbliżej zera. Pozostałe 2 części obejmują żądania sieciowe, które z natury wymagają czasu.
Pamiętaj, że te przedziały czasowe są tylko wskazówkami, a nie ścisłymi regułami. Jeśli czasy LCP na Twoich stronach są stale krótsze niż 2,5 sekundy, względne proporcje nie mają większego znaczenia. Jeśli jednak poświęcasz zbyt dużo czasu na którąkolwiek z części „opóźnienia”, trudno będzie Ci stale osiągać cel 2,5 sekundy.
Zestawienie czasu LCP można przedstawić w ten sposób:
- Zdecydowana większość czasu LCP powinna być poświęcona na ładowanie dokumentu HTML i źródła LCP.
- Każdy moment przed LCP, w którym jeden z tych 2 zasobów nie jest wczytywany, to okazja do poprawy.
Jak zoptymalizować poszczególne części
Teraz, gdy wiesz, jak powinny wyglądać czasy poszczególnych części LCP na dobrze zoptymalizowanej stronie, możesz zacząć optymalizować własne strony.
W kolejnych 4 sekcjach przedstawimy rekomendacje i sprawdzone metody optymalizacji poszczególnych części. Są one przedstawione w kolejności, zaczynając od optymalizacji, które prawdopodobnie będą miały największy wpływ.
1. Eliminowanie opóźnienia ładowania zasobów
Celem tego kroku jest zapewnienie, że zasób LCP zacznie się ładować jak najwcześniej. Teoretycznie zasób może zacząć się wczytywać natychmiast po TTFB, ale w praktyce zawsze występuje pewne opóźnienie, zanim przeglądarki zaczną wczytywać zasoby.
Dobrym rozwiązaniem jest rozpoczęcie ładowania zasobu LCP w tym samym czasie co pierwszego zasobu wczytywanego przez stronę. Innymi słowy, jeśli zasób LCP zaczyna się ładować później niż pierwszy zasób, można to poprawić.
Ogólnie rzecz biorąc, na szybkość ładowania zasobu LCP wpływają 2 czynniki:
- Gdy zasób zostanie wykryty.
- Priorytet, jaki ma zasób.
Optymalizacja w momencie wykrycia zasobu
Aby zasób LCP zaczął się wczytywać jak najwcześniej, musi być wykrywalny w początkowej odpowiedzi dokumentu HTML przez skaner wstępnego wczytywania przeglądarki. Na przykład w tych przypadkach przeglądarka może wykryć zasób LCP, skanując odpowiedź dokumentu HTML:
- Element LCP jest elementem
<img>, a jego atrybutysrclubsrcsetsą obecne w początkowym znaczniku HTML. - Element LCP wymaga obrazu tła CSS, ale ten obraz jest wstępnie wczytywany za pomocą
<link rel="preload">w znacznikach HTML (lub za pomocą nagłówkaLink). - Element LCP to węzeł tekstowy, który wymaga renderowania za pomocą czcionki internetowej, a czcionka jest wczytywana za pomocą tagu
<link rel="preload">w kodzie HTML (lub za pomocą nagłówkaLink).
Oto kilka przykładów sytuacji, w których zasób LCP nie może zostać wykryty podczas skanowania odpowiedzi dokumentu HTML:
- Element LCP to element
<img>, który jest dynamicznie dodawany do strony za pomocą JavaScriptu. - Element LCP jest wczytywany z opóźnieniem za pomocą biblioteki JavaScript, która ukrywa jego atrybuty
srclubsrcset(często jakodata-srclubdata-srcset). - Element LCP wymaga obrazu tła CSS.
W każdym z tych przypadków przeglądarka musi uruchomić skrypt lub zastosować arkusz stylów (co zwykle wiąże się z oczekiwaniem na zakończenie żądań sieciowych), zanim będzie mogła wykryć zasób LCP i zacząć go wczytywać. Nigdy nie jest to optymalne rozwiązanie.
Aby wyeliminować niepotrzebne opóźnienie w ładowaniu zasobów, zasób LCP powinien być widoczny w kodzie źródłowym HTML. Jeśli zasób jest używany tylko w zewnętrznym pliku CSS lub JavaScript, zasób LCP powinien być wstępnie wczytany z wysokim priorytetem pobierania, np.:
<!-- Load the stylesheet that will reference the LCP image. -->
<link rel="stylesheet" href="/path/to/styles.css">
<!-- Preload the LCP image with a high fetchpriority so it starts loading with the stylesheet. -->
<link rel="preload" fetchpriority="high" as="image" href="/path/to/hero-image.webp" type="image/webp">
optymalizować priorytet, jaki ma zasób;
Nawet jeśli zasób LCP jest wykrywalny w kodzie HTML, nadal może nie zacząć się ładować tak wcześnie jak pierwszy zasób. Może się tak zdarzyć, jeśli heurystyka priorytetów skanera wstępnego wczytywania przeglądarki nie rozpozna, że zasób jest ważny, lub jeśli uzna, że inne zasoby są ważniejsze.
Możesz na przykład opóźnić obraz LCP za pomocą kodu HTML, jeśli ustawisz