Zoptymalizuj opóźnienie ładowania zasobu LCP

Zoptymalizuj opóźnienie ładowania zasobu LCP

Largest Contentful Paint (LCP) składa się z czterech faz: TTFB, opóźnienie ładowania zasobu (Resource Load Delay), czas ładowania zasobu (Resource Load Duration) i opóźnienie renderowania elementu (Element Render Delay). Prace deweloperskie często koncentrują się na zmniejszeniu czasu ładowania poprzez kompresję plików, ale pomija to opóźnienie ładowania zasobu, które często jest większym źródłem opóźnień. To opóźnienie przed rozpoczęciem pobierania może dodać setki milisekund do LCP, powodując przekroczenie progu 2,5 sekundy dla kategorii „Good". 

Szybka wskazówka: jeśli Twoim elementem LCP jest obraz, prawie zawsze będzie gorszy niż tekst. Musisz śledzić typy elementów LCP w swoich danych RUM, w przeciwnym razie działasz po omacku.

Precyzyjna definicja: krytyczne oczekiwanie przed pobraniem

Opóźnienie ładowania zasobu (Resource Load Delay) to czas między TTFB a momentem, w którym przeglądarka inicjuje pobieranie zasobu LCP. To nie jest czas pobierania; to opóźnienie odkrycia, które występuje przed rozpoczęciem pobierania. Wysoka wartość wskazuje na problem architektoniczny, w którym przeglądarka nie może znaleźć adresu URL zasobu w początkowym dokumencie HTML.  To opóźnienie ładowania zasobu można postrzegać jako czas, który przeglądarka poświęca na zidentyfikowanie potrzeby zasobu LCP i podjęcie decyzji o jego pobraniu.

Dla elementów LCP opartych na tekście i renderowanych przy użyciu czcionki systemowej, to opóźnienie ładowania zasobu wynosi zwykle zero, ponieważ nie trzeba pobierać żadnego zewnętrznego zasobu. Wyższe wartości opóźnienia ładowania zasobu dotyczą konkretnie elementów LCP, które wymagają zewnętrznego zasobu sieciowego, takiego jak obraz lub plik wideo.

Mechanizm odkrywania: Preload Scanner vs. parser DOM

Aby zmniejszyć opóźnienie ładowania zasobu, musisz zrozumieć, jak przeglądarki odkrywają zasoby. Wydajność tego procesu odkrywania jest głównym czynnikiem determinującym opóźnienie. Przeglądarki używają dwóch mechanizmów: szybkiej ścieżki i wolnej ścieżki.

• Preload Scanner (szybka ścieżka): Preload Scanner (szybka ścieżka): Jest to szybki wtórny parser, który skanuje surowy HTML w poszukiwaniu adresów URL zasobów, takich jak te w tagach <img> lub <link>. Kolejkuje je do pobrania natychmiast, zanim CSS zostanie sparsowany lub JavaScript zostanie wykonany. Jest to optymalna ścieżka dla każdego krytycznego zasobu.
• Parser DOM (wolna ścieżka): Jest to główny parser, który konstruuje pełny Document Object Model (DOM) i CSS Object Model (CSSOM). Zasoby nieznalezione w początkowym HTML, takie jak CSS background-image lub element wstrzyknięty przez JavaScript, są odkrywane dopiero przez ten parser. Jest to wolna ścieżka, ponieważ jest zależna od wcześniejszego pobrania i wykonania innych plików, co tworzy łańcuch zależności wprowadzający wysokie opóźnienie.

Cała strategia optymalizacji opóźnienia ładowania zasobu opiera się na jednej zasadzie: upewnij się, że adres URL zasobu LCP jest wykrywalny przez preload scanner. Każdy wzorzec, który ukrywa URL przed początkowym dokumentem HTML, zmusza przeglądarkę do użycia wolnej ścieżki odkrywania. Ten okres oczekiwania bezpośrednio przekłada się na opóźnienie ładowania zasobu. Każda skuteczna optymalizacja polega na takim zaprojektowaniu HTML, aby zasób LCP znajdował się na szybkiej ścieżce.

Dlaczego opóźnienie ładowania ma znaczenie

Powszechnym błędnym przekonaniem jest to, że wolne LCP to problem „rozmiaru pliku". Prowadzi to zespoły do koncentrowania się wyłącznie na kompresji obrazów w celu zmniejszenia czasu ładowania zasobu (Resource Load Duration). Chociaż optymalizacja zasobów jest czynnikiem, analiza rzeczywistych danych polowych pokazuje, że dla wielu stron z niskim wynikiem LCP, opóźnienie ładowania zasobu (Resource Load Delay) jest głównym wąskim gardłem wydajności, a nie czas ładowania zasobu (Resource Load Duration).

