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

Ai un site cu 20-30 de imagini? Probabil 15 dintre ele sunt servite greșit. Nu complet greșit; nu se văd cu capul în jos sau ceva de genul. Dar sunt prea mari, în format vechi, fără dimensiuni specificate, fără responsive, și fără niciun hint pentru browser despre care dintre ele contează. Rezultatul: site-ul se încarcă în 2-4 secunde în loc de sub o secundă.

Nu e o părere. HTTP Archive Web Almanac 2025 arată că imaginile reprezintă aproximativ 40% din dimensiunea totală a unei pagini web. Pagina mediană pe desktop are 2.6 MB; pe mobil, 2.3 MB. Iar conform datelor de performanță HTTP Archive 2024, imaginile sunt elementul LCP pe 73,3% din paginile mobile și 83,3% din cele desktop.

Cu alte cuvinte: dacă site-ul tău se încarcă greu, cel mai probabil o imagine e de vină. Iar Google măsoară exact asta când decide cât de sus te clasează.

Cât costă o imagine lentă

LCP (Largest Contentful Paint) e metrica pe care Google o folosește pentru a determina cât de repede vede utilizatorul conținutul principal al paginii. Pragul de 'bun' e sub 2.5 secunde, iar conform acelorași date HTTP Archive, doar 59% din paginile mobile ating acest prag. Restul de 41% pierd poziții în căutare, pierd vizitatori, și pierd bani.

Și aici nu vorbim de un site abandonat din 2018. Vorbim de site-uri active, cu trafic, care pur și simplu nu au optimizat imaginile corect. Sau au crezut că le-au optimizat.

5 greșeli pe care le face aproape fiecare site

1. JPEG și PNG în loc de WebP sau AVIF

Conform W3Techs (mai 2026), WebP e folosit pe doar 20,3% din site-uri, iar AVIF pe 1,3%. Restul de aproape 80% servesc JPEG și PNG, formate din anii '90 și 2000. Diferența de dimensiune: AVIF e cu până la 50% mai mic decât WebP, și cu 80-90% mai mic decât JPEG la aceeași calitate vizuală. Adică o imagine hero de 800 KB în JPEG ar avea sub 100 KB în AVIF.

2. Imagini de 3000 px pentru un spațiu de 800 px

Un telefon cu ecran de 400 px CSS descarcă o imagine de 3000 px și o redimensionează la afișare. Browser-ul face efortul, consumă banda, memoria, bateria. Soluția e srcset: servești variante de imagine la dimensiuni diferite, iar browser-ul o alege pe cea potrivită. Dar conform datelor Web Almanac, majoritatea site-urilor nu folosesc srcset deloc, iar cele care îl folosesc adesea au breakpoint-urile greșite.

3. Zero dimensiuni specificate = CLS dezastru

CLS (Cumulative Layout Shift) măsoară cât de mult 'sare' layout-ul paginii în timp ce se încarcă. Când o imagine nu are width și height specificate în HTML, browser-ul nu știe cât spațiu să-i aloce. Imaginea se încarcă, împinge textul în jos, utilizatorul pierde paragraful pe care-l citea. Conform web.dev și DebugBear, o singură imagine hero fără dimensiuni poate genera un CLS de 0,2-0,5, când pragul Google pentru 'bun' e ≤0,1.

4. Lazy loading pe TOATE imaginile, inclusiv hero

Lazy loading e o practică bună: nu descarci imaginile până nu sunt vizibile pe ecran. Problema: dacă aplici lazy loading pe imaginea hero (prima imagine mare din pagină), browser-ul nu începe descărcarea până nu execută JavaScript-ul care verifică vizibilitatea. Rezultat: imaginea care ar trebui să fie prima încărcată devine ultima.

