Un LCP de 56 de secunde: cum pozele neoptimizate îți distrug scorul
PageSpeed mobil scotea 73 cu un LCP de 56 de secunde. Cauza nu era codul, ci ~20MB de poze raw. Cum am ajuns la 98 cu o singură optimizare de imagini.
Un număr absurd e mereu un indiciu. PageSpeed pe mobil scotea 73, cu un Largest Contentful Paint de 56 de secunde. Nimeni nu așteaptă 56 de secunde — deci ceva era clar rupt. Iată ce, și cum am ajuns la 98.
Diagnostic: nu codul, ci pozele
Reflexul e să cauți în JavaScript. Auditul a arătat altceva: ~20MB de imagini se descărcau pe homepage. Imaginile de proiect erau PNG-uri raw de până la 8MB fiecare, servite direct (prin background-image), fără redimensionare și fără format modern.
Pe desktop, cu rețea rapidă, nici nu se simțea (scor ~100). Pe slow-4G (cum testează PageSpeed mobilul), banda se satura complet → LCP-ul exploda la zeci de secunde. De aceea desktopul era perfect, iar mobilul catastrofal.
Fix: WebP responsive (8MB → 150KB)
Un script de optimizare generează versiuni WebP responsive (mobil / tablet / desktop) pentru fiecare imagine:
| Înainte (PNG raw) | După (WebP) | |
|---|---|---|
| joy-optic | 8.1 MB | 150 KB desktop / 37 KB mobil |
| Total homepage | ~20 MB | ~0.5 MB |
De 50-220× mai mici. Componentele servesc dimensiunea potrivită contextului. Interesant: versiunile optimizate existau deja — doar nu erau folosite pe câteva pagini.
Rezultat (PageSpeed mobil)
73 → 90+ (până la 98), iar spike-ul de LCP a dispărut complet. Desktop 100. O singură cauză, un singur fix.
Lecțiile
- Imaginile sunt cel mai frecvent ucigaș de performanță — mai des decât JavaScript-ul.
- WebP/AVIF + dimensiuni responsive = obligatoriu. Niciodată PNG-uri raw de megabytes.
- Un LCP absurd (zeci de secunde) = aproape mereu o resursă uriașă care saturează banda pe mobil.
- Lab-ul e zgomotos — scorul oscila 88 → 98 între rulări; ia mediana.
Verificăm asta în Audit & fix SEO / AI-SEO — audit real, fix-uri direct în cod. Vezi și optimizare SEO.