Optymalizacja największego wyrenderowania treści

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.

Dobre wartości LCP to 2,5 sekundy lub mniej, słabe to ponad 4,0 sekundy, a wszystko pomiędzy wymaga poprawy.
Dobry wynik LCP to 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ę).

Lokalny i terenowy LCP w panelu Wydajność w Narzędziach deweloperskich w Chrome
Lokalne i terenowe dane LCP w panelu Wydajność w Narzędziach deweloperskich w Chrome w widokach danych na żywo i śladów.

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.

Dane CrUX wyświetlane w PageSpeed Insights
Dane CrUX wyświetlane w PageSpeed Insights.

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.

PageSpeed Insights przełącza się na dane na poziomie źródła, gdy dane na poziomie adresu URL są niedostępne
Gdy PageSpeed Insights nie ma danych na poziomie adresu URL, wyświetla dane na poziomie ź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)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:

Możliwości i diagnostyka LCP w Lighthouse
Diagnostyka Lighthouse i sugestie dotyczące poprawy 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:

Komponenty LCP w Lighthouse
Zestawienie elementów LCP w Lighthouse.

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:

  1. Początkowy dokument HTML
  2. 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.

Kaskada sieciowa z wyróżnionymi zasobami HTML i LCP
Wykres kaskadowy przedstawiający czasy wczytywania kodu HTML strony internetowej i zasobów potrzebnych do obliczenia LCP.