Optimizarea imaginilor în Next.js: checklist complet pentru Core Web Vitals

Pe scurt: imaginile sunt cel mai frecvent motiv pentru care un site pică la Core Web Vitals — mai des decât JavaScript-ul. Un LCP prost pe mobil e aproape mereu o imagine prea mare servită într-un format greșit, fără dimensiuni. Checklist-ul de mai jos rezolvă cazurile care contează.

Am văzut asta de multe ori în audituri: un site cu LCP de zeci de secunde pe mobil, unde vinovatul era o singură imagine de 8MB. Case study aici. Alteori JavaScript-ul era problema — dar de câte ori nu era JS, erau imaginile.

1. Format modern: WebP sau AVIF

PNG-urile și JPEG-urile mari sunt istorie. WebP e cu 25-35% mai mic la aceeași calitate; AVIF și mai mult. În Next.js, componentul next/image le servește automat dacă ai optimizarea activă. Dacă folosești unoptimized: true (cazuri de hosting fără optimizare la runtime), pre-generezi variantele WebP la build și le servești prin <picture>.

Regula: nicio imagine raster de megabytes în producție. Un hero care ocupă tot ecranul are nevoie de câțiva zeci de KB în WebP, nu de 2-8MB în PNG.

2. Dimensiuni responsive (srcset + sizes)

Un telefon nu are nevoie de imaginea de 1920px. Servește variante multiple și lasă browserul să aleagă:

<picture>
  <source media="(max-width: 640px)" srcset="/img/mobile.webp" type="image/webp" />
  <source media="(max-width: 960px)" srcset="/img/tablet.webp" type="image/webp" />
  <source srcset="/img/desktop.webp" type="image/webp" />
  <img src="/img/fallback.jpg" alt="..." />
</picture>

Cu next/image, sizes face același lucru automat. Fără asta, mobilul descarcă imaginea de desktop și saturează banda — exact ce distruge LCP.

3. priority pe imaginea LCP

Imaginea above-the-fold (hero, cover de articol) trebuie încărcată imediat, nu lazy. În next/image folosești priority; cu <img> raw, loading="eager" + fetchpriority="high". Restul imaginilor rămân loading="lazy".

Greșeala clasică: hero-ul e lazy-loaded ca toate celelalte → browserul îl amână → LCP mare. Marchează explicit imaginea principală ca prioritară.

4. width și height pentru CLS

Fără dimensiuni explicite, browserul nu știe cât loc să rezerve pentru imagine, deci conținutul sare când se încarcă — Cumulative Layout Shift. Pune mereu width și height (sau aspect-ratio în CSS). next/image le impune; cu <img> raw le adaugi manual.

5. Lazy loading sub fold

Tot ce e sub prima vizibilă se încarcă leneș: loading="lazy". Astfel banda se duce întâi pe ce vede utilizatorul, nu pe imaginea de la finalul paginii. next/image face lazy by default (mai puțin când pui priority).

6. Compresie și decoding

• Comprimă la calitate 75-85 — diferența vizuală e neglijabilă, câștigul de dimensiune real.
• decoding="async" pe imagini ca să nu blocheze randarea.
• Servește prin CDN cu cache headers lungi — imaginile nu se schimbă des.

Cum măsori

Nu ghici — măsoară pe mobil real în PageSpeed Insights. În waterfall vezi imediat resursa cu cel mai mare download time. Dacă e o imagine, ai găsit vinovatul. Verifică LCP (sub 2.5s), CLS (sub 0.1) și dimensiunea totală a imaginilor pe pagină. Rezultatele contradictorii — FCP bun dar LCP absurd — sunt aproape mereu o imagine grea care blochează.

Rezumat

Imaginile sunt pârghia numărul unu pentru CWV. Format modern (WebP/AVIF), dimensiuni responsive, priority pe LCP, width/height pentru CLS, lazy sub fold. Cinci reguli care rezolvă majoritatea problemelor de performanță pe care le vedem.

Facem asta în fiecare proiect — vezi cum am dus un site de la 74 la 97 pe mobil. Pentru monitoring continuu al Core Web Vitals după lansare, e parte din serviciul de mentenanță.