Ce face de fapt lazy loading cu Largest Contentful Paint

Lazy loading este o decizie de planificare, nu o vrajă de viteză

Lazy loading este adesea descris ca o îmbunătățire de performanță, ceea ce este adevărat în același fel în care a nu împacheta o valiză înseamnă o reducere a greutății. Ajută deoarece browserul face mai puțină muncă la început.

Această distincție contează pentru Largest Contentful Paint, prescurtat de obicei LCP. LCP măsoară momentul în care cel mai mare element semnificativ din viewport este randat. Pe multe pagini, acel element este o imagine hero. Pe altele, este un titlu mare, o imagine poster, o fotografie de produs sau un bloc de conținut.

Lazy loading schimbă momentul în care sunt solicitate resursele. Nu face ca o imagine să se decodeze mai repede, ca un server să răspundă mai repede sau ca un font să fie randat mai devreme. Dacă aplici lazy loading lucrului greșit, mai ales elementului care devine LCP, îi spui browserului să aștepte înainte să preia exact lucrul pe care trebuie să îl afișeze pentru a trece Core Web Vitals.

De aceea lazy loading este atât suprautilizat, cât și insuficient înțeles.

Ce face browserul când aplici lazy loading unei imagini

Lazy loading nativ pentru imagini este adăugat de obicei așa:

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

Cu loading='lazy', browserului i se permite să amâne preluarea imaginii până când consideră că imaginea va fi probabil necesară. În practică, browserele folosesc distanța față de viewport, condițiile de rețea, dimensiunile imaginii și alte euristici. Regulile exacte sunt detalii de implementare și se pot schimba.

Cu loading='eager', sau fără atributul lazy în majoritatea cazurilor, browserul tratează imaginea ca parte a procesului normal de încărcare. Tot trebuie să prioritizeze între CSS, JavaScript, fonturi, imagini și alte cereri, dar imaginea poate fi descoperită imediat.

Asta înseamnă că lazy loading afectează în principal trei faze:

• Descoperire: când browserul observă resursa.
• Începerea cererii: când începe preluarea prin rețea.
• Momentul randării: când resursa poate fi în sfârșit decodată și pictată.

Pentru LCP, cea periculoasă este începerea cererii. Dacă cererea pentru imaginea LCP începe târziu, tot ce urmează se mută și el mai târziu.

Regula simplă: nu aplica niciodată lazy loading candidatului LCP

Dacă o imagine este vizibilă în viewport-ul inițial și este probabil să fie cel mai mare element contentful, nu îi aplica lazy loading.

Aceasta include:

• imagini hero
• fotografii principale de produs deasupra pliului inițial
• imagini mari de deschidere pentru articole
• imagini mari de tip fundal implementate ca <img>
• imagini poster video când posterul este elementul vizual principal

Browserul nu poate randa imaginea LCP până când aceasta nu a fost solicitată, transferată, decodată și pictată. Lazy loading introduce incertitudine înaintea primului pas. Chiar și o mică întârziere poate fi suficientă pentru a muta LCP din zona acceptabilă în zona slabă pe o conexiune mai lentă.

Un tipar comun de eșec arată așa:

1. Serverul trimite HTML.
2. Browserul parsează o imagine aflată deasupra pliului inițial.
3. Imaginea are loading='lazy'.
4. Browserul așteaptă deoarece euristica de lazy loading spune că poate.
5. CSS și JavaScript continuă să se încarce.
6. Cererea pentru imagine începe mai târziu decât ar trebui.
7. LCP întârzie, chiar dacă fișierul imaginii este optimizat rezonabil.

Acest lucru este frustrant deoarece pagina poate arăta ordonat într-un code review. Problema nu este doar dimensiunea fișierului. Este prioritatea.

Dacă citești rezultatele de laborator și încerci să îți dai seama dacă LCP este într-adevăr problema, ghidul nostru despre citirea unui raport Lighthouse fără panică este intenționat practic: separă datele din teren, indiciile de laborator și remediile înainte să începi să modifici codul. (Notă: dacă rutarea ta este sensibilă la majuscule și minuscule, folosește URL-ul exact din CMS.)