Conform unui studiu PPC Land, 16% din site-urile mobile aplică lazy loading pe imaginea LCP. Un caz concret: lazy loading pe hero image a mutat LCP de la 1,8 secunde la 4,2 secunde. Consecința: o scădere de 20% a traficului organic, chiar dacă scorul PageSpeed a rămas bun.

5. Upload direct din telefon, fără nicio procesare

O poză de pe un telefon modern are 4000-8000 px lățime și 3-12 MB. Se uploadează direct în CMS, se pune pe pagină, gata. Nimeni nu o redimensionează, nimeni nu o comprimă, nimeni nu o convertește. Dacă ai 10 poze din telefon pe o pagină, ai 30-120 MB de imagini de descărcat. Pe 4G, asta înseamnă 15-60 de secunde de încărcare doar pentru imagini.

Capcana lazy loading-ului: cum 'optimizezi' și pierzi 20% din trafic

Greșeala #4 de mai sus merită detaliată, pentru că e cea mai perfidă. Lazy loading e recomandat peste tot, e considerat best practice, și e implementat default de multe CMS-uri și plugin-uri. Problema nu e lazy loading-ul în sine, ci aplicarea lui orbește pe toate imaginile.

Cum funcționează: browser-ul întâlnește loading='lazy' pe o imagine și zice 'nu o descarc până nu e aproape de viewport'. Perfect pentru imaginea de pe rândul 15 al paginii. Dezastruos pentru imaginea hero care ocupă tot ecranul la încărcare.

Studiul PPC Land documentează cazul în detaliu: un site a implementat lazy loading pe toate imaginile, inclusiv hero. Scorul PageSpeed a crescut. Traficul organic a scăzut cu 20% în două luni. De ce? Pentru că LCP-ul real (măsurat pe utilizatorii din Chrome, nu în laborator) s-a degradat masiv. Google a observat.

Soluția corectă: imaginea hero primește fetchpriority='high' și loading='eager' (sau pur și simplu nu primește lazy loading). Browser-ul o descarcă imediat, cu prioritate maximă. Restul imaginilor primesc lazy loading normal. Dar asta necesită ca sistemul să știe care imagine e hero și care nu. Majority CMS-urilor nu fac asta automat.

'Dar eu am instalat ShortPixel / Imagify!'

Dacă folosești WordPress, probabil ai auzit de ShortPixel, Imagify, EWWW Image Optimizer, sau Smush. Sunt plugin-uri de compresie imagini, și fac o treabă decentă la ce promit: comprimă JPEG-urile existente. Dar optimizarea imaginilor înseamnă mult mai mult decât compresia.

Conform unei analize Perfmatters, avertismentul 'Properly size images' din PageSpeed e unul dintre cele mai frecvente pe site-urile WordPress. De ce? Pentru că plugin-urile de compresie nu rezolvă dimensiunea: comprimi un JPEG de 3000 px, dar tot îl servești la 3000 px pe un ecran de 400 px. Ai un JPEG comprimat dar tot prea mare.

• Compresie (ShortPixel, Imagify): reduce calitatea/dimensiunea fișierului, dar tot servești JPEG când browser-ul suportă AVIF
• Conversie format (unele plugin-uri premium): convertesc în WebP, dar nu negociază automat cu browser-ul și rareori suportă AVIF
• Lazy loading (LiteSpeed Cache, WP Rocket): aplică lazy loading pe toate imaginile, inclusiv pe hero, fără distincție
• Srcset (WordPress nativ din 4.4): generează câteva variante, dar breakpoint-urile sunt fixe și rareori potrivite pentru layout-ul real
• Dimensiuni (manual): trebuie să specifici width/height manual în fiecare bloc de imagine; dacă uiți, CLS

Fiecare aspect al optimizării necesită un plugin separat, configurare separată, și mentenanță separată. Și fiecare plugin adaugă propriul JavaScript și CSS, ceea ce ironically face site-ul mai lent. E ca și cum ai pune un plasture pe fiecare rană în loc să previi rănile de la început.