Dane polowe pokazują, że mediana stron z niskim wynikiem LCP ma 1,3 sekundy opóźnienia ładowania zasobu. To ponad połowa całego budżetu 2,5 sekundy na wynik LCP „Good", zużyta zanim pobieranie zasobu LCP w ogóle się rozpocznie. Dane wskazują, że te strony spędzają prawie cztery razy więcej czasu na oczekiwaniu na rozpoczęcie pobierania niż na samym pobieraniu.

Te dane ujawniają częste przekierowanie wysiłków deweloperskich. Zespoły mogą spędzać tygodnie na usuwaniu kilobajtów z obrazów, aby skrócić czas ładowania o kilka milisekund, podczas gdy problem architektoniczny powodujący 1,5-sekundowe opóźnienie ładowania pozostaje nierozwiązany. LCP jest procesem sekwencyjnym; opóźnienie we wczesnej fazie nie może zostać zrekompensowane optymalizacją późniejszej fazy. Jeśli pobieranie jest opóźnione o ponad sekundę, 100-milisekundowa różnica w czasie pobierania jest nieistotna dla końcowego wyniku LCP. Optymalizacje o największym wpływie obejmują zmiany architektoniczne, takie jak poprawa wykrywalności zasobów, a nie tylko kompresję zasobów. Nacisk musi zostać przeniesiony z zmniejszania rozmiaru zasobów na Te dane ujawniają częste przekierowanie wysiłków deweloperskich. Zespoły mogą spędzać tygodnie na usuwaniu kilobajtów z obrazów, aby skrócić czas ładowania o kilka milisekund, podczas gdy problem architektoniczny powodujący 1,5-sekundowe opóźnienie ładowania pozostaje nierozwiązany. LCP jest procesem sekwencyjnym; opóźnienie we wczesnej fazie nie może zostać zrekompensowane optymalizacją późniejszej fazy. Jeśli pobieranie jest opóźnione o ponad sekundę, 100-milisekundowa różnica w czasie pobierania jest nieistotna dla końcowego wyniku LCP. Optymalizacje o największym wpływie obejmują zmiany architektoniczne, takie jak poprawa wykrywalności zasobów, a nie tylko kompresję zasobów. Nacisk musi zostać przeniesiony z zmniejszania rozmiaru zasobów na zapewnienie ich wcześniejszego odkrycia.

Jak wykryć opóźnienie ładowania zasobu

Aby naprawić opóźnienie ładowania zasobu, najpierw musisz je dokładnie zmierzyć. Profesjonalny przepływ pracy polega na najpierw zdefiniowaniu problemu za pomocą danych od prawdziwych użytkowników (RUM), a dopiero potem przejściu do Chrome DevTools w celu głębokiej analizy.

Krok 1: Analiza danych polowych (RUM)

Dane polowe, czyli Real User Monitoring (RUM), są zbierane z rzeczywistych sesji użytkowników. Narzędzia RUM, takie jak publiczny Chrome User Experience Report (CrUX) lub moje własne narzędzie CoreDash, odpowiadają na pytanie: Co się dzieje w rzeczywistym świecie? Kompleksowe narzędzie RUM zapewni również podział podfaz LCP, pokazując medianę opóźnienia ładowania zasobu wśród Twoich użytkowników. Te dane potwierdzają, że problem z LCP istnieje, pokazują, które adresy URL są dotknięte, i ujawniają typowe elementy LCP, które widzą Twoi użytkownicy. Musisz zacząć tutaj, aby potwierdzić, że rozwiązujesz prawdziwy problem.

Krok 2: Diagnoza za pomocą DevTools

Gdy Twoje dane RUM zidentyfikowały docelową stronę i element LCP, używasz Chrome DevTools do diagnozowania przyczyny. Celem jest odtworzenie problemu i zmierzenie podfaz LCP, aby uzyskać dokładną wartość opóźnienia ładowania zasobu. DevTools to także miejsce, w którym przeprowadzasz analizę głównego wątku (Main Thread Analysis), aby zobaczyć dokładnie, jakie zadania są uruchamiane i potencjalnie blokują proces renderowania.

Przewodnik krok po kroku po panelu Performance w Chrome DevTools

Panel Performance w Chrome DevTools jest niezbędnym narzędziem do analizy LCP i kwantyfikacji opóźnienia ładowania.

1. Konfiguracja:

• Otwórz Chrome DevTools, klikając prawym przyciskiem myszy na stronie i wybierając "Zbadaj" lub używając skrótu Ctrl+Shift+I (Windows/Linux) lub Cmd+Option+I (Mac).   
• Przejdź do zakładki Performance.
• Upewnij się, że pole wyboru Web Vitals jest włączone w ustawieniach przechwytywania. Spowoduje to nałożenie informacji o Core Web Vitals na oś czasu wydajności.   
• Aby zasymulować realistyczne warunki użytkownika, zastosuj throttling CPU i sieci. „4x slowdown" dla CPU i profil sieciowy „Fast 3G" lub „Slow 4G" to typowe punkty wyjścia do testowania mobilnego.   

2. Nagrywanie profilu wydajności:

