NO_LCP: cum am dus un site cinematic de la Core Web Vitals picate la 91/100
Un site dark, animat, frumos — care pica testul de viteză cu „eroare". Povestea reală a vânătorii de performanță: misterul ecranului negru, pariul greșit, și scorul care a scăzut fix când reparam. Final: 91 mobil, 100 desktop.
Cel mai contraintuitiv lucru pe care l-am învățat optimizând un site frumos e ăsta: cu cât e mai cinematic, cu atât riscă mai mult să pice testul de viteză. Nu pentru că frumusețea e lentă — ci pentru că trucurile care o fac cinematică (fade-in-uri, ecrane de intrare, animații la scroll) sunt exact ce derutează motorul care măsoară performanța.
Site-ul din povestea asta e un editorial dark, contemplativ, cu o mandală care respiră și un intro care se dizolvă în „ploaia" de tipare. Arăta impecabil. Iar prima măsurătoare Google PageSpeed a dat, senin: Error! NO_LCP. Nu un scor mic. O eroare — motorul nu găsea niciun element „cel mai mare" pictat pe ecran.
Articolul ăsta e vânătoarea care a urmat. Cu tot suspansul real: un ecran negru misterios, un pariu greșit, și momentul în care scorul a scăzut fix când reparam. Final: 91 pe mobil, 100 pe desktop.
Misterul 1: ecranul negru
NO_LCP înseamnă că, în fereastra în care Lighthouse se uită la pagină, nu s-a pictat nimic „contentful" — doar negru. Ciudat, pentru un site care evident afișează un titlu uriaș.
Cauza, după săpat: tot conținutul pornea la opacity: 0 și apărea prin JavaScript, cu întârzieri de 2–3 secunde, peste un „overlay negru" de tranziție. Frumos pentru ochiul uman pe un laptop rapid. Dar pe un mobil throttled, JS-ul rula târziu, întârzierile se adunau, iar Lighthouse închidea trace-ul înainte să apară ceva. Rezultat: motorul vedea un dreptunghi negru și dădea din umeri.
Fixul n-a fost să scoatem animația — a fost s-o inversăm. În loc de „totul invizibil, apoi apare", am făcut un ecran de intrare pictat instant (titlul, randat pe server, vizibil din prima milisecundă), care ține o secundă și apoi face fade-out ca să lase loc animației. Elementul mare e acolo de la început → motorul îl vede → LCP se înregistrează. Fade-out-ul se întâmplă după ce măsurătoarea e deja făcută.
NO_LCP → LCP 1.1 secunde. 95 pe desktop. Prima victorie. Regula rămasă: un element care contează nu trebuie să aștepte JavaScript-ul ca să existe.
Misterul 2: pariul greșit
Al doilea site din ecosistem trecea desktop-ul lejer (98), dar pe mobil dădea 78, cu LCP de 5 secunde. Roșu.
Aici am făcut greșeala clasică: am presupus. „E clar mandala aia de 400KB din hero." Am optimizat-o. Am re-măsurat. LCP-ul… n-a mișcat deloc.
Lecția, plătită cu un deploy irosit: nu ghici elementul LCP — măsoară-l. Am scos din raportul Lighthouse exact ce element era „cel mai mare pictat" și ce-l întârzia. Și abia atunci s-a văzut adevărul: nu era un vinovat. Erau patru, stivuiți.
Cei patru vinovați (și de ce erau invizibili)
- Serveam aceeași imagine de 900px / 400KB pe TOATE ecranele — inclusiv pe un mobil unde se afișa la ~400px. Zero imagini responsive. Trimiteam de 2–3 ori mai mulți pixeli decât încăpeau.
- Formatul greșit. Framework-ul (Next.js) servea implicit doar WebP — nu AVIF, care comprimă un desen dens de 3–4 ori mai bine. Trebuia activat explicit. Nimeni nu-l activase.
- Un logo de 182KB pentru o iconiță de 18px. Un fișier de 1024×1024 pixeli, încărcat avid, în footer, care mânca banda exact când imaginea principală avea nevoie de ea.
- 320KB de fonturi — care încărcau un subset de caractere est-europene (ă, â, ș, ł…) pe un site 100% în engleză. Payload mort, pur și simplu.
Niciunul nu striga „eu sunt problema". Fiecare părea normal. Împreună, sufocau conexiunea mobilă și întârziau tot. Le-am rezolvat pe toate: imagini responsive per ecran, AVIF activat, logo-ul optimizat (182KB → 2KB), subsetul mort scos din fonturi. Payload-ul paginii a căzut de la 948KB la 424KB.
Momentul de panică: scorul care scade când repari
Și aici vine partea cu adrenalină. După toate fixurile, re-măsurăm, plini de speranță. Scorul… scade. De la 87 la 83. Iar „Speed Index" sărise la 13,8 secunde — de zece ori mai rău. Din lac în puț, aparent.
Genul de moment în care începi să te îndoiești de tot ce-ai făcut. Dar cifrele nu se legau: LCP-ul de fapt scăzuse (4.0 → 3.2s), imaginea era acum 32KB, pagina mai ușoară. Cum poate „viteza vizuală" să fie 14 secunde când totul e mai mic?
Răspunsul, după verificare directă: red herring de infrastructură. Varianta AVIF a imaginii era nouă — abia o generasem. Iar rețeaua de distribuție (CDN) o compune la primul request, on-demand, iar encoding-ul AVIF pe o imagine densă durează ~8 secunde. Fix acea rulare Lighthouse a nimerit prima generare și a contorizat cele 8 secunde ca lentoare. O taxă plătită o singură dată. Am dat un request de verificare: a doua oară, imaginea venea în 0,2 secunde. Caldă.
Re-rulare, cu varianta caldă: 91 pe mobil. Speed Index înapoi la 2,5 secunde. Panica fusese o iluzie de măsurare.
Ce rămâne, dincolo de scor
Un site nu se optimizează prin „mai puțină grafică". Se optimizează prin disciplină de măsurare și înțelegerea a ce plătește fiecare kilobyte:
- Măsoară, nu ghici. Un pariu prost pe elementul LCP = un deploy irosit. Raportul îți spune exact ce element și ce-l întârzie — citește-l înainte să repari.
- Cea mai ieftină imagine e cea pe care n-o trimiți la mărime întreagă. Responsive + formatul potrivit (AVIF) au tăiat 90% din greutate, fără să atingem un pixel din designul original.
- Cunoaște-ți default-urile. AVIF era oprit din config. Un flag de calitate era ignorat tăcut de framework. Lucrurile importante stăteau în setări nescrise.
- Greutatea moartă se ascunde — un subset de font pentru o limbă pe care n-o folosești, un logo de 1MB pentru 18 pixeli, o imagine de 900px pentru un ecran de 400. Niciunul nu strigă.
- O singură măsurătoare poate minți. Cold-start-ul unei resurse noi umflă un scor și te sperie degeaba. Verifică la cald înainte să tragi concluzii — sau să strici ceva ca să „repari".
Concluzie
Am pornit de la o eroare — un site frumos care nu putea fi măsurat — și am ajuns la 91 pe mobil, 100 pe desktop, cu pagina la mai puțin de jumătate din greutate. Fără să sacrificăm mandala care respiră, intro-ul cinematic sau întunericul contemplativ.
Performanța și frumusețea nu sunt în conflict. Doar cer să înțelegi ce măsoară motorul, cum îl derutează efectele, și unde se ascunde greutatea. Restul e răbdare, un raport citit cu atenție, și curajul să nu crezi prima cifră care te sperie.
Vezi și proiectele din spatele poveștii: The Cipher și Informational Pattern Design.
Din aceeași serie: Cum am tăiat 2 MB de payload invizibil de pe thecipher.is — aceeași bibliotecă, alt unghi: greutatea pe care pagina o trimitea fără s-o arate niciodată.
Întrebări frecvente
Ce înseamnă „NO_LCP" în PageSpeed? Că motorul nu a găsit niciun „Largest Contentful Paint" — niciun element mare pictat în fereastra de măsurare. Apare des pe site-uri unde conținutul pornește invizibil (opacity 0) și apare prin JavaScript cu întârziere: pe un mobil lent, nimic nu se pictează la timp. Soluția e să pictezi elementul principal instant (randat pe server), nu după JS.
De ce trecea desktop-ul dar pica mobilul? Pe desktop, rețeaua și procesorul sunt rapide — chiar și o pagină grea se încarcă instant. PageSpeed testează mobilul cu throttling (4G lent + CPU încetinit), unde fiecare kilobyte în plus și fiecare secundă de JavaScript contează. De aici diferența 100 desktop / 78 mobil pe același site.
De ce a scăzut scorul fix când optimizam? Un artefact de cold-cache. Varianta nouă (AVIF) a imaginii era generată de CDN on-demand la primul request — encoding-ul dura câteva secunde, iar acea rulare a contorizat taxa ca lentoare. La a doua rulare, cu imaginea deja în cache, scorul a sărit la valoarea reală. Lecția: verifică „la cald" înainte de concluzii.
Cât s-a redus greutatea paginii? De la 948KB la 424KB — sub jumătate. Cei mai mari câștigi: imagini responsive per ecran (nu 900px pe mobil), AVIF în loc de WebP (comprimă mult mai bine desenele dense), un logo optimizat de la 182KB la ~2KB, și scoaterea unui subset de font est-european inutil pe un site în engleză.
Se poate face un site frumos ȘI rapid? Da — cele două nu sunt în conflict. Am păstrat toate animațiile, mandala și intro-ul cinematic, și am ajuns la 91 mobil / 100 desktop. Cheia e să înțelegi ce măsoară motorul (elementul mare, pictat la timp), să servești fiecare imagine la mărimea și formatul potrivit, și să nu lași greutate moartă (fonturi, loguri, variante) să sufoce conexiunea.
Ai un site frumos care pică la viteză? Cere o ofertă — măsurăm întâi, apoi optimizăm, fără să atingem designul. Vezi și serviciile noastre.