Szczegółowy przewodnik, jak analizować LCP i określać 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 podstawowych wskaźników internetowych, który określa, jak szybko wczytują się główne treści strony. Wskaźnik LCP mierzy czas od momentu, gdy użytkownik rozpoczyna wczytywanie strony, do momentu wyrenderowania największego obrazu lub bloku tekstu w widocznym obszarze.
Aby wygodnie korzystać z witryny, w przypadku co najmniej 75% wizyt LCP powinien wynosić 2,5 sekundy lub mniej.
Na szybkość wczytywania i renderowania strony internetowej może mieć wpływ wiele czynników, a opóźnienia w ich działaniu mogą mieć znaczący wpływ na LCP.
Rzadko zdarza się, aby szybka poprawa jednego elementu strony spowodowała istotną poprawę wskaźnika LCP. Aby poprawić LCP, musisz przyjrzeć się całemu procesowi wczytywania i upewnić się, że każdy jego etap jest zoptymalizowany.
Interpretowanie danych LCP
Zanim zoptymalizują LCP, deweloperzy powinni sprawdzić, czy w ogóle mają problem z tym wskaźnikiem, i jak poważny jest ten problem.
LCP można mierzyć za pomocą różnych narzędzi, ale nie wszystkie z nich mierzą ten wskaźnik w taki sam sposób. Aby zrozumieć LCP rzeczywistych użytkowników, powinniśmy przyjrzeć się temu, jakie są wrażenia użytkowników, a nie temu, co pokazuje narzędzie laboratoryjne, takie jak Lighthouse, lub testy lokalne. Te narzędzia laboratoryjne mogą dostarczyć wiele informacji, które pomogą Ci poprawić LCP, ale pamiętaj, że same testy laboratoryjne mogą nie w pełni odzwierciedlać wrażenia użytkowników.
Dane LCP oparte na danych rzeczywistych użytkowników można uzyskać z instalowanych w witrynie narzędzi Real User Monitoring (RUM) lub z Raportu na temat użytkowania Chrome (CrUX), który zbiera anonimowe dane od prawdziwych użytkowników Chrome na miliony witryn.
Korzystanie z danych LCP w Chrome DevTools
Panel Wydajność w Chrome DevTools pokazuje lokalny czas LCP obok wartości LCP CrUX strony lub pochodzenia w widoku danych na żywo oraz w statystykach dotyczących ścieżki wydajności, w tym podział na czasy poszczególnych części LCP (omówimy to za chwilę).
Dzięki nakładaniu danych z pól na panelu Wydajność możesz sprawdzić, czy strona ma jakieś problemy z LCP w przypadku rzeczywistych użytkowników, i dostosować ustawienia środowiska lokalnego, aby lepiej odtworzyć te problemy i je debugować.
Korzystanie z danych LCP z raportu na temat użytkowania Chrome w PageSpeed Insights
PageSpeed Insights zapewnia dostęp do danych CrUX w sekcji u góry strony o nazwie Dowiedz się, jakie są wrażenia użytkowników. Bardziej szczegółowe dane z testów laboratoryjnych są dostępne w sekcji u dołu strony o nazwie Diagnoza problemów z wydajnością. Jeśli dane CrUX są dostępne w przypadku Twojej witryny, zawsze skup się najpierw na rzeczywistych danych użytkownika.
Narzędzie PageSpeed Insights wyświetla maksymalnie 4 rodzaje danych CrUX:
- Dane dotyczące urządzeń mobilnych dotyczące tego adresu URL
- Dane dotyczące komputera dotyczące tego adresu URL
- Mobilna transmisja danych w całym Origin
- Dane Desktop dotyczące całej Origin
Możesz je włączać i wyłączać za pomocą elementów sterujących u góry tej sekcji. Jeśli adres URL nie ma wystarczającej ilości danych, aby wyświetlić je na poziomie adresu URL, ale ma dane źródłowe, PageSpeed Insights zawsze wyświetla dane źródłowe.
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 wczytywanie LCP przebiega na danej stronie w porównaniu z innymi stronami w tej domenie. Na liczbę wyświetleń może też wpływać sposób, w jaki użytkownicy docierają do tych stron. Strony główne są zwykle odwiedzane przez nowych użytkowników, dlatego często są wczytywane „na zimno”, bez treści w pamięci podręcznej, co powoduje, że są to często najwolniejsze strony w witrynie.
Analiza 4 różnych kategorii danych z CrUX może pomóc Ci ustalić, czy problem z LCP dotyczy tylko tej strony, czy też jest bardziej ogólnym problemem w całej witrynie. Podobnie może ona pokazywać, które typy urządzeń mają problemy z LCP.
Korzystanie z danych uzupełniających CrUX w PageSpeed Insights
Osoby, które chcą zoptymalizować LCP, powinny też używać wartości pierwszego wyrenderowania treści (FCP) i czasu do pierwszego bajta (TTFB), które są dobrymi wskaźnikami diagnostycznymi i mogą dostarczyć cennych informacji o LCP.
TTFB to czas od momentu, gdy użytkownik rozpoczyna nawigację po stronie (np. klika link), do momentu, gdy otrzymane zostaną pierwsze bajty dokumentu HTML. Długi czas TTFB może utrudniać osiągnięcie wartości LCP wynoszącej 2,5 s, a nawet uniemożliwić to.
Długi czas TTFB może być spowodowany wieloma przekierowaniami na serwer, lokalizacją użytkowników daleko od najbliższego serwera witryny, niekorzystnymi warunkami sieci lub brakiem możliwości korzystania z treści w pamięci podręcznej z powodu parametrów zapytania.
Gdy strona zaczyna się renderować, może pojawić się początkowe wyrenderowanie (np. kolor tła), a potem treść (np. nagłówek witryny). Pojawienie się początkowej treści jest mierzone przez wskaźnik FCP. Różnica między FCP a innymi danymi może być bardzo wymowna.
Duża różnica między czasem TTFB a FCP może oznaczać, że przeglądarka musi pobrać wiele komponentów blokujących renderowanie. Może to też oznaczać, że musi wykonać dużo pracy, aby wyrenderować dowolne treści – klasyczny znak, że witryna w dużej mierze polega na renderowaniu po stronie klienta.
Duża różnica między czasem FCP a LCP wskazuje, że zasób LCP jest niedostępny od razu, aby przeglądarka mogła go ustawić jako 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ć zawartość LCP.
Korzystanie z danych Lighthouse w PageSpeed Insights
Sekcja Lighthouse w PageSpeed Insights zawiera wskazówki dotyczące poprawy LCP, ale najpierw sprawdź, czy LCP jest zgodny z danymi o prawdziwych użytkownikach pochodzącymi z raportu CrUX. Jeśli Lighthouse i CrUX podają odmienne wyniki, to prawdopodobnie raport CrUX zawiera bardziej dokładny obraz wrażeń użytkowników. Zanim podejmiesz działania, upewnij się, że dane w raporcie CrUX dotyczą Twojej strony, a nie całego źródła.
Jeśli zarówno Lighthouse, jak i CrUX wskazują, że wartości LCP wymagają poprawy, w sekcji Lighthouse znajdziesz cenne wskazówki dotyczące sposobów poprawy LCP. Użyj filtra LCP, aby wyświetlać tylko audyty dotyczące LCP w ten sposób:
Oprócz Możliwości ulepszenia aplikacji możesz też uzyskać więcej informacji o jej diagnostyce, które pomogą Ci zdiagnozować problem. Diagnostyka Największe wyrenderowanie treści zawiera przydatne zestawienie różnych wartości czasu, które składają się na LCP:
Typy i podelementy zasobów LCP są też dostępne w Chrome UX (CrUX).
W następnym kroku omówimy te podelementy.
Podział według LCP
Optymalizacja LCP może być bardziej skomplikowanym zadaniem, jeśli narzędzie PageSpeed Insights nie podaje sposobu na poprawę tego wskaźnika. W przypadku skomplikowanych zadań lepiej jest podzielić je na mniejsze, łatwiejsze do wykonania zadania i zająć się nimi oddzielnie.
W tej sekcji przedstawiamy metodę podziału LCP na najważniejsze części składowe, a następnie podajemy konkretne rekomendacje i sprawdzone metody optymalizacji poszczególnych części.
Większość wczytań stron obejmuje zwykle kilka żądań sieciowych, ale aby zidentyfikować możliwości poprawy LCP, na początek powinieneś przyjrzeć się tylko dwóm:
- Początkowy dokument HTML
- Zasób LCP (jeśli dotyczy)
Inne żądania na stronie mogą wpływać na LCP, ale te 2 żądania, a ściślej czasy rozpoczęcia i zakończenia zasobu LCP, wskazują, czy Twoja strona jest zoptymalizowana pod kątem LCP.
Aby zidentyfikować zasób LCP, możesz użyć narzędzi dla programistów (takich jak wspomniane wcześniej PageSpeed Insights, Narzędzie DevTools w Chrome lub WebPageTest), aby określić element LCP. Następnie możesz dopasować adres URL (ponownie, w stosownych przypadkach) wczytany przez element w splacie sieci wszystkich zasobów załadowanych przez stronę.
Na przykład poniższa wizualizacja pokazuje te zasoby wyróżnione na diagramie kaskady sieci z typowego wczytania strony, gdzie element LCP wymaga wysłania żądania obrazu do renderowania.
W przypadku dobrze zoptymalizowanej strony żądanie zasobu LCP powinno się rozpocząć jak najwcześniej, a element LCP powinien zostać wyrenderowany tak szybko, jak to możliwe po zakończeniu wczytywania zasobu LCP. Aby zobrazować, czy dana strona przestrzega tej zasady, możesz podzielić łączny czas LCP na te części:
- Czas do pierwszego bajtu (TTFB)
- Czas od momentu zainicjowania wczytywania strony przez użytkownika do chwili, gdy przeglądarka otrzyma pierwszy bajt odpowiedzi dokumentu HTML.
- Opóźnienie ładowania zasobów
- Czas między czasem TTFB a momentem, gdy przeglądarka rozpoczyna wczytywanie zasobu LCP. Jeśli renderowanie elementu LCP nie wymaga wczytania zasobów (np. gdy element jest węzłem tekstowym renderowanym za pomocą czcionki systemowej), czas ten wynosi 0.
- Czas wczytywania zasobu
- Czas potrzebny na wczytanie samego zasobu LCP. Jeśli renderowanie elementu LCP nie wymaga załadowania zasobu, czas jest równy 0.
- Opóźnienie renderowania elementu
- Czas od zakończenia wczytywania zasobu LCP do zakończenia renderowania elementu LCP.
LCP każdej strony składa się z tych 4 podkategorii. Nie ma między nimi żadnych przerw ani nakładania się. Ich czasy łącznie dają pełny czas LCP.
Wartość LCP każdej strony może być podzielona na te 4 części. Nie ma między nimi żadnych przerw ani luk. Razem dają one pełny czas LCP.
Podczas optymalizacji LCP warto spróbować zoptymalizować te podelementy osobno. Pamiętaj jednak, że musisz zoptymalizować wszystkie z nich. W niektórych przypadkach optymalizacja zastosowana w jednej części nie poprawi wskaźnika LCP, tylko przesunie zaoszczędzony czas na inną część.
Na przykład w poprzednim szlaku sieciowym, jeśli zmniejszysz rozmiar pliku obrazu, bardziej go skompresowując lub przechodząc na bardziej optymalny format (np. AVIF lub WebP), spowoduje to skrócenie czasu wczytywania zasobu, ale nie poprawi to wartości LCP, ponieważ czas ten zostanie po prostu przeniesiony do podelementu opóźnienia renderowania elementu:
Dzieje się tak, ponieważ na tej stronie element LCP jest ukryty, dopóki nie skończy się wczytywanie kodu JavaScript, a potem wszystko jest odsłaniane naraz.
Ten przykład pokazuje, że aby osiągnąć najlepsze wyniki LCP, musisz zoptymalizować wszystkie te elementy.
Optymalny czas trwania części
Aby zoptymalizować poszczególne elementy LCP, musisz wiedzieć, jak powinny one wyglądać na dobrze zoptymalizowanej stronie.
Spośród 4 części podrzędnych 2 mają w nazwie słowo „delay” (opóźnienie). To wskazówka, że chcesz, aby te czasy były jak najbliższe zeru. Pozostałe 2 części dotyczą żądań sieci, które z samej swojej natury zajmują trochę czasu.
Pamiętaj, że te przedziały czasowe są wskazówkami, a nie ścisłymi zasadami. Jeśli czasy LCP na stronach są konsekwentnie w zakresie 2,5 sekundy, nie ma większego znaczenia, jakie są względne proporcje. Jeśli jednak poświęcasz zbyt dużo czasu na etapy oznaczenia „opóźnienie”, trudno będzie Ci stale osiągać docelowy czas 2,5 s.
Warto pamiętać, że czas LCP składa się z tych elementów:
- Zdecydowana większość czasu LCP powinna być poświęcona na wczytywanie dokumentu HTML i źródła LCP.
- Każdy moment przed LCP, w którym jeden z tych 2 zasobów nie się wczytuje, to możliwość poprawy.
Jak optymalizować poszczególne części
Teraz, gdy już wiesz, jak poszczególne czasy wczytywania elementów LCP powinny się rozkładać na dobrze zoptymalizowanej stronie, możesz zacząć optymalizować własne strony.
W kolejnych 4 sekcjach znajdziesz zalecenia i sprawdzone metody optymalizacji poszczególnych elementów. Są one prezentowane w kolejności od zmian, które mogą mieć największy wpływ.
1. Wyeliminowanie opóźnienia ładowania zasobów
Celem tego kroku jest jak najszybsze rozpoczęcie wczytywania zasobu LCP. Chociaż teoretycznie zasób może zacząć się wczytywać zaraz po zakończeniu TTFB, w praktyce zawsze występuje pewne opóźnienie, zanim przeglądarki zaczną wczytywać zasoby.
Zasada jest taka, że zasób LCP powinien zacząć się wczytywać w tym samym momencie, co pierwszy zasób wczytywany przez stronę. Inaczej mówiąc, jeśli zasób LCP zaczyna się wczytywać później niż pierwszy zasób, istnieje możliwość poprawy.
Ogólnie rzecz biorąc, na szybkość wczytywania zasobu LCP wpływają 2 czynniki:
- Gdy zostanie odkryty zasób.
- Priorytet przypisany do zasobu.
Optymalizacja po wykryciu zasobu
Aby zasób LCP zaczął się wczytywać jak najwcześniej, musi być on możliwy do wykrycia w pierwotnym dokumencie HTML przez skaner wstępnego wczytania przeglądarki. Na przykład w tych przypadkach przeglądarka może wykryć zasób LCP, skanując odpowiedź dokumentu HTML:
- Element LCP to element
<img>, a jego atrybutysrclubsrcsetsą obecne w początkowym znaczniku HTML. - Element LCP wymaga tła CSS, ale jest ono wstępnie wczytywane za pomocą atrybutu
<link rel="preload">w znaczniku HTML (lub za pomocą nagłówkaLink). - Element LCP to węzeł tekstowy, który wymaga czcionki internetowej do renderowania. W kodzie HTML czcionka jest wczytywana za pomocą atrybutu
<link rel="preload">(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
<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 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 wymaga oczekiwania na zakończenie żądań sieciowych), zanim będzie mogła wykryć zasób LCP i rozpocząć jego wczytywanie. To nigdy nie jest optymalne.
Aby wyeliminować niepotrzebne opóźnienia w wczytywaniu zasobów, zasób LCP powinien być możliwy do znalezienia w źródle HTML. W przypadku, gdy zasób jest używany tylko z zewnętrznego pliku CSS lub JavaScript, zasób LCP powinien być wstępnie wczytywany z wysoką priorytetem pobierania, na przykład:
<!-- 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">
optymalizowanie priorytetu przypisanego zasobowi;
Nawet jeśli zasób LCP jest możliwy do wykrycia w oznaczeniu HTML, nadal może nie zacząć się wczytywać wcześniej niż pierwszy zasób. Może się tak zdarzyć, jeśli heurystyka priorytetów skanera wstępnego wczytywania przeglądarki nie uzna danego zasobu za ważny lub uzna, że inne zasoby są ważniejsze.
Możesz na przykład opóźnić obraz LCP za pomocą kodu HTML, jeśli w elemencie <img> ustawisz atrybut loading="lazy". Użycie leniwego wczytywania oznacza, że zasób nie zostanie wczytany, dopóki układ nie potwierdzi, że obraz znajduje się w widoku, więc może zacząć się wczytywać później niż w innym przypadku.
Nawet bez leniwego wczytywania obrazy nie są wczytywane przez przeglądarki z najwyższym priorytetem, ponieważ nie są to zasoby blokujące renderowanie. Możesz zasugerować przeglądarce, które zasoby są najważniejsze, używając atrybutu fetchpriority w przypadku zasobów, które mogą korzystać z wyższego priorytetu:
<img fetchpriority="high" src="/path/to/hero-image.webp">
Jeśli uważasz, że element <img> może być elementem LCP strony, warto ustawić dla niego parametr fetchpriority="high". Jeśli jednak ustawisz wysoki priorytet dla więcej niż 1 lub 2 obrazów, nie pomoże to w zmniejszeniu wartości LCP.
Możesz też obniżyć priorytet obrazów, które mogą znajdować się na początku odpowiedzi na dokument, ale nie są widoczne ze względu na stylizację, np. obrazów na slajdach w karuzeli, które nie są widoczne na początku:
<img fetchpriority="low" src="/path/to/carousel-slide-3.webp">
Zmniejszenie priorytetu niektórych zasobów może zwiększyć przepustowość zasobów, które jej potrzebują bardziej. Zawsze sprawdzaj priorytet zasobów w Narzędziach deweloperskich i testuj zmiany za pomocą narzędzi w laboratoriach i na polu.
Po optymalizacji priorytetu zasobu LCP i czasu wykrywania zasobów w sieci Twój wodospad sieci powinien wyglądać tak (zasób LCP uruchamia się w tym samym czasie co pierwszy zasób):
2. Wyeliminuj opóźnienie renderowania elementu.
Celem tego kroku jest zapewnienie, aby element LCP mógł zostać wyrenderowany natychmiast po zakończeniu wczytywania jego zasobu, niezależnie od tego, kiedy to nastąpi.
Głównym powodem, dla którego element LCP nie może zostać wyrenderowany natychmiast po zakończeniu wczytywania jego zasobu, jest to, że renderowanie jest blokowane z jakiegoś innego powodu:
- Renderowanie całej strony jest zablokowane z powodu wczytywania się arkuszy stylów lub synchronicznych skryptów w elementach
<head>. - Zasób LCP został załadowany, ale element LCP nie został jeszcze dodany do DOM (czeka na załadowanie kodu JavaScript).
- Element jest ukryty przez inny kod, np. bibliotekę testów A/B, która wciąż określa, w jakim eksperymencie powinien uczestniczyć użytkownik.
- Wątek główny jest zablokowany z powodu długich zadań, a renderowanie musi poczekać na ich zakończenie.
W następnych sekcjach wyjaśniamy, jak rozwiązać problemy związane z najczęstszymi przyczynami opóźnień w renderowaniu elementów.
Ogranicz lub usuń czcionki w plikach CSS, które blokują renderowanie
Arkusze stylów wczytane z otagowania HTML będą blokować renderowanie wszystkich treści, które się za nimi znajdują. Jest to dobre, ponieważ zazwyczaj nie chcesz renderować niestylizowanego kodu HTML. Jeśli jednak arkusz stylów jest tak duży, że jego wczytanie zajmuje znacznie więcej czasu niż zasób LCP, uniemożliwi to renderowanie elementu LCP, nawet po zakończeniu wczytywania zasobu, jak w tym przykładzie:
Aby rozwiązać ten problem, możesz:
- wstawiać arkusz stylów bezpośrednio w pliku HTML, aby uniknąć dodatkowego żądania sieciowego;
- zmniejszyć rozmiar arkusza stylów.
Wstawianie arkusza stylów jest zalecane tylko wtedy, gdy jest on mały, ponieważ wstawiane treści w kodzie HTML nie mogą korzystać z pamięci podręcznej podczas kolejnych wczytywań strony. Jeśli arkusz stylów jest tak duży, że jego wczytanie zajmuje więcej czasu niż zasób LCP, prawdopodobnie nie nadaje się do wstawienia w kod HTML.
W większości przypadków najlepszym sposobem na upewnienie się, że arkusz stylów nie blokuje renderowania elementu LCP, jest zmniejszenie jego rozmiaru, tak aby był mniejszy niż zasób LCP. Dzięki temu nie będzie ona wąskim gardłem w przypadku większości wizyt.
Oto kilka zaleceń dotyczących zmniejszania rozmiaru arkusza stylów:
- Usuwanie nieużywanego CSS: użyj Narzędzi deweloperskich w Chrome, aby znaleźć reguły CSS, które nie są używane i można je usunąć (lub odłożyć).
- Opóźnij wczytywanie nieistotnych stylów CSS: podziel arkusz stylów na style wymagane do wstępnego wczytania strony i style, które można wczytywać leniwie.
- Zmniejsz rozmiar i skompresuj pliki CSS: w przypadku ważnych stylów zmniejsz ich rozmiar przesyłania w jak największym stopniu.
Odkładanie lub wstawianie kodu JavaScript blokującego renderowanie
Dodawanie skryptów synchronicznych (bez atrybutów async ani defer) do <head> stron jest prawie nigdy niepotrzebne i prawie zawsze negatywnie wpływa na wydajność.
Jeśli kod JavaScript musi być wykonywany jak najwcześniej podczas wczytywania strony, najlepiej umieścić go w kodze HTML, aby nie opóźniać renderowania przez oczekiwanie na inne żądanie sieci. Podobnie jak w przypadku arkuszy stylów, skrypty powinny być wstawiane w postaci kodu tylko wtedy, gdy są bardzo małe.
<head> <script src="/path/to/main.js"></script> </head>
<head>
<script>
// Inline script contents directly in the HTML.
// IMPORTANT: only do this for very small scripts.
</script>
</head>Korzystanie z renderowania po stronie serwera
Renderowanie po stronie serwera (SSR) to proces wykonywania logiki aplikacji po stronie klienta na serwerze i odpowiedzi na żądania dotyczące dokumentu HTML z pełnym znacznikiem HTML.
Z punktu widzenia optymalizacji LCP SSR ma 2 główne zalety:
- Twoje zasoby obrazów będą dostępne w źródle HTML (jak opisano w kroku 1).
- Treści strony nie będą wymagać dodatkowych żądań JavaScript, aby mogły zostać wyrenderowane.
Główną wadą SSR jest to, że wymaga dodatkowego czasu przetwarzania na serwerze, co może spowolnić czas TTFB. Zwykle jednak warto, ponieważ czas przetwarzania na serwerze jest pod Twoją kontrolą, a możliwości sieci i urządzeń użytkowników nie.
Opcja podobna do SSR to generowanie witryn statycznych (SSG) lub renderowanie wstępne. Jest to proces generowania stron HTML na etapie kompilacji, a nie na żądanie. Jeśli w Twojej architekturze jest możliwe prerenderowanie, jest to zazwyczaj lepszy wybór pod kątem wydajności.
Dzielenie długich zadań
Nawet jeśli zastosujesz się do wcześniejszych wskazówek i Twój kod JavaScript nie będzie blokować renderowania ani nie będzie odpowiedzialny za renderowanie elementów, może on opóźniać LCP.
Najczęstszą przyczyną jest wczytywanie przez strony dużych plików JavaScriptu, które muszą zostać przeanalizowane i wykonane w głównym wątku przeglądarki. Oznacza to, że nawet jeśli zasób obrazu został całkowicie pobrany, może on nadal czekać na zakończenie działania niezwiązanego skryptu, zanim zostanie poddany renderowaniu.
Wszystkie przeglądarki renderują obrazy w głównym wątku, co oznacza, że wszystko, co blokuje ten wątek, może też spowodować niepotrzebne opóźnienie renderowania elementu.
3. Skrócenie czasu wczytywania zasobów
Celem tego kroku jest skrócenie czasu przesyłania bajtów zasobu przez sieć na urządzenie użytkownika. Ogólnie można to zrobić na 4 sposoby:
- Zmniejsz rozmiar zasobu.
- Zmniejsz odległość, jaką ma pokonać zasób.
- zmniejszenie rywalizacji o przepustowość sieci;
- całkowicie wyeliminować czas oczekiwania na odpowiedź z sieci;
Zmniejsz rozmiar zasobu
Zasób LCP strony (jeśli taki istnieje) to obraz lub czcionka internetowa. W tych przewodnikach znajdziesz szczegółowe informacje o tym, jak zmniejszyć rozmiar obu tych plików:
- Udostępnianie optymalnego rozmiaru obrazu
- Używanie nowoczesnych formatów obrazów
- Kompresowanie obrazów
- Zmniejszanie rozmiaru czcionki w internecie
Zmniejsz odległość, jaką ma pokonać zasób
Oprócz zmniejszenia rozmiaru zasobu możesz też skrócić czas wczytywania, umieszczając serwery jak najbliżej użytkowników pod względem geograficznym. Najlepszym sposobem jest użycie sieci dostarczania treści (CDN).
CDN obrazów są szczególnie przydatne, ponieważ nie tylko zmniejszają odległość, jaką muszą pokonać zasoby, ale także ogólnie zmniejszają ich rozmiar, automatycznie stosując w Twoim imieniu wszystkie wcześniejsze zalecenia dotyczące zmniejszania rozmiaru.
zmniejszenie rywalizacji o przepustowość sieci;
Nawet jeśli zmniejszysz rozmiar zasobu i odległość, jaką musi pokonać, wczytywanie zasobu może potrwać długo, jeśli wczytujesz wiele innych zasobów w tym samym czasie. Ten problem nazywamy konkurencją sieciową.
Jeśli nadasz zasobowi LCP wysoki priorytet fetchpriority i zaczniesz wczytywać go tak szybko, jak to możliwe, przeglądarka zrobi wszystko, co możliwe, aby zasoby o niższym priorytecie nie mogły z nim konkurować. Jeśli jednak wczytujesz wiele zasobów o wysokiej wartości fetchpriority lub po prostu wczytujesz dużo zasobów, może to wpłynąć na szybkość wczytywania zasobu LCP.
całkowite wyeliminowanie czasu sieci;
Najlepszym sposobem na skrócenie czasu wczytywania zasobów jest całkowite wyeliminowanie sieci z procesu. Jeśli zasoby są dostarczane zgodnie z skuteczną zasadą kontroli pamięci podręcznej, użytkownicy, którzy po raz drugi poproszą o te zasoby, otrzymają je z pamięci podręcznej, co spowoduje, że czas wczytywania zasobów będzie praktycznie zerowy.
Jeśli zasób LCP to czcionka internetowa, oprócz zmniejszenia rozmiaru czcionki internetowej zastanów się, czy nie trzeba zablokować renderowania podczas wczytywania czcionki internetowej. Jeśli wartość atrybutu font-display jest inna niż auto lub block, tekst będzie zawsze widoczny podczas wczytywania, a LCP nie będzie blokowane w dodatkowym żądaniu sieci.
Jeśli zasób LCP jest niewielki, warto umieścić go w sposób inline jako adres URL danych, co pozwoli też uniknąć dodatkowego żądania sieci. Używanie adresów URL danych ma jednak pewne ograniczenia, ponieważ zasoby nie mogą być przechowywane w pamięci podręcznej, a w niektórych przypadkach może to spowodować wydłużenie czasu renderowania z powodu dodatkowego kosztu dekodowania.
4. Skrócenie czasu do pierwszego bajtu
Celem tego kroku jest jak najszybsze przesłanie początkowego kodu HTML. Ten krok jest wymieniony na końcu, ponieważ często deweloperzy mają nad nim najmniejszą kontrolę. Jest to jednak też jeden z najważniejszych kroków, ponieważ ma bezpośredni wpływ na wszystkie kolejne kroki. Dopóki backend nie dostarczy pierwszego bajta treści, nic nie może się dziać po stronie front-endu. Dlatego wszystko, co możesz zrobić, aby przyspieszyć TTFB, poprawi też wszystkie inne dane dotyczące wczytywania.
Częstą przyczyną długiego czasu TTFB w przypadku szybkiej witryny jest to, że użytkownicy docierają do niej przez wiele przekierowań, np. z reklam lub linków skróconych. Zawsze minimalizuj liczbę przekierowań, przez które musi przejść użytkownik.
Inną częstą przyczyną jest sytuacja, gdy nie można użyć treści z pamięci podręcznej z serwera peryferyjnego CDN, a wszystkie żądania muszą być kierowane z powrotem do serwera źródłowego. Może się tak zdarzyć, jeśli użytkownicy używają unikalnych parametrów URL do celów analitycznych, nawet jeśli nie powodują one wyświetlenia innej strony.
Szczegółowe wskazówki dotyczące optymalizacji czasu oczekiwania na odpowiedź znajdziesz w przewodniku po optymalizacji czasu oczekiwania na odpowiedź.
Monitorowanie podziału LCP w JavaScript
Informacje o czasie dla wszystkich wcześniej omówionych części LCP są dostępne w JavaScript za pomocą kombinacji tych interfejsów API dotyczących wydajności:
Wiele usług RUM już oblicza części podrzędne za pomocą tych interfejsów API. Biblioteka web-vitals zawiera też te czasy ładowania poszczególnych części LCP w ramach procesu atrybucji. Można się do nich odwoływać w kodzie, aby dowiedzieć się, jak je obliczyć w JavaScript.
Narzędzie Lighthouse i Narzędzia deweloperskie w Chrome mierzą też te podelementy, jak widać na poprzednich zrzutach ekranu, dzięki czemu nie musisz ich obliczać ręcznie w JavaScript.
Podsumowanie
LCP to złożony wskaźnik, a na jego czas trwania może wpływać wiele czynników. Jeśli jednak weźmiesz pod uwagę, że optymalizacja LCP polega przede wszystkim na optymalizacji wczytywania zasobu LCP, może to znacznie uprościć sprawę.
Ogólnie rzecz biorąc, optymalizację LCP można podsumować w 4 kroki:
- Upewnij się, że zasób LCP zaczyna się ładować jak najwcześniej.
- Upewnij się, że element LCP może zostać wyświetlony, gdy tylko jego zasób zostanie wczytany.
- Skróć czas wczytywania zasobu LCP tak bardzo, jak to możliwe, bez obniżania jakości.
- Prześlij jak najszybciej początkowy dokument HTML.
Jeśli możesz wykonać te czynności na swoich stronach, możesz mieć pewność, że zapewniasz użytkownikom optymalne wczytywanie, co powinno być widoczne w rzeczywistych wynikach LCP.