• Kliknij przycisk „Record and reload page" (ikona okrągłej strzałki) w panelu Performance. Spowoduje to rozpoczęcie nagrywania, przeładowanie strony, a następnie zatrzymanie nagrywania po pełnym załadowaniu strony.   

3. Analiza i interpretacja:

• Ścieżka Timings: W głównym widoku osi czasu znajdź ścieżkę Timings. Zobaczysz znacznik oznaczony LCP. Najechanie kursorem na ten znacznik podświetli odpowiedni element LCP na zrzucie ekranu głównego widoku i wyświetli całkowity czas LCP.   
• Podział LCP wg faz: Kliknij na znacznik LCP w ścieżce Timings. W zakładce Summary na dole panelu znajdziesz szczegółowy podział czasów LCP. Ten podział jawnie pokazuje czas trwania każdej z czterech podfaz, w tym Load delay, mierzony w milisekundach. Ta wartość jest najbardziej bezpośrednim i precyzyjnym pomiarem opóźnienia ładowania zasobu dla tego konkretnego ładowania strony.   
• Analiza głównego wątku: Przeglądając oś czasu, spójrz na ścieżkę Main pod kątem długich zadań (bloki aktywności oznaczone czerwonym trójkątem). Jeśli te długie zadania występują po zakończeniu ładowania zasobu LCP, ale przed znacznikiem LCP, prawdopodobnie przyczyniają się do opóźnienia renderowania elementu (Element Render Delay), co jest powiązanym, ale odrębnym problemem.   

Typowe przyczyny i rozwiązania o dużym wpływie

Wysokie opóźnienie ładowania zasobu jest spowodowane jednym z dwóch czynników: zasób LCP jest odkrywany późno lub otrzymuje niski priorytet pobierania. Oto najczęstsze błędy architektoniczne i ich rozwiązania.

Przyczyna: LCP ładowane przez CSS

Problem: Preload scanner nie parsuje plików CSS. Gdy Twój obraz LCP jest zdefiniowany za pomocą CSS background-image, jego URL jest niewidoczny dla tego szybkiego skanera. Przeglądarka może odkryć obraz dopiero po pobraniu HTML, znalezieniu odnośnika do pliku CSS, pobraniu pliku CSS, zbudowaniu CSSOM i zastosowaniu stylu. Ten łańcuch zależności bezpośrednio powoduje wysokie opóźnienie ładowania zasobu.

Rozwiązanie: Prawidłowa implementacja polega na unikaniu używania background-image dla jakiegokolwiek krytycznego elementu LCP. Zamiast tego użyj standardowego tagu <img>. Umieszcza to URL obrazu bezpośrednio w HTML, gdzie preload scanner może go natychmiast znaleźć. Ten sam efekt wizualny można osiągnąć za pomocą CSS.

Przykład implementacji:

Antywzorzec (nie rób tego):

    <!-- CSS -->
   .hero {
      background-image: url('hero-image.jpg');
      height: 500px;
      width: 100%;
    }

    <!-- HTML -->
    <div class="hero"></div>
    

Najlepsza praktyka (rób to zamiast tego):

    <!-- HTML -->
    <div class="hero-container">
      <img
        src="hero-image.jpg"
        alt="A descriptive alt text for the hero image"
        fetchpriority="high"
        class="hero-background-img"
        width="1200"
        height="500"
      />
      <div class="hero-content">
        <h1>Page Title</h1>
      </div>
    </div>

    <!-- CSS -->
   .hero-container {
      position: relative;
      height: 500px;
      width: 100%;
    }

   .hero-background-img {
      position: absolute;
      inset: 0; /* Equivalent to top: 0; right: 0; bottom: 0; left: 0; */
      width: 100%;
      height: 100%;
      object-fit: cover; /* This property mimics background-size: cover */
      z-index: -1; /* Places the image behind other content */
    }
    

Ta implementacja zapewnia ten sam efekt wizualny, ale sprawia, że obraz LCP jest wykrywalny w najwcześniejszym możliwym momencie, co minimalizuje jego opóźnienie ładowania.

Przyczyna: renderowanie po stronie klienta i wstrzykiwanie przez JavaScript

Problem: Aplikacje używające frameworków do renderowania po stronie klienta (CSR), takich jak React czy Vue, często serwują minimalną powłokę HTML. Rzeczywista treść, w tym tag LCP <img>, jest wstawiana do DOM przez JavaScript dopiero po pobraniu, sparsowaniu i wykonaniu dużych paczek frameworka. Ten proces fundamentalnie ukrywa zasób LCP przed preload scannerem, tworząc wysokie opóźnienie odkrycia.

Rozwiązanie: Najskuteczniejszym rozwiązaniem jest przeniesienie początkowego renderowania z klienta na serwer.

