Core Web Vitals in 2026: cum diagnostichezi problemele de LCP, INP si CLS

Core Web Vitals sunt usor de citit ca trei scoruri si mult mai greu de diagnosticat corect. O pagina poate avea LCP slab din cauza serverului, INP slab din cauza unui task JavaScript lung si CLS slab din cauza unei imagini fara spatiu rezervat. Daca tratezi toate cele trei probleme ca pe o simpla nevoie de „viteza mai buna”, risti sa optimizezi lucrurile gresite.

In 2026, setul Core Web Vitals folosit de Google ramane format din LCP, INP si CLS. Google recomanda valori bune de cel mult 2,5 secunde pentru LCP, cel mult 200 ms pentru INP si cel mult 0,1 pentru CLS, evaluate la percentila 75 a experientelor reale, separat pentru mobil si desktop.

Core Web Vitals masoara trei probleme diferite

Google descrie Core Web Vitals ca un set de metrici pentru experienta reala a utilizatorilor privind incarcarea, responsivitatea si stabilitatea vizuala. Cele trei metrici actuale sunt:

Valorile dintre pragul bun si cel slab intra in zona „needs improvement”. Google recomanda evaluarea la percentila 75 a vizitelor. Cu alte cuvinte, nu este suficient ca un test facut de pe un laptop performant sa fie rapid; majoritatea experientelor reale trebuie sa se incadreze in pragurile bune.

Nu exista un singur „scor Core Web Vitals” care sa explice cauza unei probleme. Fiecare metrica are alta logica si necesita alta investigatie.

INP, nu FID

INP a inlocuit FID ca metrica Core Web Vital in martie 2024. Spre deosebire de FID, care analiza in principal intarzierea primei interactiuni, INP urmareste interactiunile pe durata vizitei si raporteaza o valoare care reflecta responsivitatea generala a paginii.

Datele reale si laboratorul raspund la intrebari diferite

Una dintre cele mai frecvente confuzii apare cand PageSpeed Insights afiseaza doua realitati aparent contradictorii: date reale slabe, dar un test Lighthouse bun, sau invers.

Aceste rezultate nu se exclud. Ele masoara contexte diferite.

Field data: ce au experimentat utilizatorii reali

Datele de teren provin din Chrome UX Report, cunoscut ca CrUX, si reflecta experiente reale ale utilizatorilor Chrome eligibili. Ele includ varietatea de telefoane, conexiuni, locatii, stari ale cache-ului si comportamente reale care nu pot fi reproduse complet printr-un singur test.

PageSpeed Insights poate afisa aceste date pentru URL si, in anumite situatii, pentru origin. Search Console foloseste de asemenea date Core Web Vitals provenite din experiente reale si grupeaza URL-urile cu comportament similar.

Lab data: o reproducere controlata

Lighthouse ruleaza un test sintetic intr-un mediu controlat. Este foarte util pentru a identifica resurse care blocheaza randarea, JavaScript costisitor, imagini mari, probleme de caching si alte oportunitati tehnice.

Dar un test Lighthouse nu poate reproduce toate interactiunile unei vizite reale. De exemplu, INP este in mod natural o metrica de teren deoarece are nevoie de interactiuni reale pe durata vizitei. Lighthouse foloseste alte audituri si metrici de laborator pentru a indica potentiale probleme de responsivitate.

De ce rezultatele pot fi foarte diferite

• utilizatorii reali pot avea telefoane mai lente;
• conexiunile pot avea latenta mai mare;
• vizitatorii pot interactiona cu componente pe care testul automat nu le foloseste;
• cache-ul poate schimba incarcarea;
• scripturile externe pot avea timpi variabili;
• continutul dinamic poate aparea diferit intre sesiuni;
• datele CrUX reprezinta o perioada, nu doar momentul testului curent.

Diagnosticul corect foloseste datele reale pentru a stabili daca exista o problema si laboratorul pentru a o reproduce si investiga.

LCP: afla unde se pierde timpul pana apare continutul principal

Largest Contentful Paint masoara timpul pana cand cel mai mare element eligibil din viewport este randat. De multe ori este imaginea hero, fotografia unui produs sau un bloc mare de text.

web.dev recomanda analizarea LCP ca o succesiune de componente, nu ca o singura cifra. Practic, timpul total poate fi influentat de raspunsul serverului, momentul in care browserul descopera resursa, durata descarcarii si intarzierea pana la randare.

