Poprawa największego wyrenderowania treści (LCP) strony może być skomplikowana i często wymaga wielu ruchomych części i kompromisów. W tym poście przyjrzymy się danym z rzeczywistych stron w internecie, aby określić, na czym powinni się skupić deweloperzy.
Klasyczna porada LCP: zmniejsz rozmiar obrazów.
W przypadku większości stron internetowych elementem LCP jest obraz. Zazwyczaj zakłada się, że najlepszym sposobem na poprawę LCP jest optymalizacja obrazu LCP.
Od wprowadzenia wskaźnika LCP mija zwykle 5 lat i jest taka możliwość. Upewnij się, że obrazy mają odpowiedni rozmiar i są odpowiednio skompresowane. W miarę możliwości używaj formatu XXI wieku. Narzędzie Lighthouse ma nawet 3 różne kontrole.
Jednym z powodów, dla których taka wskazówka jest tak powszechna, że można łatwo zmierzyć nadmierną liczbę bajtów, a łatwo zaproponować narzędzia do kompresji obrazu. Implementacja może być prosta w zależności od potoków kompilacji i wdrażania.
Jeśli tak, zrób to. Wysyłanie mniejszej liczby bajtów do użytkowników jest niemal zawsze korzystne. W internecie jest wiele witryn, które nadal wyświetlają niepotrzebnie duże obrazy, a rozwiązanie problemu może nawet podstawowa kompresja.
Jednak gdy zaczęliśmy sprawdzać dane dotyczące wydajności w terenie dotyczące użytkowników Chrome, aby zobaczyć, w jakim czasie zazwyczaj spędzany jest czas LCP, odkryliśmy, że wąskie gardło prawie nigdy nie leży po stronie czasu pobierania obrazów.
Znacznie poważniejszy problem są natomiast inne elementy LCP.
Podział LCP
Aby określić obszary, które mają największe szanse na poprawę LCP, przeanalizowaliśmy dane z ich części LCP, zgodnie z opisem w artykule Optymalizacja LCP.
Każda strona i każda platforma może wyglądać inaczej w przypadku wczytywania i wyświetlania elementu LCP. Każdą stronę można podzielić na następujące części:
- Czas do pierwszego bajtu (TTFB)
- Czas od inicjowania wczytywania strony przez użytkownika do czasu, w którym przeglądarka otrzymuje pierwszy bajt odpowiedzi z dokumentu HTML.
- Opóźnienie wczytywania zasobu
- Czas między TTFB a rozpoczęciem wczytywania zasobu LCP przez przeglądarkę. Jeśli
element LCP nie wymaga obciążenia zasobu do renderowania, tym razem czas to
0. - Czas wczytywania zasobu
- Czas potrzebny na wczytanie zasobu LCP. Jeśli LCP
nie wymaga wczytania zasobu do renderowania, tym razem czas to
0. - Opóźnienie renderowania elementu
- Czas, jaki upływa od zakończenia wczytywania zasobu LCP do elementu LCP w pełni renderowanie.
Rzeczywiste dane o skuteczności nawigacji
| 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 poście przyjrzeliśmy się elementom podrzędnym LCP, korzystając z danych nawigacyjnych strony z parametrem LCP obrazu zasobu podrzędnego w Chrome. Przyjrzeliśmy się już tego rodzaju danym, ale nigdy na podstawie danych z terenu, żeby określić, gdzie prawdziwi użytkownicy spędzają czas, oczekując na LCP strony.
Podobnie jak w przypadku podstawowych wskaźników internetowych, w przypadku każdego punktu początkowego w zbiorze danych CrUX wykorzystaliśmy 75 centyl (p75) dla każdej podczęści LCP. W efekcie uzyskaliśmy 4 rozkłady wartości p75 (po 1 na każdą część podczęści). Aby podsumować te rozkłady, wybraliśmy medianę tych wartości dla wszystkich źródeł dla każdego z 4 podczęści LCP.
Na koniec dzielimy źródła na segmenty w zależności od tego, czy są „dobre”, „wymaga poprawy” czy „słabe”. LCP na 75 centylu. Pomaga to ustalić, co odróżnia źródło z dobrym LCP od źródła o niskim wskaźniku LCP.
Zmniejszyć rozmiar obrazu LCP? Tym razem z użyciem danych
Czas wczytywania to miara czasu potrzebnego do pobrania zasobu LCP, w tym przypadku obrazu. Ten czas jest zwykle proporcjonalny do liczby bajtów na obrazie, dlatego zalecamy zmniejszenie tej liczby bajtów.
Patrząc na rozkład czasu na wcześniejszych wykresach, warto zwrócić uwagę na to, że czas wczytywania obrazu nie zajmuje dużo czasu. W rzeczywistości jest to najkrótsza podczęść LCP we wszystkich segmentach LCP. Czas wczytywania w przypadku źródeł o słabej jakości LCP jest dłuższy w porównaniu z pochodzeniem LCP o dobrej jakości, ale w przypadku tych źródeł zaoszczędzony czas jest też w dużej mierze.
Większość źródeł o niskim LCP poświęca mniej niż 10% czasu LCP p75 na pobranie obrazu LCP.
Tak, musisz zadbać o optymalizację obrazów, ale to tylko jeden z elementów poprawiania LCP. Na podstawie tych danych wyraźnie widać, że w przypadku typowego źródła stron internetowych potencjalny wzrost LCP w postaci milisekundy jest niewielki, bez względu na to, jak bardzo zaawansowany jest schemat kompresji.
I ostatnia niespodzianka: niekiedy przyczyną problemu były długie czasy wczytywania i jakość sieci komórkowych. Być może spodziewaliśmy się, że na typowym telefonie pobranie tego samego zdjęcia za pomocą połączenia przewodowego trwa kilka razy dłużej niż na komputerze. Dane sugerują, że już tak nie jest. W przypadku źródeł o niskim wskaźniku LCP mediana czasu wczytywania obrazu P75 na urządzeniach mobilnych jest o 20% dłuższa niż na komputerach.
Czas do pierwszego bajtu (TTFB)
W przypadku nawigacji wysyłającej żądanie sieciowe funkcja TTFB może zająć trochę czasu. Przeprowadzenie wyszukiwania DNS i rozpoczęcie połączenia może trochę potrwać. Nie da się pokonać fizyki: żądanie musi podróżować przez rzeczywisty świat przewodami i kablami optycznymi, aby dotrzeć do serwera, a potem w odpowiedzi na nie odpowiedzieć. Nawet w przypadku 75 centyla wartości mediany punktu odniesienia o dobrym wskaźniku LCP czas spędzany w trakcie przeglądania TFB przez ponad pół sekundy.
Jednak rozbieżność między poprawnymi i słabymi wskaźnikami LCP wskazuje szanse na poprawę wyników. W przypadku co najmniej połowy źródeł o niskim LCP p75 TTFB o długości 2270 ms sam niemal gwarantuje, że wartość LCP p75 nie będzie szybsza niż 2,5 sekundy jako „dobra”. Nawet niewielkie procentowe skrócenie tego czasu oznacza znaczną poprawę LCP.
Nie uda Ci się pokonać fizyki, ale są rzeczy, które da się zrobić. Jeśli na przykład Twoi użytkownicy często znajdują się w zupełnie innej lokalizacji niż Twoje serwery, sieć CDN może przybliżyć im Twoje treści.
Więcej informacji znajdziesz w przewodniku po optymalizacji TTFB.
Opóźnienie wczytywania zasobu – pomijany problem z powolnym LCP
Jeśli można usprawnić TTFB, ale wszelkie ulepszenia wiąże się z fizyką, można potencjalnie wyeliminować opóźnienie wczytywania zasobów – w praktyce jest to związane tylko z architekturą obsługi.
Ta część podczęści mierzy czas od momentu dostarczenia pierwszego bajtu odpowiedzi HTML (TTFB) do momentu, gdy przeglądarka rozpoczyna żądanie obrazu LCP. Od lat skupiamy się na tym, jak długo trwa pobieranie obrazów LCP, ale często ignorujemy czas marnowany, zanim przeglądarka w ogóle poprosi o rozpoczęcie pobierania.
W przypadku witryny o niskim wskaźniku LCP oczekiwanie na rozpoczęcie pobierania obrazu LCP trwa prawie 4 razy dłużej, ponieważ w rzeczywistości pobiera go, czyli 1,3 sekundy między TTFB a żądaniem obrazu. To więcej niż połowa 2,5-sekundowego budżetu LCP zaplanowana na jedną część składową.
Łańcuchy zależności są częstą przyczyną długich opóźnień w ładowaniu. Najprostszym rozwiązaniem jest strona wczytująca arkusz stylów, który po utworzeniu układu obrazu w przeglądarce ustawia obraz tła, który ostatecznie stanie się wartością LCP. Wszystkie te kroki muszą zostać wykonane, zanim przeglądarka zacznie pobierać obraz LCP.
korzystanie z publicznych danych indeksowania z archiwum HTTP, które rejestrują „inicjator” łańcuch żądań sieciowych z dokumentu HTML do obrazu LCP, wyraźnie widać zależność między długością łańcucha żądań a mniejszą wartością LCP.
Najważniejsze jest, aby jak najszybciej poinformować przeglądarkę o poziomie LCP, aby mogła rozpocząć wczytywanie, jeszcze zanim w układzie strony znajdzie się miejsce na jego umieszczenie. Jest do tego kilka narzędzi, np. klasyczny tag <img> w kodzie HTML, który skaner wstępnego wczytywania może go szybko znaleźć i zacząć pobierać. Można też użyć tagu <link rel="preload"> (lub nagłówka HTTP) w przypadku obrazów, które nie będą <img>.
Ważne jest też, aby pomóc przeglądarce określić, które zasoby należy traktować priorytetowo. Dzieje się tak zwłaszcza wtedy, gdy strona wysyła wiele żądań podczas jej wczytywania, ponieważ przeglądarka często nie wie, czym jest element LCP, dopóki wiele z tych zasobów nie zostanie załadowanych i nie będzie miał układu. Adnotacje w postaci prawdopodobnego elementu LCP za pomocą atrybutu fetchpriority="high" (i unikanie loading="lazy") jasno pokazują przeglądarce, że zasób może zacząć się od razu ładować.
Przeczytaj więcej porad na temat optymalizacji opóźnienia wczytywania.
Opóźnienie renderowania
Opóźnienie renderowania mierzy czas od załadowania i gotowości obrazu LCP w przeglądarce. Z jakiegoś powodu jednak może to nastąpić z pewnym opóźnieniem, zanim pojawi się on na ekranie. Czasami jest to długie zadanie blokujące wątek główny, gdy obraz jest gotowy. W innych przypadkach wyświetlenie ukrytego elementu może być wskazane w interfejsie.
W przypadku typowych źródeł w internecie nie ma dużego opóźnienia renderowania, ale podczas optymalizacji możesz czasem utworzyć opóźnienie renderowania, które będzie zależne od czasu poświęcanego wcześniej na udział w innych częściach witryny. Jeśli na przykład strona zacznie wstępnie ładować obraz LCP, aby był on szybko dostępny, opóźnienie wczytywania nie będzie długotrwałe, ale gdy sama strona nie będzie gotowa do wyświetlenia obrazu, np. z dużego arkusza stylów blokującego renderowanie lub z aplikacji renderującej po stronie klienta, która musi najpierw załadować cały kod JavaScriptu, przed wyświetleniem cokolwiek wyświetla się LCP – ze względu na opóźnienie renderowania pojawia się czas oczekiwania. Dlatego renderowanie po stronie serwera lub statyczny kod HTML ma często przewagę, jeśli chodzi o wskaźnik LCP.
Jeśli problem dotyczy Twoich treści, przeczytaj więcej porad na temat optymalizacji opóźnienia renderowania.
Zaznacz wszystkie części.
Aby skutecznie optymalizować LCP, deweloperzy muszą całościowo patrzeć na wczytywanie strony, a nie tylko na optymalizację obrazów. Co jakiś czas sprawdzaj wskaźnik LCP, ponieważ szanse na poprawę wyników są prawdopodobnie znacznie większe.
Do zbierania tych danych w polu kompilacja atrybucji w bibliotece Web Vitals uwzględnia czasy 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 to tylko początek. Mamy nadzieję, że w przyszłości dane użyte w tym poście zostaną uwzględnione w raporcie CrUX. Wkrótce podamy więcej informacji na ten temat.
Aby lokalnie przetestować podczęści LCP, skorzystaj z rozszerzenia Web Vitals lub fragmentu kodu JavaScriptu w tym artykule. Lighthouse uwzględnia też podział w elemencie „Największe wyrenderowanie treści” . Więcej porad dotyczących podpunktów dotyczących LCP znajdziesz wkrótce w panelu skuteczności w Narzędziach deweloperskich.