• Server-Side Rendering (SSR) lub Static Site Generation (SSG): Wzorce architektoniczne takie jak SSR lub SSG generują pełny HTML na serwerze. Przeglądarka otrzymuje kompletny dokument zawierający tag <img> i jego atrybut src, dzięki czemu zasób LCP jest natychmiast wykrywalny przez preload scanner. Jest to wymagana architektura dla każdej strony krytycznej pod względem wydajności.
• Optymalizacje specyficzne dla frameworka: Nowoczesne frameworki oferują również wbudowane optymalizacje. Na przykład komponent <Image> w Next.js ma właściwość priority. Ustawienie jej na true instruuje framework, aby automatycznie dodał odpowiednie atrybuty <link rel="preload"> i fetchpriority="high", zapewniając, że obraz zostanie odkryty i pobrany z odpowiednim priorytetem.

Przyczyna: użycie loading="lazy" na obrazie LCP

Problem: Jest to częsty i mający duży wpływ błąd. Atrybut loading="lazy" to bezpośrednia instrukcja dla przeglądarki, aby opóźnić pobieranie obrazu do momentu, gdy znajdzie się blisko viewportu. Chociaż jest to prawidłowa optymalizacja dla obrazów poniżej linii zagięcia, zastosowanie jej do elementu LCP znajdującego się powyżej linii zagięcia jest kontrproduktywne. Preload scanner przeglądarki jest zaprojektowany tak, aby ignorować obrazy z loading="lazy", co gwarantuje późne odkrycie i wysokie opóźnienie ładowania zasobu.

Rozwiązanie: Rozwiązanie wymaga staranności.

• Usuń loading="lazy" z obrazu LCP: Każdy obraz, który prawdopodobnie będzie elementem LCP, nie powinien mieć atrybutu loading="lazy". Domyślnym zachowaniem przeglądarki jest loading="eager", co jest prawidłowym ustawieniem dla krytycznej treści powyżej linii zagięcia. Pominięcie atrybutu loading ma ten sam efekt.
• Audytuj i konfiguruj narzędzia zewnętrzne: Musisz również audytować narzędzia zewnętrzne. Wiele platform CMS, takich jak WordPress, i różne wtyczki do optymalizacji obrazów automatycznie stosują lazy loading do wszystkich obrazów. Istotne jest skonfigurowanie tych narzędzi tak, aby wykluczały obraz LCP z tego zachowania. Często wymaga to stworzenia reguły wykluczenia dla pierwszego lub dwóch pierwszych obrazów na stronie.

Przyczyna: nieoptymalna struktura HTML i duże dokumenty

Problem: Preload scanner przetwarza dokument HTML od góry do dołu. Jeśli niekrytyczne, ale wymagające dużej przepustowości zasoby, takie jak ikony nagłówka lub skrypty widgetów czatu, są umieszczone wyżej w <body> niż element LCP, są odkrywane i kolejkowane do pobrania jako pierwsze. Zużywa to początkową przepustowość sieci i może opóźnić pobieranie zasobu LCP. Duży dokument HTML może również stanowić problem; jeśli element LCP nie znajduje się w pierwszym fragmencie danych otrzymanych przez przeglądarkę (około 14KB), jego odkrycie jest opóźnione o co najmniej jedną rundę sieciową.

Rozwiązanie: Zoptymalizuj strukturę i priorytet treści w HTML.

• Zmień kolejność w HTML: W miarę możliwości upewnij się, że tag <img> lub blok tekstowy dla elementu LCP pojawia się jak najwcześniej wewnątrz tagu <body>.
• Obniż priorytet niekrytycznych obrazów: Dla nieistotnych obrazów, które muszą pojawiać się wcześnie w kodzie HTML (jak ikony w nagłówku), zastosuj loading="lazy". To instruuje preload scanner, aby je pominął, zachowując kolejkę pobierania dla elementu LCP.
• Odrocz nieistotne skrypty: Skrypty do analityki, reklam lub widgetów mediów społecznościowych rzadko są krytyczne dla początkowego renderowania. Przenieś ich tagi <script> na koniec <body> lub użyj atrybutu defer. Zapobiega to blokowaniu parsera lub konkurowaniu o przepustowość sieci z zasobem LCP.

Zaawansowana priorytetyzacja za pomocą wskazówek zasobów

Gdy zasób LCP jest wykrywalny w HTML, możesz użyć wskazówek zasobów (resource hints), aby dać przeglądarce bardziej precyzyjne instrukcje dotyczące jego pobierania. Te wskazówki zapewniają szczegółową kontrolę nad odkrywaniem i priorytetyzacją.

Wymuszenie wczesnego odkrycia za pomocą <link rel="preload">

<link rel="preload"> to nie wskazówka; to dyrektywa. Zmusza przeglądarkę do pobrania zasobu z wysokim priorytetem, nawet jeśli nie jest jeszcze wykrywalny przez główny parser. Umieszczenie go w <head> HTML to najbardziej bezpośredni sposób na naprawienie problemów z późnym odkryciem zasobów takich jak czcionki, obrazy CSS background lub obrazy LCP znajdujące się głęboko w DOM.

Mechanizm

