Co lazy loading naprawdę robi z Largest Contentful Paint

Lazy loading to decyzja o harmonogramie, nie zaklęcie przyspieszające

Lazy loading często opisuje się jako poprawę wydajności, co jest prawdą w takim samym sensie, w jakim niespakowanie walizki zmniejsza jej wagę. Pomaga, ponieważ przeglądarka ma mniej pracy na starcie.

To rozróżnienie ma znaczenie dla Largest Contentful Paint, zwykle skracanego do LCP. LCP mierzy moment wyrenderowania największego istotnego elementu w widocznym obszarze strony. Na wielu stronach tym elementem jest obraz hero. Na innych jest to duży nagłówek, obraz plakatu, zdjęcie produktu albo blok treści.

Lazy loading zmienia moment żądania zasobów. Nie sprawia, że obraz dekoduje się szybciej, serwer odpowiada szybciej ani font renderuje się wcześniej. Jeśli zastosujesz lazy loading do niewłaściwego elementu, zwłaszcza tego, który staje się LCP, mówisz przeglądarce, aby poczekała z pobraniem dokładnie tego, co musi wyświetlić, by przejść Core Web Vitals.

Dlatego lazy loading jest jednocześnie nadużywany i zbyt słabo rozumiany.

Co robi przeglądarka, gdy stosujesz lazy loading obrazu

Natywny lazy loading obrazów zwykle dodaje się tak:

<img src='hero.jpg' loading='lazy' alt='...'>

Przy loading='lazy' przeglądarka może odroczyć pobranie obrazu do chwili, gdy uzna, że obraz prawdopodobnie będzie potrzebny. W praktyce przeglądarki używają odległości od viewportu, warunków sieciowych, wymiarów obrazu i innych heurystyk. Dokładne reguły są szczegółami implementacyjnymi i mogą się zmieniać.

Przy loading='eager', albo w większości przypadków bez atrybutu lazy, przeglądarka traktuje obraz jako część normalnego procesu ładowania. Nadal musi ustalać priorytety między CSS, JavaScript, fontami, obrazami i innymi żądaniami, ale obraz jest wykrywalny od razu.

Oznacza to, że lazy loading wpływa głównie na trzy fazy:

• Wykrycie: kiedy przeglądarka zauważa zasób.
• Start żądania: kiedy zaczyna się pobieranie przez sieć.
• Moment renderowania: kiedy zasób może wreszcie zostać zdekodowany i namalowany.

Dla LCP niebezpieczny jest start żądania. Jeśli żądanie obrazu LCP zacznie się późno, wszystko po nim również przesuwa się w czasie.

Prosta zasada: nigdy nie stosuj lazy loading do kandydata na LCP

Jeśli obraz jest widoczny w początkowym viewporcie i prawdopodobnie jest największym elementem contentful, nie stosuj do niego lazy loading.

Dotyczy to między innymi:

• obrazów hero
• głównych zdjęć produktów powyżej pierwszego ekranu
• dużych obrazów prowadzących w artykułach
• dużych obrazów podobnych do tła, zaimplementowanych jako <img>
• obrazów poster dla wideo, gdy poster jest głównym elementem wizualnym

Przeglądarka nie może wyrenderować obrazu LCP, dopóki nie zostanie on zażądany, przesłany, zdekodowany i namalowany. Lazy loading wprowadza niepewność przed pierwszym krokiem. Nawet niewielkie opóźnienie może wystarczyć, aby na wolniejszym połączeniu przesunąć LCP z akceptowalnego do słabego.

Typowy wzorzec awarii wygląda tak:

1. Serwer wysyła HTML.
2. Przeglądarka parsuje obraz powyżej pierwszego ekranu.
3. Obraz ma loading='lazy'.
4. Przeglądarka czeka, ponieważ heurystyka lazy loading uznaje, że może.
5. CSS i JavaScript nadal się ładują.
6. Żądanie obrazu zaczyna się później, niż powinno.
7. LCP jest spóźnione, mimo że sam plik obrazu jest rozsądnie zoptymalizowany.

To frustrujące, ponieważ w code review strona może wyglądać schludnie. Problemem nie jest wyłącznie rozmiar pliku. Problemem jest priorytet.

Jeśli czytasz wyniki laboratoryjne i próbujesz ustalić, czy LCP naprawdę jest problemem, nasz przewodnik po czytaniu raportu Lighthouse bez paniki jest celowo praktyczny: zanim zaczniesz zmieniać kod, oddziel dane terenowe, wskazówki z laboratoriów i poprawki. (Uwaga: jeśli routing jest wrażliwy na wielkość liter, użyj dokładnego URL-a z CMS-a.)

