Optymalizacja największego wyrenderowania treści

Na szybkość wczytywania i renderowania strony internetowej może mieć wpływ wiele czynników, a opóźnienia w ich działaniu mogą znacząco wpłynąć 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.

Jak interpretować wskaźnik LCP

Zanim zoptymalizują LCP, deweloperzy powinni sprawdzić, czy w ogóle mają problem z tym wskaźnikiem i jak poważny jest on problem.

LCP można mierzyć za pomocą wielu 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, jak czują się oni podczas korzystania z witryny, 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 o prawdziwych użytkownikach 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 milionach witryn.

Korzystanie z danych LCP w narzędziach deweloperskich w Chrome

Panel wydajności w Narzędziach deweloperskich w Chrome wyświetla lokalny wskaźnik LCP obok strony lub LCP CrUX w widoku danych transmisji na żywo.

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 w raporcie CrUX 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 na dole 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łego Origin

Możesz je włączać i wyłączać za pomocą elementów sterujących u góry tej sekcji. Jeśli URL nie ma wystarczającej ilości danych do wyświetlenia na poziomie adresu URL, ale ma dane na temat źródła, PageSpeed Insights zawsze pokazuje dane o pochodzeniu.

Wartość LCP całego punktu początkowego może się znacznie różnić od LCP pojedynczej strony w zależności od tego, jak LCP jest wczytywany na tej stronie w porównaniu z innymi stronami w tej witrynie. 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.

Przyjrzenie się 4 różnym kategoriom danych raportu na temat użytkowania Chrome może pomóc Ci zrozumieć, czy problem LCP dotyczy tylko tej strony czy raczej całej witryny. Podobnie może ona pokazywać, które typy urządzeń mają problemy z LCP.

Korzystanie z dodatkowych danych CrUX w narzędziu 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 którego użytkownik zaczyna przechodzić na stronę (np. klika link) do momentu otrzymania pierwszych bajtów 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.

Po rozpoczęciu renderowania strony może być początkowo wyrenderowane (np. kolor tła), a potem pojawi się jakaś 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 on 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 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

W sekcji dotyczącej narzędzia Lighthouse na PageSpeed Insights znajdziesz wskazówki dotyczące poprawy LCP. Najpierw sprawdź jednak, czy podany wskaźnik LCP jest w ogóle zgodny z prawdziwymi danymi użytkowników dostarczanymi przez 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 tego wskaźnika. Użyj filtra LCP, aby wyświetlać tylko audyty dotyczące LCP w ten sposób:

Oprócz możliwości ulepszenia masz też dostęp do informacji diagnostycznych, które mogą zawierać więcej informacji, które pomogą zdiagnozować problem. Diagnostyka Największe wyrenderowanie treści zawiera przydatne zestawienie różnych wartości czasu, które składają się na LCP:

W następnym kroku przyjrzymy się bliżej tym elementom.

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 metodologię podziału LCP na najważniejsze części, a potem przedstawianie konkretnych zaleceń i sprawdzonych metod optymalizacji każdej z nich.

Większość wczytań stron obejmuje zwykle kilka żądań sieci, ale aby zidentyfikować możliwości poprawy LCP, na początek powinieneś przyjrzeć się tylko 2 z nich:

1. Początkowy dokument HTML
2. Zasób LCP (jeśli dotyczy)

Inne żądania na stronie mogą wpływać na LCP, ale te 2 żądania, a w szczególności 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 deweloperskie w Chrome lub WebPageTest), aby określić element LCP. Możesz tam dopasować adres URL (ponownie, w stosownych przypadkach) wczytany przez element w splacie sieci wszystkich zasobów załadowanych przez stronę.

Na przykład na tej wizualizacji te zasoby są wyróżnione na diagramie kaskady sieci podczas typowego wczytywania strony, gdy element LCP wymaga przesłania żądania obrazu.

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 którego użytkownik rozpocznie wczytywanie strony do momentu otrzymania przez przeglądarkę pierwszego bajtu odpowiedzi z dokumentu HTML.

Opóźnienie ładowania zasobów

Czas między czasem TTFB a momentem, gdy przeglądarka rozpoczyna wczytywanie zasobu LCP. Jeśli element LCP nie wymaga wczytania zasobów do renderowania (np. jeśli jest to węzeł tekstowy renderowany za pomocą czcionki systemowej), ten czas wynosi 0.