Gdy link preload jest umieszczony w <head> dokumentu HTML, preload scanner identyfikuje go i natychmiast kolejkuje określony zasób do pobrania. Jest to idealne rozwiązanie dla zasobów takich jak czcionki ładowane przez @font-face w zewnętrznym arkuszu stylów, LCP z CSS background-image (choć preferowane jest użycie tagu <img>) lub obraz LCP znajdujący się głęboko w złożonej strukturze DOM.[3]

Responsywne preładowanie

Krytyczny szczegół implementacyjny jest wymagany przy preładowaniu responsywnych obrazów. Aby upewnić się, że przeglądarka preładuje obraz o odpowiednim rozmiarze dla viewportu użytkownika i uniknie marnotrawnego podwójnego pobierania, tag <link rel="preload"> musi zawierać atrybuty imagesrcset i imagesizes, które dokładnie odzwierciedlają atrybuty na odpowiadającym tagu <img>.[4]

Przykład responsywnego preładowania:

<link rel="preload" as="image"
      href="lcp-image-large.jpg"
      imagesrcset="lcp-image-small.jpg 400w, lcp-image-medium.jpg 800w, lcp-image-large.jpg 1200w"
      imagesizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
      fetchpriority="high">

<img src="lcp-image-large.jpg"
     srcset="lcp-image-small.jpg 400w, lcp-image-medium.jpg 800w, lcp-image-large.jpg 1200w"
     sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
     alt="A descriptive alt text"
     fetchpriority="high"
     width="1200" height="675">
    

Potencjalna pułapka

Preładowanie rozwiązuje problem czasu pobierania (Load Delay i Load Duration), ale nie problem *czasu renderowania*. Jeśli główny wątek jest zablokowany przez ciężki JavaScript lub blokujący renderowanie CSS w momencie przybycia preładowanego obrazu, obraz nadal będzie musiał czekać na wyrenderowanie, co może przenieść wąskie gardło z opóźnienia ładowania na opóźnienie renderowania elementu (Element Render Delay).[5, 6]

Precyzyjne dostrajanie za pomocą fetchpriority="high": wygrywanie bitwy o przepustowość

Atrybut fetchpriority to wskazówka sygnalizująca względne znaczenie pobierania zasobu. Pozwala wpływać na priorytet zasobu w kolejce pobierania przeglądarki.[7]

preload vs. fetchpriority

Te dwie wskazówki służą różnym, ale komplementarnym celom. preload wpływa na to, kiedy zasób jest odkrywany i dodawany do kolejki. fetchpriority wpływa na jego poziom priorytetu, gdy jest już w kolejce.

Najlepsza praktyka dla LCP

Dla obrazu LCP, optymalna strategia polega na użyciu ich razem. Po pierwsze, zapewnij wczesne odkrycie, umieszczając tag <img> wcześnie w HTML lub używając preload. Po drugie, dodaj fetchpriority="high" bezpośrednio do tagu <img> (i do linku preload, jeśli jest używany). Ta kombinacja zapewnia, że zasób jest nie tylko wcześnie odkryty, ale również otrzymuje najwyższy możliwy priorytet, aby wygrać konkurencję o przepustowość sieci z innymi zasobami, takimi jak arkusze stylów czy czcionki.[3, 1, 7]

Przykład:

<img src="lcp-image.jpg" fetchpriority="high" alt="A critical hero image">

Udowodniony wpływ

W studium przypadku dotyczącym Google Flights, dodanie fetchpriority="high" do obrazu tła LCP przyczyniło się do poprawy czasu LCP z 2,6 sekundy do 1,9 sekundy, co stanowi poprawę o 700ms.[8]

Optymalizacja połączeń z zewnętrznymi serwerami: preconnect i dns-prefetch

Problem

Jeśli Twój zasób LCP jest hostowany na domenie zewnętrznej, takiej jak CDN obrazów lub dostawca czcionek, jak Google Fonts, przeglądarka musi nawiązać nowe połączenie sieciowe z tą domeną. Ten proces obejmuje wyszukiwanie DNS, uzgadnianie TCP i negocjację TLS, z których wszystkie muszą zostać zakończone przed pobraniem pierwszego bajtu zasobu. Ten czas konfiguracji połączenia bezpośrednio przyczynia się do opóźnienia ładowania zasobu dla zasobów cross-origin.[9, 2, 10, 11]

Rozwiązania

• preconnect: Ta wskazówka instruuje przeglądarkę, aby wykonała pełną konfigurację połączenia (DNS, TCP i TLS) dla określonego źródła zewnętrznego w tle, z wyprzedzeniem. Gdy zasób jest faktycznie żądany, połączenie jest już nawiązane, eliminując opóźnienie konfiguracji. Jest to wysoce skuteczne i zalecane dla jednej lub dwóch najważniejszych domen zewnętrznych obsługujących zasoby LCP.[2]
• dns-prefetch: Jest to lżejsza wskazówka, która wykonuje tylko wyszukiwanie DNS dla domeny. Oszczędza mniej czasu niż preconnect, ale ma szersze wsparcie przeglądarek i jest przydatna jako rozwiązanie zastępcze lub dla mniej krytycznych domen zewnętrznych.[2, 12]