Korekta: użyj właściwego wewnętrznego URL-a

Poprawny URL artykułu Wux to Jak czytać raport Lighthouse bez paniki. Sedno pozostaje bez zmian: zidentyfikuj element LCP, zanim zmienisz zachowanie ładowania.

Kiedy lazy loading może poprawić LCP

Lazy loading może poprawić LCP pośrednio, gdy usuwa z drogi przeglądarki zasoby niekrytyczne.

Wyobraź sobie stronę produktu z obrazem hero produktu na górze i karuzelą dwunastu obrazów rekomendacji poniżej pierwszego ekranu. Jeśli wszystkie trzynaście obrazów ładuje się eager, przeglądarka może zużywać przepustowość i sloty połączeń na obrazy, których użytkownik jeszcze nie widzi. W ograniczonej sieci może to konkurować z obrazem hero, CSS lub plikami fontów.

Lazy loading obrazów karuzeli poniżej pierwszego ekranu może pomóc obrazowi LCP załadować się wcześniej, ponieważ podczas początkowego ładowania strony konkuruje mniej niekrytycznych żądań.

To jest uzasadniony przypadek wydajnościowy dla lazy loading:

• ładuj eager kandydata na LCP powyżej pierwszego ekranu
• stosuj lazy loading obrazów poniżej początkowego viewportu
• unikaj ciężkich skryptów, które późno wstrzykują ważne obrazy
• utrzymuj wymiary obrazów w HTML, aby uniknąć przesunięć układu

Lazy loading sam w sobie nie jest optymalizacją LCP. To narzędzie do priorytetyzacji zasobów. Pomaga, gdy chroni ścieżkę krytyczną.

Lepszy wzorzec dla obrazów LCP

W przypadku obrazu LCP powyżej pierwszego ekranu celem jest sprawienie, aby przeglądarka wcześnie go wykryła, wcześnie zażądała i wyrenderowała bez niestabilności układu.

Solidna baza wygląda tak:

<img
  src='/images/product-hero.avif'
  srcset='/images/product-hero-800.avif 800w, /images/product-hero-1400.avif 1400w'
  sizes='(max-width: 768px) 100vw, 720px'
  width='1400'
  height='900'
  loading='eager'
  fetchpriority='high'
  decoding='async'
  alt='Black hiking backpack with roll-top closure'
>

Ważne części nie są dekoracyjne:

• loading='eager' zapobiega opóźnieniu lazy loading.
• fetchpriority='high' mówi przeglądarce, że ten obraz ma znaczenie.
• width i height rezerwują miejsce i ograniczają przesunięcia układu.
• srcset i sizes zapobiegają pobieraniu zbyt dużych plików.
• Nowoczesny format może skrócić czas transferu, jeśli jest użyty rozsądnie.

Jeśli nadal serwujesz jeden duży JPEG na każdy ekran, format obrazu i responsywne rozmiarowanie mogą mieć większe znaczenie niż atrybut lazy-loading. Praktyczne drzewo decyzyjne znajdziesz w artykule kiedy AVIF wygrywa z WebP, a kiedy nie.

Obrazy tła wymagają dodatkowej ostrożności

Obrazy tła CSS nie są wykrywane tak wcześnie jak zwykłe obrazy HTML. Przeglądarka musi pobrać i sparsować CSS, zanim się o nich dowie. Jeśli elementem LCP jest obraz tła CSS, już utrudniasz jego wykrycie.

Nie znaczy to, że obrazy tła są zakazane. Oznacza to, że należy używać ich świadomie.

Dla obrazów dekoracyjnych tła CSS są w porządku. Dla znaczącej grafiki hero element <img> albo <picture> zwykle jest lepszy, ponieważ jest widoczny dla parsera HTML, obsługuje tekst alternatywny i dobrze współpracuje z atrybutami obrazów responsywnych.

Jeśli musisz użyć tła CSS dla obrazu LCP, rozważ jego preload:

<link rel='preload' as='image' href='/images/hero.avif'>

Preload również nie jest magiczną różdżką. Preload zbyt wielu obrazów tworzy ten sam problem priorytetów w innym przebraniu. Użyj go dla jednego obrazu, który naprawdę ma znaczenie, nie dla każdego obrazu w design systemie.

Lazy loading w JavaScript często pogarsza sytuację

Zanim natywny lazy loading był szeroko wspierany, wiele stron używało bibliotek JavaScript, które po załadowaniu strony albo po uruchomieniu intersection observer podmieniały data-src na src. Niektóre nadal to robią.

Może to być rozsądne dla długich stron artykułów albo galerii z dużą liczbą obrazów. To słaby wybór dla treści powyżej pierwszego ekranu.

