DEV Community

Cover image for 16% din site-uri aplică lazy loading pe imaginea LCP. Apoi se întreabă de ce le scade traficul.
FLASH SHIP
FLASH SHIP

Posted on

16% din site-uri aplică lazy loading pe imaginea LCP. Apoi se întreabă de ce le scade traficul.

Lazy loading e best practice. Întârzie descărcarea imaginilor care nu sunt vizibile pe ecran, reducând load time-ul inițial. Fiecare ghid de performanță web îl recomandă. Și totuși, implementat greșit, poate distruge exact metrica pe care încerci s-o optimizezi.

Capcana: lazy loading pe hero image

Conform unui studiu PPC Land, 16% din site-urile mobile aplică lazy loading pe imaginea LCP (de obicei hero image). Ce se întâmplă: browser-ul întâlnește loading="lazy", decide să nu descarce imaginea imediat, așteaptă execuția JavaScript-ului care verifică vizibilitatea. Imaginea care ar trebui să fie prima descărcată devine una dintre ultimele.

Rezultat concret: un site a implementat lazy loading pe toate imaginile, inclusiv hero. Scorul PageSpeed a crescut (testul se face pe o pagină goală, fără scroll). Dar LCP-ul real, măsurat pe utilizatori Chrome prin CrUX, s-a degradat de la 1.8 secunde la 4.2 secunde. Consecința: -20% trafic organic în două luni.

PageSpeed a arătat verde. Google a văzut roșu.

A doua greșeală invizibilă: imagini fără dimensiuni

Asta e și mai subtilă. O imagine fără width și height specificate în HTML pare normală la prima vedere. Se încarcă, se afișează, arată bine. Dar în timpul încărcării, browser-ul nu știe cât spațiu să-i aloce.

Conform web.dev și DebugBear, o singură imagine hero fără dimensiuni poate genera un CLS de 0.2-0.5. Pragul Google pentru CLS „bun" e ≤0.1. Deci o singură imagine nespecificată poate dubla sau cvintupla CLS-ul acceptabil.

CLS nu e doar o metrică de laborator. E factor de ranking din 2021. Și e exact motivul pentru care utilizatorii „pierd" paragraful pe care-l citeau: imaginea se încarcă, împinge textul în jos, experiența e deteriorată.

Soluția corectă: framework care impune regulile

Ambele probleme (lazy loading pe hero + lipsa dimensiunilor) au aceeași cauză: sistemul nu diferențiază între imagini. Aplică aceleași reguli pe toate. next/image din Next.js rezolvă asta nativ: lazy loading default pe toate imaginile, dar cu priority pe hero (descărcare imediată). Dimensiuni obligatorii; dacă nu specifici width/height, codul nu compilează. Zero CLS din imagini, automat.

Ce mai analizăm în articolul complet

Lazy loading și CLS sunt doar două din cele 5 greșeli pe care le documentăm. Articolul complet acoperă:

  • 40% din dimensiunea paginii sunt imagini și 73% din elementele LCP sunt imagini (date HTTP Archive 2025/2024)
  • 80% din site-uri servesc JPEG/PNG în 2026, când AVIF e cu 80-90% mai mic (date W3Techs)
  • WordPress necesită 3-4 plugin-uri pentru ce next/image face nativ, zero config (analiză Perfmatters)
  • +63% conversie din optimizarea imaginilor, +33% din imagini profesionale vs. amatoricești (studii CXL și AutoPhoto.ai)

Imaginile de pe site-ul tău: De ce se încarcă în 3 secunde și cum ar trebui să se încarce în 0,3

8 surse, date 2024-2026, comparație directă plugin approach vs. native.


Publicat de FLASH SHIP S.R.L., agenție digitală din Sibiu, România. Construim sisteme de creștere organică pe Next.js.

Top comments (0)