1. Identifica elementul LCP real

Nu presupune ca imaginea hero este automat elementul LCP. Foloseste DevTools, PageSpeed Insights sau instrumentele de performance pentru a vedea ce element este raportat efectiv.

Pe desktop poate fi un titlu mare, iar pe mobil o imagine complet diferita. Daca template-ul este responsive, diagnosticul trebuie facut separat.

2. Verifica TTFB si inceputul incarcarii

LCP include si intarzierile dinainte ca browserul sa inceapa efectiv sa primeasca si sa randaze continutul. Un backend lent, redirecturile suplimentare sau latenta conexiunii pot consuma deja o parte importanta din bugetul de 2,5 secunde.

Daca documentul HTML ajunge tarziu, optimizarea unei imagini de la 180 KB la 150 KB poate avea un impact mult mai mic decat repararea raspunsului serverului.

3. Verifica momentul in care browserul descopera resursa LCP

O imagine poate fi relativ mica si totusi sa produca LCP slab daca browserul o descopera tarziu. Cauzele pot include:

• imagine introdusa prin JavaScript dupa incarcarea initiala;
• background CSS descoperit tarziu;
• prioritate mica a resursei;
• prea multe resurse concurente;
• lazy loading aplicat gresit imaginii LCP.

Imaginea aflata imediat in viewport si folosita drept LCP nu ar trebui tratata mecanic ca orice imagine de sub fold.

4. Verifica durata efectiva a descarcarii

Daca imaginea LCP are dimensiuni mult mai mari decat cele necesare pe ecran, browserul descarca date care nu imbunatatesc vizibil experienta. Formatele potrivite, compresia, dimensiunile responsive si infrastructura de livrare pot reduce aceasta componenta.

5. Verifica intarzierea dintre descarcare si randare

Uneori resursa este deja disponibila, dar browserul nu o poate picta imediat. CSS-ul, JavaScript-ul, fonturile sau alte operatiuni pe main thread pot amana randarea.

Aceasta situatie este importanta deoarece arata de ce „imaginea este optimizata” nu inseamna automat ca LCP este optim.

Exemplu: homepage cu imagine hero mare

Sa presupunem ca PageSpeed indica imaginea hero drept LCP. Investigatia corecta nu incepe cu schimbarea formatului, ci cu cronologia:

1. cat dureaza pana ajunge HTML-ul;
2. cand descopera browserul imaginea;
3. cat dureaza transferul imaginii;
4. cat trece intre finalizarea descarcarii si afisare.

Daca imaginea incepe sa fie descarcata abia dupa executarea unui script, problema principala este descoperirea tarzie, nu neaparat dimensiunea fisierului.

INP: pagina poate fi incarcata si totusi sa raspunda greu

Interaction to Next Paint masoara latenta interactiunilor precum click, tap si input de la tastatura pe durata vizitei. In majoritatea cazurilor, valoarea INP corespunde celei mai lente interactiuni observate, cu o tratare a outlierilor pentru paginile cu foarte multe interactiuni.

Aceasta metrica schimba perspectiva asupra performantei: utilizatorul poate vedea pagina rapid, dar meniul, filtrele sau butonul „Adauga in cos” pot raspunde greu dupa cateva secunde.

O interactiune lenta are mai multe componente

Pentru diagnostic, latenta unei interactiuni poate fi privita in trei parti:

• input delay: cat asteapta evenimentul pana poate incepe executia callback-ului;
• processing duration: timpul consumat efectiv de callback-uri;
• presentation delay: timpul pana cand browserul poate afisa urmatorul frame.

Daca nu stii care dintre aceste zone este lenta, „optimizeaza JavaScript” este prea vag pentru a fi un plan tehnic.

1. Cauta task-uri lungi pe main thread

Daca browserul executa un task JavaScript lung exact cand utilizatorul interactioneaza, evenimentul trebuie sa astepte. Cauza poate fi cod propriu sau cod third-party: analytics, chat, A/B testing, reclame, tag manager sau diverse widget-uri.

2. Analizeaza handler-ul interactiunii

Un click pe un filtru poate declansa simultan filtrare, actualizare DOM, recalculare de preturi, analytics si randarea unei liste mari. Chiar daca fiecare operatie pare rezonabila separat, executarea lor sincron poate produce o interactiune lenta.