Skaner preload przeglądarki jest szybki, ale nie może zażądać obrazu, którego URL jest ukryty w niestandardowym atrybucie, dopóki nie uruchomi się JavaScript. Jeśli obraz hero zaczyna jako data-src='hero.jpg', opóźniasz wykrycie o pobranie skryptu, parsowanie, wykonanie i hydratację frameworka.

To zły kompromis dla LCP. Umieszczaj URL-e krytycznych obrazów w prawdziwym HTML. Pozwól przeglądarce wykonać jej pracę.

LCP nie zawsze jest problemem obrazu

Na niektórych stronach elementem LCP jest tekst. Wtedy lazy loading obrazów może mieć niewielki bezpośredni wpływ. Wąskim gardłem może być CSS blokujący renderowanie, wolna odpowiedź serwera, renderowanie po stronie klienta albo fonty webowe.

Fonty warto wyróżnić, ponieważ często są ukrytą przyczyną późnego renderowania tekstu. Duży nagłówek może stać się LCP, a zachowanie ładowania fontów może opóźnić lub zmienić moment jego namalowania. Jeśli praca nad obrazami nie przesuwa metryki, sprawdź bezpośrednio element LCP, zamiast zakładać. Nasz artykuł o fontach webowych jako zysku wydajnościowym omawia nudne poprawki, które często działają: mniej grubości, nowoczesne formaty, rozsądne fallbacki.

Jak testować zmiany lazy loading, nie oszukując samego siebie

Nie testuj, wpatrując się w stronę na biurowym Wi‑Fi. Musisz zobaczyć momenty żądań.

Użyj takiego workflow:

1. Otwórz Chrome DevTools i nagraj ślad Performance.
2. Włącz ograniczanie sieci, na przykład Fast 4G albo Slow 4G.
3. Przeładuj stronę z wyłączoną pamięcią podręczną.
4. Znajdź znacznik LCP.
5. Zidentyfikuj element LCP.
6. W panelu Network sprawdź, kiedy ten zasób zaczął się ładować.

Jeśli zasób LCP zaczyna się późno, zapytaj dlaczego:

• Czy zastosowano do niego lazy loading?
• Czy został wstrzyknięty przez JavaScript?
• Czy był ukryty w CSS?
• Czy został zdepriorytetyzowany za innymi obrazami?
• Czy serwer wolno odpowiadał?

Następnie wprowadź jedną zmianę i przetestuj ponownie. Praca nad wydajnością robi się chaotyczna, gdy zespoły zmieniają format obrazu, lazy loading, preloading, paczki JavaScript i ustawienia CDN w tym samym wdrożeniu. Możesz poprawić stronę, ale nie będziesz wiedzieć, która zmiana miała znaczenie.

Dane terenowe też są ważne. Narzędzia laboratoryjne są przydatne do diagnozy, ale LCP różni się w zależności od urządzenia, sieci, viewportu, stanu cache i geografii. Korzystaj z monitoringu realnych użytkowników albo danych Chrome User Experience Report, kiedy możesz.

<!-- tool-cta:start -->

💡 Wypróbuj to: Utrzymuj obraz LCP mały i ładowany priorytetowo, przepuszczając go przez Image Compressor, aby szybko się renderował bez potrzeby lazy loadingu.

<!-- tool-cta:end -->

Praktyczna polityka dla większości stron

Dla większości stron marketingowych, ecommerce, dokumentacji i wydawców taka polityka wystarczy:

• Główny obraz powyżej pierwszego ekranu: ładuj eager, rozważ wysoki priorytet pobierania.
• Obrazy treści poniżej pierwszego ekranu: stosuj lazy loading.
• Ikony i drobne zasoby UI: zwykle nie warto rozważać ich pojedynczo.
• CSS background hero: rozważ ponownie obraz HTML albo ostrożny preload.
• Obraz hero wstrzykiwany przez JavaScript: jeśli to możliwe, napraw architekturę renderowania.
• Karuzele: ładuj eager tylko pierwszy widoczny slajd; resztę ładuj lazy.

Istnieją przypadki brzegowe. Heurystyki przeglądarek się poprawiają. Frameworki dodają automatyczne komponenty obrazów. Niektóre platformy unikają już lazy loading obrazów wykrytych blisko viewportu. Mimo to zasada się nie zmienia: zasoby krytyczne powinny być wczesne i oczywiste; zasoby niekrytyczne powinny poczekać.

Lazy loading jest wartościowy, gdy wyraża to rozróżnienie. Jest szkodliwy, gdy ukrywa przed przeglądarką najważniejszą treść aż do momentu, gdy strona zaczęła już przegrywać wyścig o LCP.