WebP și AVIF: formatele pe care 80% din site-uri le ignoră

W3Techs raportează (mai 2026) că WebP e folosit pe 20,3% din site-uri, iar AVIF pe doar 1,3%. Asta înseamnă că aproape 4 din 5 site-uri servesc formate vechi de 30 de ani. JPEG a fost creat în 1992. PNG în 1996. WebP în 2010. AVIF în 2019.

Diferența practică: un banner hero de 1920x1080 px, calitate vizuală identică:

Conform unei analize Dev.to, JPEG reprezintă încă 32,4% din request-urile de imagini, iar PNG 28,4%. Adopția AVIF a crescut cu 386% între 2022 și 2024, dar de la o bază minusculă. Concluzia: piața se mișcă, dar încet. Cine adoptă acum are un avantaj competitiv real.

Ce face next/image și de ce nu ai nevoie de plugin-uri

Componenta next/image din Next.js rezolvă fiecare dintre cele 5 probleme de mai sus, nativ, fără configurare suplimentară. Conform analizei DebugBear și ghidului Strapi, reduce payload-ul total de imagini cu 60-80% față de abordarea clasică.

Cum funcționează concret: specifici sursa, dimensiunile și atributul priority pe imaginea hero, iar framework-ul se ocupă de restul. Primești automat conversie în AVIF (sau WebP ca fallback) pe server, srcset cu variante de la 640 px la 3840 px, lazy loading pe toate imaginile mai puțin cele cu priority, dimensiuni fixe în HTML deci zero CLS, blur placeholder opțional în timpul încărcării, și cache pe edge CDN.

Impactul real: conversii, nu doar milisecunde

Viteza imaginilor nu e o metrică abstractă pentru developeri. E bani. Conform unei analize CXL, 90% din consumatori spun că imaginile sunt factorul cel mai important în decizia de cumpărare online. 67% evaluează imaginile înainte de a citi descrierea produsului.

Un studiu AutoPhoto.ai arată că optimizarea imaginilor de produs a generat o creștere de 63% a conversiilor și că imaginile profesionale convertesc cu 33% mai bine decât cele amatoricești. Dar ce înseamnă 'optimizare' aici? Nu doar calitate vizuală; înseamnă și viteză de încărcare. O imagine de calitate excelentă care se încarcă în 4 secunde pierde față de una decentă care apare instant.

Lanțul logic e simplu: imagini lente → LCP slab → poziție mai slabă în Google → mai puțin trafic → mai puține conversii. Și invers: imagini rapide și bine servite → LCP sub 2,5s → ranking mai bun → mai mult trafic organic → mai multe vânzări. Totul începe de la cum sunt servite imaginile.

Cum rezolvăm noi: nativ, nu cu cârpeli

Fiecare site pe care îl construim folosește next/image din prima zi. Nu instalăm plugin-uri de compresie după lansare, nu configurăm CDN-uri separate, nu sperăm că srcset-ul default e suficient. Optimizarea imaginilor e parte din arhitectura de bază, nu un afterthought.

Concret, asta înseamnă: LCP sub 2,5 secunde chiar și pe conexiuni mobile lente, CLS zero din imagini pentru că dimensiunile sunt obligatorii, format AVIF sau WebP servit automat fiecărui browser, srcset adaptat la layout-ul real nu la breakpoint-uri generice, și hero image cu priority maximă pentru încărcare instantanee.

• Zero plugin-uri de imagini: totul e nativ în framework
• Zero configurare manuală: formatul, dimensiunile, lazy loading-ul sunt automate
• Zero mentenanță: nu actualizezi plugin-uri, nu verifici compatibilități, nu rezolvi conflicte
• Performanță constantă: nu depinde de câte plugin-uri mai adaugi pe parcurs

Am detaliat întreg sistemul nostru de dezvoltare și rezultatele obținute dacă vrei să vezi cum se leagă totul.