3. Verifica munca de randare dupa JavaScript

INP nu se opreste cand callback-ul JavaScript se termina. Browserul trebuie sa poata calcula stiluri, layout si paint pentru a prezenta feedbackul urmator. Un DOM mare sau modificari extinse ale layout-ului pot creste presentation delay.

Exemplu: filtrul unui magazin online

Utilizatorul selecteaza un brand. Interfata pare blocata 700 ms, apoi apar produsele. Investigatia poate arata:

• 200 ms asteptare pentru ca main thread-ul era ocupat;
• 300 ms executie JavaScript pentru filtrare si manipulare DOM;
• 200 ms recalculare de stil si randare.

Optimizarea trebuie sa tina cont de componenta dominanta. Mutarea unei singure functii nu rezolva neaparat problema daca randarea listei continua sa fie costisitoare.

Testeaza interactiunile care conteaza pentru utilizator

Nu verifica doar meniul. Pentru un magazin online merita testate cautarea, filtrele, selectarea variantelor, adaugarea in cos si checkout-ul. Pentru o aplicatie web: tabele, modaluri, formulare, cautari, dashboard-uri si orice actiune folosita frecvent.

Articolul despre problemele tehnice si UX din checkout explica de ce o interactiune lenta poate deveni greu de diferentiat de o eroare functionala.

CLS: cauta elementele care se muta dupa ce utilizatorul le-a vazut

Cumulative Layout Shift masoara instabilitatea vizuala. Spre deosebire de LCP si INP, CLS nu este exprimat in secunde. Este un scor calculat pe baza deplasarilor neasteptate ale elementelor.

Un CLS slab apare atunci cand continutul vizibil isi schimba pozitia fara ca utilizatorul sa se astepte la asta. Exemplele clasice sunt imaginea care apare si impinge textul, bannerul injectat deasupra continutului sau fontul care modifica dimensiunile textului dupa incarcare.

1. Imagini fara spatiu rezervat

Daca browserul nu cunoaste raportul de aspect al unei imagini pana cand aceasta se descarca, continutul poate fi impins ulterior. Declararea dimensiunilor sau rezervarea corecta a spatiului permite browserului sa calculeze layout-ul dinainte.

2. Reclame, embed-uri si iframe-uri

Componentele externe cu inaltime necunoscuta pot crea salturi mari. Pentru zone cu dimensiuni previzibile merita rezervat spatiu. Pentru continut variabil trebuie proiectat un container care minimizeaza rearanjarile.

3. Bannere si continut dinamic inserat deasupra

Un banner de promotie, cookie, instalare aplicatie sau notificare aparut deasupra continutului poate muta intreaga pagina. Uneori solutia nu este sa incarci componenta mai repede, ci sa ii rezervi loc sau sa alegi o prezentare care nu muta continutul deja afisat.

4. Fonturile web

Un font de fallback poate avea alte dimensiuni decat fontul final. Cand fontul web se incarca, liniile se pot rearanja, iar elementele de sub text se pot deplasa. Strategia de incarcare si alegerea fallback-urilor compatibile pot reduce efectul.

De ce CLS din laborator poate arata bine, iar field data nu

Unele schimbari de layout apar dupa interactiuni, dupa incarcarea reclamelor sau mult mai tarziu in sesiune. Un test sintetic scurt poate sa nu ajunga in acele situatii. De aceea, pentru CLS sunt importante atat field data, cat si reproducerea scenariilor reale.

PageSpeed Insights si Search Console nu trebuie citite ca acelasi raport

PageSpeed Insights este util pentru investigarea unei pagini si poate combina date reale CrUX cu un test Lighthouse. Search Console este mai potrivit pentru monitorizarea la nivel de site si pentru identificarea grupurilor de URL-uri cu probleme similare.

PageSpeed Insights: porneste de la sectiunea cu utilizatori reali

Daca URL-ul are suficiente date CrUX, sectiunea despre experienta utilizatorilor reali este prima pe care merita sa o interpretezi pentru Core Web Vitals. Testul de laborator de mai jos este util pentru investigarea cauzelor tehnice.

Nu transforma scorul Performance 0-100 in obiectivul proiectului. Acesta este un scor Lighthouse calculat din mai multe metrici de laborator si nu este identic cu evaluarea Core Web Vitals din field data.