Czas wczytywania zasobu

Czas potrzebny na wczytanie zasobu LCP. Jeśli renderowanie elementu LCP nie wymaga załadowania zasobów, ten czas wynosi 0.

Opóźnienie renderowania elementu

Czas, jaki upływa od zakończenia wczytywania zasobu LCP do pełnego 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żna podzielić na cztery 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 elementy 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 łańcuchu 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 zakończy się wczytywanie kodu JavaScript, a potem wszystko zostaje odsłonięte naraz.

Ten przykład pokazuje, że aby uzyskać najlepsze wyniki LCP, musisz zoptymalizować wszystkie te elementy.

Optymalne czasy części składowych

Aby zoptymalizować każdą część LCP, trzeba wiedzieć, jak idealny rozkład tych części jest odpowiedni na dobrze zoptymalizowanej stronie.

Dwie z tych 4 części mają w nazwie słowo „opóźnienie”. To wskazówka, że chcesz, aby te czasy były jak najbliższe zeru. Pozostałe 2 części to żądania sieciowe, które z natury są bardzo czasochłonne.

Pamiętaj, że podane przedziały czasowe są wskazówkami, a nie ścisłymi regułami. 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 „opóźnienia”, trudno będzie Ci stale osiągać docelowy czas 2,5 s.

Oto prawidłowy sposób przedstawienia rozkładu czasu LCP:

• Zdecydowaną większość czasu LCP należy poświęcić 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, stanowi szansę na ulepszenie.

Jak zoptymalizować każdą część

Teraz, gdy już wiesz, jak poszczególne czasy ładowania 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. Eliminowanie opóźnienia wczytywania zasobów

W tym kroku należy zadbać o to, aby zasób LCP jak najwcześniej zaczął się ładować. 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.

Jako zasadę można przyjąć, że ładowanie zasobu LCP powinno rozpocząć się w tym samym czasie co pierwszy zasób wczytany przez daną stronę. Inaczej mówiąc, jeśli zasób LCP zacznie się wczytywać później niż pierwszy zasób, będzie można go ulepszyć.

Ogólnie rzecz biorąc, na szybkość wczytywania zasobu LCP wpływają 2 czynniki:

• Gdy zostanie znaleziony zasób.
• Priorytet przypisany do zasobu.