Corecție: folosește URL-ul intern real

URL-ul corect al articolului Wux este Cum să citești un raport Lighthouse fără panică. Ideea rămâne valabilă: identifică elementul LCP înainte să schimbi comportamentul de încărcare.

Când lazy loading poate îmbunătăți LCP

Lazy loading poate îmbunătăți LCP indirect atunci când ține resursele necritice departe de drumul browserului.

Imaginează-ți o pagină de produs cu o imagine hero a produsului în partea de sus și un carusel cu douăsprezece imagini de recomandări sub pliul inițial. Dacă toate cele treisprezece imagini se încarcă eager, browserul poate consuma lățime de bandă și sloturi de conexiune pentru imagini pe care utilizatorul nu le poate vedea încă. Pe o rețea limitată, acestea pot concura cu imaginea hero, CSS sau fișierele de font.

Lazy loading pentru imaginile caruselului aflat sub pliul inițial poate ajuta imaginea LCP să se încarce mai devreme, deoarece mai puține cereri necritice concurează în timpul încărcării inițiale a paginii.

Acesta este cazul legitim de performanță pentru lazy loading:

• încarcă eager candidatul LCP deasupra pliului inițial
• aplică lazy loading imaginilor aflate sub viewport-ul inițial
• evită scripturile grele care injectează târziu imagini importante
• păstrează dimensiunile imaginilor în HTML pentru a evita deplasările de layout

Lazy loading nu este în sine o optimizare LCP. Este un instrument de prioritizare a resurselor. Ajută atunci când protejează calea critică.

Tiparul mai bun pentru imaginile LCP

Pentru o imagine LCP deasupra pliului inițial, obiectivul este ca browserul să o descopere devreme, să o solicite devreme și să o randeze fără instabilitate de layout.

O bază solidă arată așa:

<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'
>

Părțile importante nu sunt decorative:

• loading='eager' previne întârzierea produsă de lazy loading.
• fetchpriority='high' îi spune browserului că această imagine contează.
• width și height rezervă spațiu și reduc deplasarea layoutului.
• srcset și sizes previn descărcările supradimensionate.
• Un format modern poate reduce timpul de transfer când este folosit cu atenție.

Dacă încă livrezi un singur JPEG mare către orice ecran, formatul imaginii și dimensionarea responsive pot conta mai mult decât atributul de lazy loading. Pentru un arbore decizional practic, vezi când AVIF depășește WebP și când nu.

Imaginile de fundal au nevoie de atenție suplimentară

Imaginile de fundal CSS nu sunt descoperite la fel de devreme ca imaginile HTML normale. Browserul trebuie să preia și să parseze CSS înainte să afle despre ele. Dacă elementul tău LCP este o imagine de fundal CSS, ai făcut deja descoperirea mai dificilă.

Asta nu înseamnă că imaginile de fundal sunt interzise. Înseamnă că ar trebui să fii deliberat.

Pentru imagini decorative, fundalurile CSS sunt în regulă. Pentru imagini hero semnificative, un element <img> sau <picture> este de obicei mai bun, deoarece este vizibil pentru parserul HTML, acceptă text alt și funcționează bine cu atributele pentru imagini responsive.

Dacă trebuie să folosești un fundal CSS pentru o imagine LCP, ia în considerare preîncărcarea lui:

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

Nici preload nu este o baghetă magică. Preîncărcarea prea multor imagini creează aceeași problemă de prioritate într-un alt costum. Folosește-l pentru singura imagine care contează cu adevărat, nu pentru fiecare imagine din design system.

Lazy loading prin JavaScript înrăutățește adesea lucrurile

Înainte ca lazy loading nativ să fie acceptat pe scară largă, multe site-uri foloseau biblioteci JavaScript care înlocuiau data-src cu src după încărcarea paginii sau după declanșarea unui intersection observer. Unele încă o fac.

Acest lucru poate fi rezonabil pentru pagini lungi de articol sau galerii bogate în imagini. Este o alegere slabă pentru conținutul deasupra pliului inițial.