Search Console: cauta tipare intre grupuri de pagini

Raportul Core Web Vitals poate evidentia grupuri de URL-uri cu performanta similara. Daca toate paginile de produs au LCP slab, este probabil sa existe o cauza comuna in template, imagine hero, backend sau resurse.

Daca doar cateva URL-uri au problema, investigatia poate indica imagini neobisnuit de mari, componente speciale sau continut diferit.

Modificarile nu apar instantaneu in field data

Datele reale reprezinta o perioada de experiente, nu un benchmark facut in secunda in care ai publicat modificarea. Din acest motiv, o reparatie poate fi confirmata imediat in laborator, dar efectul complet in datele de teren necesita timp si suficiente vizite noi.

Nu optimiza metricile in ordinea in care apar in raport

Prioritizarea eficienta pleaca de la impact, amploare si cauza comuna.

1. Cauta probleme de template: o singura reparatie poate imbunatati sute de pagini.
2. Verifica mobil versus desktop: problema poate exista predominant pe telefoane.
3. Leaga metrica de comportament: un INP slab pe checkout poate avea prioritate mai mare decat o diferenta minora pe o pagina secundara.
4. Ataca componenta dominanta: nu comprima imagini la nesfarsit daca problema LCP este TTFB.
5. Retesteaza dupa modificari: o optimizare pentru LCP poate introduce CLS daca este implementata gresit.

Pentru probleme recurente sau care afecteaza mai multe template-uri, serviciul de optimizare viteza website si Core Web Vitals poate aborda masurarea, diagnosticul si interventiile tehnice pe cauzele dominante.

Greseli frecvente: cand optimizarea scorului inlocuieste diagnosticul

1. Urmarirea obsesiva a scorului Lighthouse

Un scor mare este util, dar nu inseamna automat ca toti utilizatorii au experiente bune. Google recomanda Core Web Vitals pentru experienta reala si precizeaza ca obtinerea unor rezultate perfecte doar pentru SEO nu ar trebui sa fie obiectivul principal.

2. Tratarea INP si CLS ca probleme de incarcare

INP este despre responsivitate la interactiuni, iar CLS despre stabilitate vizuala. Un CDN mai rapid nu rezolva automat un event handler de 800 ms sau un banner care muta pagina.

3. Comprimarea tuturor imaginilor fara identificarea LCP

Reducerea imaginilor este utila, dar daca elementul LCP este text sau daca resursa este descoperita foarte tarziu, efortul poate avea efect limitat.

4. Eliminarea aleatorie a scripturilor pentru INP

Foloseste Performance panel si instrumentele de profiling pentru a vedea ce ruleaza in timpul interactiunii lente. Altfel poti elimina functionalitati fara sa atingi task-ul care blocheaza efectiv main thread-ul.

5. Un singur test este tratat ca adevar absolut

Conditiile retelei, serverului si dispozitivului variaza. Pentru diagnostic foloseste mai multe rulari de laborator si compara-le cu datele reale.

6. Core Web Vitals sunt tratate ca o garantie SEO

Google confirma ca sistemele sale folosesc Core Web Vitals, dar explica si ca experienta paginii este doar o parte a evaluarii generale. Rezultate bune in Core Web Vitals nu garanteaza pozitionari superioare.

Checklist practic de diagnostic

Pentru un site nou sau un redesign, performanta trebuie verificata impreuna cu crawlingul, indexarea, canonical-urile si redirectarile. Checklistul despre SEO tehnic pentru site-uri noi inainte si dupa lansare acopera aceste verificari complementare.

Core Web Vitals se rezolva mai bine cu cronologii decat cu presupuneri

Cele trei metrici devin mult mai usor de inteles cand sunt privite ca evenimente tehnice:

• LCP intreaba cand apare continutul principal si unde s-a pierdut timpul pana atunci;
• INP intreaba ce s-a intamplat intre interactiunea utilizatorului si urmatorul frame vizual;
• CLS intreaba ce element s-a mutat si de ce browserul nu ii rezervase corect spatiul.

Nu optimiza o metrica inainte sa identifici componenta care produce intarzierea sau instabilitatea.

Aceasta abordare evita modificarile cosmetice si permite prioritizarea interventiilor care au efect real asupra utilizatorilor.