Najlepsza praktyka implementacji

Aby zapewnić maksymalną kompatybilność, podaj obie wskazówki. Przeglądarka użyje preconnect, jeśli jest obsługiwany, i przejdzie do dns-prefetch, jeśli nie. Atrybut crossorigin jest niezbędny dla zasobów pobieranych za pomocą CORS, takich jak czcionki.

<link rel="preconnect" href="https://my-image-cdn.com" crossorigin>
<link rel="dns-prefetch" href="https://my-image-cdn.com">

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>    

Tabela: porównanie wskazówek zasobów dla optymalizacji LCP

Aby zapobiec niewłaściwemu użyciu i wyjaśnić odrębne role tych potężnych wskazówek, poniższa tabela przedstawia podsumowanie porównawcze.

Holistyczne i przyszłościowe strategie

Oprócz celowanych wskazówek, szersze decyzje architektoniczne i pojawiające się funkcje platformy webowej mogą zapewnić holistyczne i potężne rozwiązania problemu opóźnienia ładowania zasobu.

Rola nowoczesnego CDN

Content Delivery Network (CDN) to fundamentalna technologia wydajności webowej, która pośrednio, ale znacząco zmniejsza opóźnienie ładowania zasobu, szczególnie dla zasobów LCP.

• Zmniejszenie narzutu połączenia: Poprzez dystrybucję zasobów w globalnej sieci serwerów, CDN umieszcza treść geograficznie bliżej użytkownika. To z natury zmniejsza czas podróży w obie strony (RTT) wymagany do wyszukiwania DNS, uzgadniania TCP i negocjacji TLS, które są elementami czasu konfiguracji połączenia.[13, 14, 15] Dla obrazu LCP hostowanego na CDN bezpośrednio zmniejsza to jego opóźnienie ładowania.
• CDN obrazów: Wyspecjalizowane CDN obrazów oferują podwójną korzyść. Zapewniają przewagę bliskości standardowego CDN, jednocześnie automatyzując wiele złożonych optymalizacji zmniejszających czas ładowania zasobu, takich jak zmiana rozmiaru obrazu w locie, kompresja i konwersja do nowoczesnych formatów, takich jak AVIF i WebP.[9, 1]
• Zaawansowane protokoły: Wiele nowoczesnych CDN wykorzystuje lepsze protokoły sieciowe, takie jak HTTP/3, który używa QUIC zamiast TCP. HTTP/3 zmniejsza czas konfiguracji połączenia i łagodzi blokowanie head-of-line, prowadząc do szybszego i bardziej wydajnego dostarczania zasobów ogólnie.[16]

Całkowite eliminowanie opóźnienia za pomocą Speculation Rules

Speculation Rules API to nowatorska funkcja platformy webowej, która oferuje potencjał całkowitego wyeliminowania opóźnienia LCP dla kolejnych nawigacji.

Mechanizm

To API pozwala deweloperom deklaratywnie informować przeglądarkę o tym, do których adresów URL użytkownik prawdopodobnie przejdzie dalej. Na podstawie tych reguł przeglądarka może zdecydować się na prerenderowanie docelowej strony w ukrytej karcie w tle, zanim użytkownik kliknie link.[3, 1, 16]

Wpływ na LCP

Gdy użytkownik kliknie link do prerenderowanej strony, nawigacja jest praktycznie natychmiastowa. Strona została już w pełni załadowana i wyrenderowana w tle. Dla tej nawigacji TTFB, opóźnienie ładowania zasobu, czas ładowania zasobu i opóźnienie renderowania elementu są wszystkie efektywnie zredukowane do niemal zera z perspektywy użytkownika.[3, 1, 16]

Przykładowy przypadek użycia

Na stronie kategorii e-commerce, speculation rules mogą być użyte do prerenderowania stron szczegółów produktu dla kilku pierwszych pozycji na liście. Gdy użytkownik kliknie na jeden z tych produktów, strona pojawia się natychmiast, zapewniając płynne i wyjątkowo szybkie doświadczenie.

Synteza studium przypadku: od teorii do praktyki

Skuteczność tych strategii optymalizacji nie jest jedynie teoretyczna; jest potwierdzona danymi z rzeczywistych testów i scenariuszy.