Scannerul de preload al browserului este rapid, dar nu poate solicita o imagine al cărei URL este ascuns într-un atribut personalizat până când JavaScript rulează. Dacă imaginea ta hero începe ca data-src='hero.jpg', ai întârziat descoperirea în spatele descărcării scriptului, parsării, execuției și hidratării frameworkului.

Este un compromis prost pentru LCP. Pune URL-urile imaginilor critice în HTML real. Lasă browserul să își facă treaba.

LCP nu este întotdeauna o problemă de imagine

Pe unele pagini, elementul LCP este text. În acest caz, lazy loading pentru imagini poate avea un efect direct redus. Gâtul de sticlă poate fi CSS care blochează randarea, un răspuns lent al serverului, randare pe client sau fonturi web.

Fonturile merită menționate deoarece sunt o cauză ascunsă frecventă a randării întârziate a textului. Un titlu mare poate deveni LCP, iar comportamentul de încărcare a fonturilor poate întârzia sau modifica momentul în care acel titlu este pictat. Dacă munca la imagini nu mișcă metrica, inspectează direct elementul LCP în loc să presupui. Articolul nostru despre fonturi web ca avantaj de performanță acoperă remediile plictisitoare care funcționează adesea: mai puține greutăți, formate moderne, fallbackuri rezonabile.

Cum să testezi modificările de lazy loading fără să te păcălești

Nu testa uitându-te la pagină pe Wi-Fi-ul de la birou. Trebuie să vezi momentul cererilor.

Folosește acest workflow:

1. Deschide Chrome DevTools și înregistrează un Performance trace.
2. Activează limitarea rețelei, cum ar fi Fast 4G sau Slow 4G.
3. Reîncarcă pagina cu cache-ul dezactivat.
4. Găsește marcajul LCP.
5. Identifică elementul LCP.
6. În panoul Network, verifică momentul în care acea resursă a început să se încarce.

Dacă resursa LCP începe târziu, întreabă de ce:

• A fost încărcată lazy?
• A fost injectată de JavaScript?
• A fost ascunsă în CSS?
• A fost deprioritizată în spatele altor imagini?
• Serverul a răspuns lent?

Apoi fă o singură modificare și retestează. Munca de performanță devine dezordonată când echipele schimbă formatul imaginii, lazy loading, preloading, bundle-urile JavaScript și setările CDN în aceeași lansare. Poți îmbunătăți pagina, dar nu vei ști care schimbare a contat.

Datele din teren contează și ele. Instrumentele de laborator sunt utile pentru diagnostic, dar LCP variază în funcție de dispozitiv, rețea, viewport, starea cache-ului și geografie. Folosește monitorizare pe utilizatori reali sau date Chrome User Experience Report când poți.

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

💡 Încercați asta: Păstrați imaginea LCP mică și încărcată cu prioritate trecând-o prin Image Compressor, astfel încât să se afișeze rapid fără a necesita lazy loading.

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

O politică practică pentru majoritatea site-urilor

Pentru majoritatea site-urilor de marketing, paginilor ecommerce, site-urilor de documentație și paginilor de publisheri, această politică este suficientă:

• Imagine principală deasupra pliului inițial: încarcă eager, ia în considerare prioritate ridicată la preluare.
• Imagini de conținut sub pliul inițial: aplică lazy loading.
• Iconițe și resurse UI mici: de obicei nu merită analizate individual.
• Hero ca fundal CSS: reconsideră ca imagine HTML sau preîncarcă atent.
• Imagine hero injectată prin JavaScript: repară arhitectura de randare dacă este posibil.
• Carusele: încarcă eager doar primul slide vizibil; aplică lazy loading restului.

Există cazuri de margine. Euristicile browserelor se îmbunătățesc. Frameworkurile adaugă componente automate pentru imagini. Unele platforme evită acum lazy loading pentru imaginile detectate lângă viewport. Totuși, principiul nu se schimbă: resursele critice ar trebui să fie timpurii și evidente; resursele necritice ar trebui să aștepte.

Lazy loading este valoros când exprimă această distincție. Este dăunător când ascunde cel mai important conținut de browser până după ce pagina a început deja să piardă cursa LCP.