Core Web Vitals: cum atingi LCP sub 1.5s în producție
Largest Contentful Paint este metric-ul care, mai mult decât orice altul, decide percepția de viteză a unui site. În 2026, pragul de 2500 ms este insuficient pentru SEO competitiv în nișe aglomerate. Site-urile care câștigă constant primele poziții au LCP în zona 1100-1400 ms pe utilizatorii reali, nu doar pe Lighthouse-ul rulat în birou.
Atingerea acestui prag nu este magie. Este rezultatul unei discipline tehnice care combină alegerea inteligentă a stack-ului, optimizarea imaginilor, fonturilor și CSS-ului critic, controlul agresiv asupra tag-urilor terțe și monitorizarea continuă pe utilizatori reali. Echipa Blackbone aplică acest set de practici pe site-uri client de la lansare și menține rezultatele lună de lună.
Articolul de față prezintă, în ordine, fiecare zonă de optimizare cu pași concreți, capcane reale și instrumente folosite efectiv în proiectele noastre. Tot ce găsești mai jos a fost validat în producție pe site-uri cu trafic real.
01Diagnoza corectă a elementului LCP
Înainte să optimizezi, trebuie să știi exact ce element produce LCP-ul pe paginile importante. În cele mai multe cazuri este o imagine hero, dar poate fi și un titlu mare sau un bloc de text. Identificarea greșită duce la optimizări care nu mișcă acul. Folosește Chrome DevTools în tab-ul Performance Insights și Lighthouse cu device emulation realist pentru a marca elementul.
Apoi, măsoară pe utilizatori reali, nu doar în lab. Google Search Console raportează Core Web Vitals pe 28 de zile pe baza datelor CrUX, iar Web Vitals JS poate trimite metrici către un endpoint propriu pentru analize granulare. Diferența între scor Lighthouse și scor real este adesea mai mare decât se așteaptă echipele.
În Blackbone, primul deliverable al unui audit Core Web Vitals este o tabelă cu rutele top trafic și elementul LCP pe fiecare, plus baseline-ul curent. Doar după ce avem datele acestea pornim optimizările, ordonate după impact estimat.
- →Chrome DevTools Performance Insights pentru identificare LCP.
- →Web Vitals JS pentru date RUM trimise către endpoint propriu.
- →Google Search Console pentru date agregate pe 28 de zile.
- →WebPageTest pentru profile mobile realiste.
02next/image și AVIF: imagini fără compromis
Imaginea care produce LCP este cel mai des locul unde poți câștiga 500-1000 ms cu efort minim. next/image rezolvă majoritatea problemelor automat: generează variante multiple, servește formatul potrivit per browser, lazy-load implicit pe imaginile non-critice și preîncărcare automată pentru cele marcate cu priority. Combinat cu AVIF, fișierele sunt cu 40-60% mai mici decât JPEG la calitate vizuală echivalentă.
Capcana cea mai frecventă este să lipsești atributul sizes sau să îl pui generic. Fără sizes corect, browserul descarcă imagini mai mari decât este nevoie, ceea ce inflează inutil byte-urile și încetinește LCP-ul. Pentru fiecare imagine importantă, definim explicit dimensiunile per breakpoint, nu lăsăm la valori implicite.
Pentru hero, sunt obligatorii: priority pe componentă, preconnect către CDN-ul de imagini, fetchpriority high în HTML și dimensiuni intrinseci corecte pentru a evita layout shift. Doar combinația acestor patru elemente produce LCP-uri sub 1500 ms pe imagini mari pe device-uri reale.
AVIF + JPEG fallback, sizes explicit, priority, preconnect CDN, fetchpriority high, dimensiuni intrinseci corecte. Toate șase, niciodată parțial.
03Font loading inteligent
Fonturile sunt sursa numărul doi de probleme LCP, în special când elementul LCP este text. next/font cu Google Fonts sau cu fișiere self-hosted gestionează automat preload, font-display swap și subset-uri, ceea ce reduce timpul până la primul text vizibil. Pentru titluri mari, font-display swap evită FOIT și permite afișarea instantanee cu fontul de sistem.
Fallback metric matching este o adăugire valoroasă. Definind un font fallback cu metrici similari fontului final, layout shift-ul la swap dispare aproape complet. Combinația next/font cu adjustFontFallback face asta automat pentru majoritatea fonturilor populare, fără cod manual.
În Blackbone evităm încărcarea mai multor familii de fonturi sau a prea multor variante de weight. Două familii maxime, trei weight-uri per familie. Orice mai mult înseamnă byte-uri suplimentari fără beneficiu vizual real.
04Critical CSS și defer-uri inteligente
CSS-ul blocant este unul dintre cele mai subtile motive pentru LCP-uri lente. Browserul nu randează nimic până nu primește CSS-ul critic. Strategia este să inline-ezi CSS-ul necesar pentru above-the-fold și să încarci restul async, cu media swap sau cu preload + onload swap.
Pe stack Next.js modern, CSS modules și Tailwind cu purge eficient produc bundle-uri foarte mici per rută. Asta face critical CSS inlining mai ușor și mai eficient. Pentru site-uri cu shared CSS mare, recomandăm o trecere de audit care identifică regulile efectiv folosite above-the-fold.
JavaScript-ul blocant este o variantă a aceleiași probleme. Defer și async pe orice script terț, niciodată script-uri inline mari în head, niciodată JS sincron pentru analytics sau marketing. Aceste reguli simple economisesc sute de ms pe LCP fără să sacrifice funcționalitate.
- →Critical CSS inlined pentru above-the-fold.
- →Restul CSS-ului încărcat async cu preload + swap.
- →Tailwind purge configurat corect, fără reguli moarte.
- →Niciun JS sincron în head, fără excepție.
05Taxul invizibil al tag-urilor terțe
Cea mai subevaluată sursă de LCP-uri proaste sunt tag-urile terțe: pixeli de marketing, chat widgets, hotjar, analytics multiple, A/B testing tools. Fiecare dintre acestea pare neînsemnat individual, dar cumulat blochează main thread-ul timp de secunde și amână LCP-ul cu sute de milisecunde.
Politica pe care o aplicăm în Blackbone este strictă: orice tag terț trebuie justificat, încărcat după evenimentul de LCP atins și, dacă este posibil, mutat server-side. Pentru analytics, Vercel Analytics sau soluțiile self-hosted cu Plausible elimină majoritatea overhead-ului. Pentru chat, încărcare doar la interacțiunea utilizatorului, nu la pageload.
Audit-ul trimestrial al tag-urilor terțe este o disciplină pe care o impunem clienților. Adesea descoperim 4-5 tag-uri instalate de echipe anterioare, care nu mai sunt folosite, dar continuă să încarce 200-300 KB de JavaScript și să degradeze LCP-ul. Curățarea lor este cel mai ieftin câștig de SEO posibil.
06Monitorizare continuă, nu doar audit punctual
Un audit punctual care produce LCP sub 1500 ms este excelent, dar fără monitorizare continuă, regresul este garantat în 30-60 de zile. Codul nou, conținut nou, integrări noi adaugă straturi care, necontrolate, deteriorează metricile. Strategia corectă este monitorizare RUM continuă plus lighthouse-CI în pipeline-ul de deploy.
În proiectele Blackbone, fiecare PR rulează Lighthouse-CI cu prag definit per rută. Dacă LCP-ul depășește bugetul, build-ul nu intră în main. Asta forțează disciplina la nivel de echipă: nu se merge mai departe cu un PR care strică performanța, indiferent cât de mult avansează feature-ul.
Pe partea de RUM, alegerea ține de cerințele de confidențialitate. Pentru clienți care vor totul self-hosted, GoatCounter sau Plausible. Pentru viteza implementării, Vercel Analytics. Indiferent de alegere, raportarea metricilor către cineva care urmărește săptămânal este obligatorie. Fără urmărire, datele nu produc acțiune.
Definește un buget pe fiecare metric Core Web Vitals și un buget pe bundle size per rută. Orice depășire blochează deploy-ul. Disciplină simplă, efecte mari.
Concluzii
LCP sub 1500 ms în producție nu este un truc, ci rezultatul unei discipline tehnice consecvente. Diagnoză corectă, imagini optimizate, fonturi inteligente, critical CSS, control strict asupra tag-urilor terțe și monitorizare continuă. Niciun pas singular nu produce magie, dar combinația lor produce site-uri care domină constant Core Web Vitals.
Pentru un audit complet de performanță și pentru implementare disciplinată care menține LCP-uri verzi pe termen lung, firma de IT Blackbone oferă echipe specializate în SEO tehnic și optimizare front-end. Scrie-ne URL-ul tău și revenim cu un raport detaliat plus un plan de acțiune cu impact estimat per fiecare optimizare propusă.
Core Web Vitals verzi, constant
Echipa Blackbone face audit, optimizare și monitorizare continuă a Core Web Vitals. LCP sub 1.5s nu mai este obiectiv, ci punct de plecare.
Discută cu Blackbone