• Przypadek 1: Transformacyjna moc preładowania: Eksperyment przeprowadzony przez DebugBear na stronie z wysokim opóźnieniem ładowania stanowi dramatyczny przykład. Obraz LCP był ukryty w łańcuchu żądań, powodując, że opóźnienie ładowania zasobu stanowiło oszałamiające 75% całkowitego czasu LCP. Wdrożenie pojedynczej wskazówki <link rel="preload">, aby obraz był wcześnie wykrywalny, zmniejszyło opóźnienie ładowania zasobu do zaledwie 2% czasu LCP.[17] Pokazuje to, jak prosta poprawka architektoniczna może rozwiązać ogromne wąskie gardło wydajnościowe.
• Przypadek 2: Rzeczywisty antywzorzec loading="lazy": Deweloper na Stack Overflow zgłosił desktopowe LCP z zagadkowym 1430ms opóźnieniem ładowania pomimo szybkiej sieci. Przyczynę wyśledzono do wtyczki optymalizacji obrazów, która nieprawidłowo stosowała lazy loading do obrazu LCP, zastępując jego atrybut src przezroczystym placeholderem SVG. Ostatecznym rozwiązaniem było wyłączenie tego zachowania dla elementu LCP, umożliwiając jego natychmiastowe odkrycie i ładowanie.[18] Ilustruje to, jak narzędzia zewnętrzne mogą nieumyślnie wprowadzać poważne opóźnienia ładowania.
• Przypadek 3: Zwiększenie wydajności dzięki fetchpriority: Studium przypadku Google Flights dostarcza wyraźnych dowodów na wpływ jawnej priorytetyzacji. Przez proste dodanie fetchpriority="high" do obrazu tła LCP strony, wynik LCP poprawił się o 700ms, spadając z 2,6 sekundy do 1,9 sekundy.[8] Pokazuje to, że nawet gdy zasób jest wykrywalny, sygnalizowanie jego wysokiego znaczenia dla przeglądarki jest krytycznym krokiem w wygrywaniu wyścigu o przepustowość sieci.

Inspekcja sieci w Chrome DevTools: Użyj skrótu Ctrl + Shift + I, aby otworzyć narzędzia deweloperskie Chrome, a następnie wybierz kartę „Network" i przeładuj stronę. Spójrz na sekwencję ładowania. Twój zasób LCP powinien być jednym z pierwszych elementów w kolejce pobierania. Jeśli pozostaje w tyle za innymi elementami, istnieje problem z opóźnieniem ładowania zasobu. Poniżej znajduje się przykład strony, na której opóźnienie ładowania zasobu nie zostało zoptymalizowane.

Wykorzystaj dane Real User Monitoring (RUM): Narzędzia Real User Monitoring często rejestrują dane atrybucji LCP. Dzięki RUM możesz wizualizować podział podfaz LCP (w czasie lub według strony), uzyskując wyraźny obraz opóźnienia ładowania dla elementów LCP na całej stronie lub na poszczególnych stronach. Poniższy przykład pokazuje globalny podział LCP wraz z odpowiadającym opóźnieniem ładowania.

Jak poprawić opóźnienie ładowania

Opóźnienie ładowania zasobu występuje, gdy kolejność pobierania i czas zasobów nie są optymalne. Istnieją zasadniczo dwa proste sposoby, aby to naprawić: nadanie priorytetu zasobowi LCP lub obniżenie priorytetu zasobów niebędących LCP. Przyjrzyjmy się kilku typowym wzorcom:

Wskazówka LCP: Zrozum Preload Scanner: Nowoczesne przeglądarki używają mechanizmu zwanego preload scanner, który szybko skanuje HTML i kolejkuje zasoby do pobrania. Jeśli zasób nie może zostać dodany do kolejki przez preload scanner, będzie musiał czekać na wolniejszy parser DOM, co spowoduje opóźnienia. Zapewnienie, że Twoje zasoby LCP są wykrywalne przez preload scanner, może znacząco zmniejszyć opóźnienie ładowania.

1. Zoptymalizuj strukturę HTML

Przeglądarka (lub preload scanner) przetwarza HTML od góry do dołu, kolejkując zasoby w kolejności, w jakiej się pojawiają. Oznacza to, że im wyżej zasób LCP pojawia się w HTML, tym szybciej zostanie dodany do kolejki. Aby to zoptymalizować, usuń lub odrocz niepotrzebne zasoby z górnej części HTML:

• Lazy-load nieważnych lub ukrytych obrazów: Czasami obrazy (na przykład flagi dla wersji językowych strony lub obrazy w menu) znajdują się na samej górze HTML Twojej strony. Te obrazy nie są nawet w przybliżeniu tak ważne jak element LCP. Stosując lazy loading do tych obrazów, są one pomijane przez preload scanner i dodawane do kolejki nieco później w procesie ładowania.
  
• Przenieś nieważne skrypty na dół strony: Przenieś skrypty, które są absolutnie nieważne dla początkowego ładowania, na dół strony, aby zapobiec opóźnianiu krytycznych zasobów. Na przykład widget czatu. Nikt w historii internetu nigdy nie potrzebował czatować przed wyświetleniem strony!

2. Unikaj obrazów tła.

Obrazy tła są niewidoczne dla preload scannera, co oznacza, że zawsze będą kolejkowane przez znacznie wolniejszy parser DOM. Aby uniknąć tego opóźnienia, użyj zwykłego tagu <img>, w połączeniu z właściwością CSS object-fit: cover, aby naśladować wygląd obrazu tła. W ten sposób preload scanner może natychmiast wykryć i dodać obraz do kolejki.

