Ulepszenie największego wyrenderowania treści (LCP) strony może być skomplikowane, ponieważ często wymaga wielu zmian i kompromisów. W tym artykule analizujemy dane z polów pochodzące z rzeczywistych wczytań stron w internecie, aby określić, na czym deweloperzy powinni się skupić podczas optymalizacji.
Klasyczna porada dotycząca LCP: zmniejszaj rozmiar obrazów.
W przypadku większości stron internetowych element LCP to obraz. Z tego powodu można założyć, że najlepszym sposobem na poprawę LCP jest zoptymalizowanie obrazu LCP.
W ciągu około 5 lat od wprowadzenia LCP ta rada była często podawana w przypadku nagłówków. Upewnij się, że obrazy mają odpowiedni rozmiar i są odpowiednio skompresowane. Możesz też użyć formatu obrazu z XXI wieku. Lighthouse zawiera 3 różne audyty, które umożliwiają tworzenie tych sugestii.
Jedną z przyczyn, dla których jest to tak powszechna rada, jest to, że nadmiar bajtów jest łatwy do zmierzenia, a narzędzia do kompresji obrazów są łatwe do zaproponowania. W zależności od potoków kompilacji i wdrażania może być też łatwa do wdrożenia.
Jeśli tak, zrób to. Wysyłanie mniejszej liczby bajtów do użytkowników jest prawie zawsze korzystne. W internecie jest wiele witryn, które nadal wyświetlają niepotrzebnie duże obrazy, które można by zmniejszyć nawet przy użyciu podstawowej kompresji.
Jednak gdy zaczęliśmy analizować dane dotyczące wydajności użytkowników Chrome, aby sprawdzić, na co zwykle przeznaczają oni czas potrzebny na LCP, okazało się, że czas pobierania obrazów prawie nigdy nie jest problemem.
Zamiast tego znacznie większym problemem są inne elementy LCP.
Podział na części składowe LCP
Aby dowiedzieć się, jakie obszary dają największe możliwości poprawy LCP, przeanalizowaliśmy dane z podelementów LCP, jak opisano w artykule Optymalizacja LCP.
Każda strona i każda platforma może mieć inne podejście do wczytywania i wyświetlania elementów, które stają się elementem LCP strony, ale wszystkie można podzielić na te części:
Cytując z tego artykułu, te części to:
- 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, czas ten wynosi
0
. - Czas wczytywania zasobu
- Czas potrzebny na wczytanie samego zasobu LCP. Jeśli element LCP nie wymaga wczytania zasobów do renderowania, ten czas wynosi
0
. - Opóźnienie renderowania elementu
- Czas od zakończenia wczytywania zasobu LCP do pełnego wyrenderowania elementu LCP.
Dane o skuteczności w rzeczywistych warunkach
Ocena LCP | TTFB (ms) | Opóźnienie wczytywania obrazu (ms) | Czas wczytywania obrazu (ms) | Opóźnienie renderowania (ms) |
---|---|---|---|---|
Dobry | 600 | 350 | 160 | 230 |
Wymagana poprawa | 1360 | 720 | 270 | 310 |
Niska | 2270 | 1290 | 350 | 360 |
W tym wpisie wykorzystaliśmy dane z przechodzenia do innych stron z LCP w Chrome, aby przyjrzeć się elementom składowym LCP. Mieliśmy już wcześniej do czynienia z tego typu danymi, ale nigdy nie korzystaliśmy z danych z pola, aby sprawdzić, na co poświęcają czas prawdziwi użytkownicy podczas oczekiwania na LCP strony.
Podobnie jak w przypadku podstawowych wskaźników internetowych, obliczyliśmy 75. percentyl (p75) każdego podelementu LCP dla każdego źródła w zbiorze danych CrUX, co dało 4 rozkłady wartości p75 (po jednym dla każdego podelementu). Aby podsumować te rozkłady, obliczyliśmy medianę tych wartości dla wszystkich źródeł w przypadku każdego z 4 podelementów LCP.
Na koniec dzielimy źródła na grupy na podstawie tego, czy w przypadku 75 procentyla „dobra”, „wymagana poprawa” czy „słaba” wartość LCP. Dzięki temu możesz sprawdzić, czym różni się origin o dobrym LCP od originu o słabym LCP.
Zmniejszyć rozmiar obrazu LCP? Tym razem z danymi
Czas wczytywania to czas potrzebny na pobranie zasobu LCP, w tym przypadku obrazu. Czas ten jest zwykle proporcjonalny do liczby bajtów w obrazie, dlatego wszystkie porady dotyczące wydajności dotyczą zmniejszania tej liczby.
Jeśli spojrzeć na to, na co składają się czasy z poprzednich wykresów, widać, że na wczytywanie obrazów nie poświęca się zbyt wiele czasu. Jest to najkrótszy podelement LCP we wszystkich zbiorach LCP. Czas wczytywania jest dłuższy w przypadku źródeł o złej wartości LCP niż w przypadku źródeł o dobrej wartości LCP, ale i tak nie jest to miejsce, w którym spędza się najwięcej czasu.
Większość źródeł o niskiej wartości LCP poświęca na pobieranie obrazu LCP mniej niż 10% czasu LCP75.
Tak, musisz zadbać o to, aby Twoje obrazy były zoptymalizowane, ale to tylko jeden z elementów poprawiania LCP. Z tych danych wynika, że w przypadku typowego źródła w internecie potencjalne oszczędności w czasie ładowania LCP są niewielkie, niezależnie od tego, jak zaawansowany jest schemat kompresji.
Ostatnia niespodzianka: kiedyś za wolne wczytywanie winiono urządzenia mobilne i jakość sieci komórkowych. Kiedyś zakładaliśmy, że pobieranie tego samego obrazu na typowym telefonie zajmie kilka razy więcej czasu niż na komputerze z połączeniem przewodowym. Dane wskazują, że tak już nie jest. W przypadku źródeł o niskiej wartości LCP średni czas wczytywania obrazu p75 na urządzeniach mobilnych jest tylko o 20% dłuższy niż na komputerach.
Czas do pierwszego bajtu (TTFB)
W przypadku nawigacji, która wysyła żądanie do sieci, czas TTFB zawsze będzie dłuższy. Wyszukiwanie DNS i nawiązanie połączenia zajmuje trochę czasu. Nie da się też obejść praw fizyki: żądanie musi dotrzeć do serwera przez rzeczywisty świat po kablach i przez przewody optyczne, a potem odpowiedź musi wrócić z powrotem. Nawet średnia wartość pochodzenia z dobrym czasem LCP zajmuje ponad pół sekundy na TTFB w 75. percentylu.
Różnica w czasie TTFB między stronami o dobrym a złym LCP wskazuje jednak, że istnieje możliwość poprawy. W przypadku co najmniej połowy źródeł o niskiej wartości LCP wartość TTFB p75 wynosząca 2270 ms prawie zawsze gwarantuje, że wartość p75 LCP nie może być krótsza niż 2,5 s, czyli wartość progowa „dobrego” wyniku. Nawet niewielkie procentowe skrócenie tego czasu oznaczałoby znaczną poprawę LCP.
Możesz nie być w stanie pokonać praw fizyki, ale możesz zrobić kilka rzeczy. Jeśli na przykład Twoi użytkownicy często znajdują się w miejscach bardzo odległych od Twoich serwerów, sieć CDN może przesłać treści bliżej nich.
Więcej informacji znajdziesz w przewodniku Optymalizacja czasu TTFB.
Opóźnienie ładowania zasobów – często pomijany czynnik powodujący długi czas wczytywania LCP
Jeśli TTFB można poprawić, ale wszelkie ulepszenia są ograniczone przez prawa fizyki, opóźnienie ładowania zasobów można potencjalnie wyeliminować, a w praktyce ograniczone jest tylko przez architekturę serwowania.
Ta część mierzy czas od momentu dotarcia pierwszego bajtu odpowiedzi HTML (TTFB) do momentu, w którym przeglądarka rozpoczyna żądanie obrazu LCP. Od lat skupiamy się na czasie pobierania obrazów LCP, ale często ignorowaliśmy czas marnowany, zanim przeglądarka otrzyma polecenie rozpoczęcia pobierania.
Średnia witryna o niskiej wartości LCP spędza na rozpoczęciu pobierania obrazu LCP prawie 4 razy więcej czasu niż na jego faktyczne pobranie.Czas odbierania odpowiedzi na żądanie pobierania obrazu wynosi 1, 3 sekundy. To ponad połowa budżetu na LCP wynoszącego 2,5 sekundy, który został wykorzystany w jednej części.
Łańcuchy zależności są częstą przyczyną długich opóźnień wczytywania. Prostszą opcją jest strona wczytująca arkusz stylów, który po ułożeniu przez przeglądarkę ustawia obraz tła, który stanie się LCP. Wszystkie te kroki muszą zostać wykonane, zanim przeglądarka zacznie pobierać obraz LCP.
Korzystając z publicznych danych z przeszukiwania w Archiwum HTTP, które rejestruje łańcuch żądań sieciowych „inicjatora” od dokumentu HTML do obrazu LCP, możesz zauważyć wyraźną korelację długości łańcucha żądań z wolniejszym czasem LCP.
Najważniejsze jest, aby jak najszybciej poinformować przeglądarkę, czym będzie LCP, aby mogła zacząć go wczytywać, nawet zanim znajdzie się na stronie miejsce na ten element. Do tego celu służy kilka narzędzi, np. klasyczny tag <img>
w HTML, dzięki któremu skaner wstępnego wczytania może szybko go znaleźć i rozpocząć pobieranie, lub tag <link rel="preload">
(lub nagłówek HTTP) dla obrazów, które nie będą <img>
.
Ważne jest też, aby pomóc przeglądarce określić, które zasoby mają mieć najwyższy priorytet. Jest to szczególnie ważne, jeśli podczas wczytywania strony wysyła ona wiele żądań, ponieważ przeglądarka często nie wie, jaki będzie element LCP, dopóki nie wczytają się wszystkie te zasoby i nie zostanie utworzony układ. Dodanie do prawdopodobnego elementu LCP atrybutu fetchpriority="high"
(i uniknięcie atrybutu loading="lazy"
) sprawia, że przeglądarka wie, że zasób ma się zacząć wczytywać natychmiast.
Więcej wskazówek dotyczących optymalizacji opóźnienia wczytywania
Opóźnienie renderowania
Opóźnienie renderowania to czas od momentu, gdy przeglądarka wczyta i przygotuje obraz LCP, do momentu, gdy zostanie on wyświetlony na ekranie. Czasami jest to długie zadanie blokujące wątek główny, gdy obraz jest gotowy, a w innych przypadkach może to być wybór w interfejsie, który powoduje wyświetlenie ukrytego elementu.
W przypadku typowego źródła w internecie nie ma możliwości znacznego opóźnienia renderowania, ale podczas optymalizacji czasami można utworzyć opóźnienie renderowania z czasu wcześniej spędzonego w innych częściach. Jeśli na przykład strona zacznie wstępnie wczytywać obraz LCP, aby był szybko dostępny, nie będzie już długiego opóźnienia wczytywania, ale jeśli sama strona nie jest gotowa do wyświetlenia obrazu, np. z powodu dużego arkusza stylów blokującego renderowanie lub aplikacji do renderowania po stronie klienta, która musi ukończyć wczytywanie całego kodu JavaScript, zanim będzie można wyświetlić obraz, LCP będzie nadal wczytywać się wolniej niż powinien, a czas oczekiwania będzie teraz wyświetlany jako opóźnienie renderowania. Dlatego renderowanie po stronie serwera lub statyczny kod HTML często ma przewagę w przypadku LCP.
Jeśli problem dotyczy Twoich treści, przeczytaj więcej wskazówek dotyczących optymalizacji opóźnienia renderowania.
Sprawdź wszystkie te podelementy.
Aby skutecznie optymalizować LCP, deweloperzy muszą całościowo spojrzeć na wczytywanie strony, a nie skupiać się tylko na optymalizacji obrazów. Sprawdź każdą część czasu LCP, ponieważ prawdopodobnie masz dużo większe możliwości poprawy.
Aby zbierać te dane w polu, budowa atrybucji biblioteki web-vitals obejmuje czasy trwania poszczególnych części LCP. Raport na temat użytkowania Chrome (CrUX) nie zawiera jeszcze wszystkich tych danych, ale zawiera wpisy dotyczące TTFB i LCP, więc jest to dobry początek. Mamy nadzieję, że w przyszłości uda nam się uwzględnić w CrUX dane użyte w tym poście. Bądź na bieżąco z aktualnościami na ten temat.
Aby testować elementy składowe LCP lokalnie, użyj rozszerzenia Web Vitals lub fragmentu kodu JavaScript podanego w tym artykule. Lighthouse zawiera też zestawienie w ramach audytu „Element największego wyrenderowania treści”. Więcej wskazówek dotyczących poszczególnych elementów LCP znajdziesz w panelu Wydajność w Narzędziach deweloperskich, który wkrótce udostępnimy.