Optymalizacja podczas wykrywania 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 atrybuty src lub srcset są 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łówka Link).
• Element LCP to węzeł tekstowy, który wymaga do renderowania czcionki internetowej, a czcionka jest ładowana za pomocą <link rel="preload"> w znacznikach HTML (lub za pomocą nagłówka Link).

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 src lub srcset (często jako data-src lub data-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 wykryje zasób LCP i zacznie go wczytywać. 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 zasobów, do których odwołuje się tylko zewnętrzny plik CSS lub JavaScript, zasób LCP powinien być wstępnie ładowany z wysokim 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">

Zoptymalizuj priorytet przydzielanego zasobu

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 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 w elemencie <img> ustawisz atrybut loading="lazy". Użycie leniwego ładowania oznacza, że zasób zostanie wczytany dopiero wtedy, gdy układ potwierdzi, że obraz znajduje się w widocznym obszarze. W rezultacie ładowanie może rozpocząć się później niż zwykle.

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 są niewidoczne 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 zapewnić więcej przepustowości zasobom, które jej potrzebują. Zawsze sprawdzaj priorytet zasobów w Narzędziach deweloperskich i testuj zmiany za pomocą narzędzi w laboratorium i na polu.

Po optymalizacji priorytetu zasobu LCP i czasu wykrywania zasobów sieciowych wodospad sieci powinien wyglądać tak (zasób LCP uruchamia się w tym samym czasie co pierwszy zasób):

2. Eliminowanie opóźnienia renderowania elementu.

Celem tego kroku jest zagwarantowanie, że element LCP będzie mógł się wyrenderować od razu 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 skryptów synchronicznych w elementach <head>.
• Zasób LCP został wczytany, ale element LCP nie został jeszcze dodany do modelu DOM (czeka na wczytanie 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 za pomocą znaczników HTML będą blokować renderowanie całej treści, która następuje po nich, co jest dobrą wiadomością, ponieważ zazwyczaj nie chcesz renderować kodu HTML bez stylu. 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:

• wstawić 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 arkusz jest 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 wczytywanie trwa dłużej niż zasób LCP, raczej nie nadaje się do wbudowania.

W większości przypadków najlepszym sposobem, aby arkusz stylów nie blokował 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 kodu CSS: za pomocą Narzędzi deweloperskich w Chrome możesz znaleźć reguły CSS, które nie są używane i które można usunąć (lub odroczyć).
• 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ć z opóźnieniem.
• Zmniejsz i kompresuj kod CSS: w przypadku najważniejszych stylów postaraj się jak najbardziej ograniczyć rozmiar transferu.

Odkładanie lub umieszczanie w kodze źródłowym kodu JavaScript blokującego renderowanie

Prawie nigdy nie trzeba dodawać skryptów synchronicznych (skryptów bez atrybutów async lub defer) do tagu <head> stron, więc prawie zawsze ma to negatywny wpływ na wydajność.

Jeśli kod JavaScript musi być uruchamiany jak najwcześniej podczas wczytywania strony, najlepiej go umieścić w tekście, aby renderowanie nie było opóźnione w oczekiwaniu na kolejne żądanie sieciowe. Podobnie jak w przypadku arkuszy stylów, należy jednak stosować tylko bardzo małe skrypty wbudowane.

<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 po zastosowaniu się do wcześniejszych wskazówek kod JavaScript nie blokuje renderowania i nie jest odpowiedzialny za renderowanie elementów, nadal może 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 wykonania niezwiązanego skryptu, zanim zostanie poddany renderowaniu.

Obecnie wszystkie przeglądarki renderują obrazy w głównym wątku, co oznacza, że wszystko, co blokuje wątek główny, może również prowadzić do niepotrzebnego opóźnienia renderowania elementu.

3. Skrócenie czasu wczytywania zasobów

Celem tego kroku jest skrócenie czasu poświęcanego na przenoszenie 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ą zasób musi pokonać.
• zmniejszenie rywalizacji o przepustowość sieci;
• całkowicie wyeliminować czas sieci;

Zmniejsz rozmiar zasobu

Zasób LCP strony (jeśli taki istnieje) to obraz lub czcionka internetowa. W tych przewodnikach szczegółowo opisujemy, jak zmniejszyć rozmiar obu tych elementów:

• Udostępniaj optymalny rozmiar obrazu
• Używanie nowoczesnych formatów obrazów
• Kompresowanie obrazów
• Zmniejsz rozmiar czcionki internetowej

zmniejszyć odległość, jaką musi 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ą musi pokonać zasób, ale także ogólnie zmniejszają jego rozmiar, automatycznie stosując w Twoim imieniu wszystkie wcześniejsze rekomendacje 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 poproszą o te zasoby po raz drugi, otrzymają je z pamięci podręcznej. W ten sposób 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 w polu font-display ustawisz wartość inną niż auto lub block, tekst będzie zawsze widoczny podczas wczytywania, a LCP nie będzie blokowany po otrzymaniu dodatkowego żądania sieciowego.

Jeśli zasób LCP jest mały, 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 wymaga jednak ostrożności, ponieważ zasoby nie mogą być przechowywane w pamięci podręcznej, a w niektórych przypadkach może to spowodować dłuższe opóźnienia w renderowaniu 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 jako ostatni, 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 prześle 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 wskaźniki 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ń, 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 unikalne parametry adresu URL są używane przez użytkowników 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 podelementów LCP są dostępne w JavaScript za pomocą kombinacji tych interfejsów API dotyczących wydajności:

• Largest Contentful Paint API
• Navigation Timing API
• Resource Timing API

Obliczanie tych wartości w JavaScriptzie ma tę zaletę, że możesz wysyłać je do dostawcy usługi analitycznej lub rejestrować w narzędziach dla programistów, aby ułatwić debugowanie i optymalizowanie.

Na przykład ten zrzut ekranu korzysta z metody performance.measure() z interfejsu User Timing API, aby dodać słupki do ścieżki czasu w panelu Wydajność Narzędzi deweloperskich w Chrome.

Wizualizacje na ścieżce Czas trwania są szczególnie przydatne, gdy oglądasz je razem ze ścieżkami Sieć i Główny wątek, ponieważ dzięki temu możesz od razu zobaczyć, co jeszcze dzieje się na stronie w wybranym przedziale czasu.

Oprócz wizualizacji części składowych LCP w ścieżce Czas możesz też użyć JavaScriptu do obliczenia, jaki procent czasu zajmuje każda z nich w stosunku do całkowitego czasu LCP. Na podstawie tych informacji możesz określić, czy Twoje strony spełniają podane wcześniej zalecane zestawienie procentowe.

Ten zrzut ekranu pokazuje przykład, w którym na konsoli rejestrowany jest łączny czas trwania poszczególnych części LCP oraz ich procentowy udział w całościowym czasie LCP.

Obie te wizualizacje zostały utworzone za pomocą tego kodu:

const LCP_SUB_PARTS = [
  'Time to first byte',
  'Resource load delay',
  'Resource load duration',
  'Element render delay',
];

new PerformanceObserver((list) => {
  const lcpEntry = list.getEntries().at(-1);
  const navEntry = performance.getEntriesByType('navigation')[0];
  const lcpResEntry = performance
    .getEntriesByType('resource')
    .filter((e) => e.name === lcpEntry.url)[0];

  // Ignore LCP entries that aren't images to reduce DevTools noise.
  // Comment this line out if you want to include text entries.
  if (!lcpEntry.url) return;

  // Compute the start and end times of each LCP sub-part.
  // WARNING! If your LCP resource is loaded cross-origin, make sure to add
  // the `Timing-Allow-Origin` (TAO) header to get the most accurate results.
  const ttfb = navEntry.responseStart;
  const lcpRequestStart = Math.max(
    ttfb,
    // Prefer `requestStart` (if TOA is set), otherwise use `startTime`.
    lcpResEntry ? lcpResEntry.requestStart || lcpResEntry.startTime : 0
  );
  const lcpResponseEnd = Math.max(
    lcpRequestStart,
    lcpResEntry ? lcpResEntry.responseEnd : 0
  );
  const lcpRenderTime = Math.max(
    lcpResponseEnd,
    // Use LCP startTime (the final LCP time) because there are sometimes
    // slight differences between loadTime/renderTime and startTime
    // due to rounding precision.
    lcpEntry ? lcpEntry.startTime : 0
  );

  // Clear previous measures before making new ones.
  // Note: due to a bug, this doesn't work in Chrome DevTools.
  LCP_SUB_PARTS.forEach((part) => performance.clearMeasures(part));

  // Create measures for each LCP sub-part for easier
  // visualization in the Chrome DevTools Performance panel.
  const lcpSubPartMeasures = [
    performance.measure(LCP_SUB_PARTS[0], {
      start: 0,
      end: ttfb,
    }),
    performance.measure(LCP_SUB_PARTS[1], {
      start: ttfb,
      end: lcpRequestStart,
    }),
    performance.measure(LCP_SUB_PARTS[2], {
      start: lcpRequestStart,
      end: lcpResponseEnd,
    }),
    performance.measure(LCP_SUB_PARTS[3], {
      start: lcpResponseEnd,
      end: lcpRenderTime,
    }),
  ];

  // Log helpful debug information to the console.
  console.log('LCP value: ', lcpRenderTime);
  console.log('LCP element: ', lcpEntry.element, lcpEntry.url);
  console.table(
    lcpSubPartMeasures.map((measure) => ({
      'LCP sub-part': measure.name,
      'Time (ms)': measure.duration,
      '% of LCP': `${
        Math.round((1000 * measure.duration) / lcpRenderTime) / 10
      }%`,
    }))
  );
}).observe({type: 'largest-contentful-paint', buffered: true});

Możesz użyć tego kodu bez zmian do debugowania lokalnego lub zmodyfikować go, aby wysyłać te dane do dostawcy usług analitycznych. Dzięki temu lepiej poznasz podział LCP na stronach w przypadku rzeczywistych użytkowników.

Podsumowanie

LCP to złożony proces, a jego czas może zależeć od wielu 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:

1. Upewnij się, że zasób LCP zaczyna się ładować jak najwcześniej.
2. Upewnij się, że element LCP może zostać wyświetlony, gdy tylko jego zasób zostanie wczytany.
3. Zmniejsz czas wczytywania zasobu LCP tak bardzo, jak to możliwe, bez obniżania jakości.
4. Dostarcz początkowy dokument HTML tak szybko, jak to możliwe.

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.