3. Użyj Fetch Priority

Dodaj atrybut fetchpriority="high" do elementu LCP, aby zasugerować przeglądarce, że powinna nadać priorytet temu zasobowi od samego początku. Normalnie obrazy ładują się z domyślnym niskim lub średnim priorytetem. Podczas fazy układu przeglądarka podnosi priorytet widocznych elementów na wysoki. Ustawiając fetchpriority="high" pobieranie rozpoczyna się natychmiast z wysokim priorytetem, zapewniając szybsze LCP. 

Fetchpriority jest zwykle mniej inwazyjne (i mniej skuteczne) niż preładowanie, ponieważ ustawia względny priorytet elementu (w tym przypadku obraz jest relatywnie ważniejszy niż inne obrazy), ale nie czyni go ważniejszym niż na przykład arkusze stylów lub nieblokujące skrypty.

<img src="hero-image.jpg" alt="Hero Image" fetchpriority="high">

4. Zaimplementuj preładowanie

Preładowanie zmienia kolejność, w jakiej preload scanner kolejkuje pliki. Umieść tag <link rel="preload"> w head strony aby poinstruować przeglądarkę, aby pobrała krytyczne zasoby, takie jak obraz LCP, jak najwcześniej. Preload można użyć do preładowania zasobów, które są przywoływane później w HTML (i dlatego są kolejkowane później) lub nawet do preładowania zasobów, które nie są jeszcze przywoływane w HTML (jak w przypadku niektórych sliderów). Dla maksymalnej skuteczności zaleca się umieszczanie preload po arkuszach stylów i przed skryptami w head strony. 

<link rel="preload" as="image" href="hero-image.jpg">

5. Zoptymalizuj style

Arkusze stylów są normalnie kolejkowane przed zasobem LCP i jest to uzasadnione. Bez arkuszy stylów przeglądarka nie będzie wiedziała, jak strona będzie wyglądać i nie może rozpocząć fazy renderowania. Jednak nadmierny rozmiar CSS i nadmierna liczba arkuszy stylów będą konkurować z zasobem LCP o wczesną przepustowość.

6. Zaimplementuj efektywne lazy-loading

Atrybut loading może być mieczem obosiecznym. Użyj loading="eager" (lub po prostu pomiń atrybut, ponieważ "eager" jest domyślnym ustawieniem przeglądarki) dla zasobu LCP, stosując loading="lazy" dla obrazów poza ekranem.

• Ładuj element LCP natychmiastowo (eager): Jeśli element LCP ma lazy loading, nie zostanie kolejkowany przez preload scanner i załaduje się znacznie później, negatywnie wpływając na wydajność.
• Lazy-load obrazów w viewporcie: Dla obrazów w widocznym viewporcie, które nie są zasobami LCP, użyj loading="lazy", aby kolejkować je do pobrania nieco później. Zmniejsza to konkurencję o przepustowość z zasobem LCP.
• Unikaj lazy loading obrazów poza ekranem: Obrazy, które nie znajdują się w widocznym viewporcie, w ogóle nie spowodują pobrania, całkowicie eliminując konkurencję o przepustowość.

7. Buforowanie przeglądarki

Buforowanie przeglądarki pozwala pominąć żądania sieciowe dla zasobów, które zostały już zapisane lokalnie na urządzeniu użytkownika. Chociaż nie przyspieszy pierwszego wyświetlenia strony, poprawi czasy ładowania dla kolejnych odsłon i powracających odwiedzających. Oto jak buforowanie przeglądarki pomaga z opóźnieniem ładowania zasobu:

• Buforuj konkurujące zasoby: Chociaż buforowanie samego zasobu LCP jest świetną strategią, buforowanie przeglądarki poprawia opóźnienia ładowania zasobu LCP poprzez przechowywanie zasobów sieciowych, które mogą konkurować z zasobem LCP lub go opóźniać, takich jak skrypty, arkusze stylów i obrazy.
  
• Zmniejsz obciążenie serwera: Buforowanie zmniejsza liczbę żądań wysyłanych do serwera, co może poprawić wydajność innych zasobów poprzez zwolnienie przepustowości i zmniejszenie obciążenia CPU serwera.
  

8. Użyj speculation rules

Speculation Rules umożliwia przeglądarkom prefetch lub prerender stron internetowych na podstawie przewidywanej nawigacji użytkownika. Prefetch skutecznie eliminuje podfazę Time to First Byte LCP i nie ma wpływu na opóźnienie ładowania zasobu. Prerender renderuje następną stronę w ukrytej karcie i pobiera wszystkie zasoby strony.  Eliminuje to wszystkie opóźnienia ładowania dla elementu LCP, jak pokazano w tym przykładowym podziale LCP prerenderowanej strony.

9. Unikaj renderowania po stronie klienta