Core Web Vitals în 2026: ce sunt LCP, INP și CLS și cum le repari

Ce sunt cele trei metrici și ce măsoară fiecare

LCP (Largest Contentful Paint) măsoară cât durează până se afișează cel mai mare element vizibil din ecranul inițial — de obicei o imagine hero sau un titlu mare. Pragul bun este sub 2,5 secunde. INP (Interaction to Next Paint) măsoară timpul de răspuns al paginii la interacțiuni (click, tap, tastare) pe toată durata vizitei, nu doar la prima interacțiune — pragul bun este sub 200 de milisecunde. CLS (Cumulative Layout Shift) măsoară cât de mult „sare" conținutul paginii în timp ce se încarcă — pragul bun este sub 0,1.

Cei trei indicatori acoperă trei aspecte diferite ale experienței: cât de repede vezi conținutul, cât de repede răspunde pagina când interacționezi cu ea și cât de stabilă e vizual pagina. Un site poate fi rapid la încărcare (LCP bun) și totuși frustrant de folosit dacă butoanele răspund cu întârziere (INP prost).

Fiecare metrică are și un prag intermediar, „necesită îmbunătățiri", între valoarea bună și cea slabă: pentru LCP între 2,5 și 4 secunde, pentru INP între 200 și 500 de milisecunde, pentru CLS între 0,1 și 0,25. Orice valoare peste aceste intervale intermediare e considerată slabă de Google. Scopul realist pentru majoritatea site-urilor nu e neapărat „excelent" pe toate cele trei, ci ieșirea din zona slabă, care e cea cu impact real asupra clasamentului.

INP a înlocuit FID din martie 2024

Până în martie 2024, indicatorul oficial de răspuns la interacțiune era FID (First Input Delay), care măsura doar întârzierea primei interacțiuni. INP l-a înlocuit pentru că măsoară toate interacțiunile din vizită, nu doar prima, oferind o imagine mai realistă a modului în care pagina se comportă pe termen lung. Un site poate avea FID excelent (prima interacțiune e rapidă) și INP slab, dacă interacțiunile ulterioare — de exemplu deschiderea unui filtru pe pagina de categorie a unui magazin online — devin lente pe măsură ce se încarcă tot mai mult JavaScript.

Dacă vezi rapoarte vechi care încă menționează FID, ele nu mai reflectă metodologia actuală de evaluare Google. Tranziția e importantă mai ales pentru site-urile cu multă interacțiune — filtre, formulare, coșuri de cumpărături — unde experiența reală a utilizatorului nu se termină la primul click, ci continuă pe toată durata sesiunii.

Din auditurile noastre, site-urile care aveau FID bun dar nu erau niciodată testate la interacțiuni ulterioare descoperă, după trecerea la INP, probleme reale de performanță pe care nu le suspectau — de multe ori exact în paginile cu cel mai mult trafic, unde utilizatorii interacționează cel mai des.

Date de laborator vs. date de teren: care contează

Datele de laborator vin din instrumente precum Lighthouse, rulate o singură dată, pe o conexiune și un dispozitiv simulate. Sunt utile pentru depanare, dar nu reflectă experiența reală a vizitatorilor. Datele de teren vin din CrUX (Chrome User Experience Report) — telemetrie reală, colectată de la utilizatori Chrome care au vizitat efectiv pagina.

Google evaluează Core Web Vitals pe date de teren, la percentila 75 (adică 75% dintre vizite trebuie să se încadreze în prag), pe o fereastră glisantă de 28 de zile. Asta înseamnă că un scor bun în Lighthouse nu garantează un scor bun în Search Console, dacă majoritatea vizitatorilor tăi folosesc conexiuni mobile lente sau telefoane mai vechi.

Fereastra de 28 de zile mai are o consecință practică importantă: o modificare tehnică făcută astăzi nu apare instant în raportul de Search Console. Trebuie să treacă suficient timp ca noile date de teren să acumuleze o pondere semnificativă în fereastra glisantă, ceea ce înseamnă că rezultatul unei optimizări se vede cu adevărat abia după 2-4 săptămâni, nu a doua zi.

Lighthouse arată ce e posibil în condiții ideale. CrUX arată ce trăiesc efectiv utilizatorii tăi.

Cauze frecvente și remedii pentru LCP

Cele mai frecvente cauze pentru un LCP slab: CSS render-blocking (foi de stil mari, încărcate sincron, care blochează afișarea), imagini hero neoptimizate (fișiere mari, fără format modern precum WebP), fonturi de la terți încărcate lent și server lent la primul răspuns. Remediile concrete: comprimarea și dimensionarea corectă a imaginilor, încărcarea CSS critic inline iar restul asincron, precum și găzduire pe un server rapid, aproape geografic de audiență.

Un caz frecvent, mai ales pe magazine online: imaginea hero de pe pagina principală e adesea cea mai mare imagine din tot site-ul, dar și cea mai puțin optimizată, pentru că e adăugată ultima, sub presiunea lansării. Verificarea și optimizarea specifică a acestei singure imagini rezolvă, în multe cazuri, cea mai mare parte din problema de LCP.

În proiectele de optimizare SEO pe care le facem, LCP e de obicei primul indicator corectat, pentru că are cel mai mare impact vizibil asupra scorului general.

Cauze frecvente și remedii pentru INP

INP e afectat în principal de JavaScript greu — scripturi de tracking multiple, biblioteci încărcate inutil, cod care blochează firul principal la fiecare click. Bannerele de cookies prost implementate sunt un vinovat frecvent: apar instant, dar procesează evenimente de click cu întârziere, pentru că rulează peste alt JavaScript deja în execuție.

Remediile concrete: eliminarea scripturilor de terți nefolosite, împărțirea sarcinilor lungi de JavaScript în bucăți mai mici, amânarea încărcării codului care nu e necesar imediat. Pentru un magazin online pe WordPress/WooCommerce, plugin-urile acumulate în timp sunt cauza cea mai comună a unui INP slab.

Un semn tipic de INP slab, ușor de recunoscut fără instrumente tehnice: butonul „adaugă în coș" pare că nu reacționează la primul click, iar utilizatorul îl apasă a doua oară. Acel al doilea click e adesea semnul clar al unei probleme de INP, nu al unei erori funcționale — și, din experiența noastră, e un motiv de abandon al coșului mai des decât se crede.

Cauze frecvente și remedii pentru CLS

CLS apare de obicei din imagini fără dimensiuni declarate în HTML (browserul nu știe cât spațiu să rezerve, apoi „împinge" conținutul când imaginea se încarcă), reclame sau bannere injectate dinamic fără spațiu rezervat și fonturi web care schimbă dimensiunea textului la încărcare.

Remediile: setarea atributelor width și height (sau aspect-ratio în CSS) pentru toate imaginile, rezervarea de spațiu fix pentru bannere și widget-uri dinamice, folosirea font-display: optional sau swap cu atenție la fallback-uri similare ca dimensiune.

CLS e, dintre cele trei metrici, cea mai ușor de rezolvat definitiv, pentru că majoritatea cauzelor sunt statice și previzibile, nu variabile în funcție de comportamentul utilizatorului. Un audit unic, care verifică toate imaginile și elementele dinamice de pe paginile principale, elimină de regulă cea mai mare parte din problema de CLS pentru mult timp.

Cum verifici Core Web Vitals pentru site-ul tău

Search Console are un raport dedicat „Core Web Vitals" care arată paginile grupate pe stare (bună, necesită îmbunătățiri, slabă), bazat pe date de teren reale. PageSpeed Insights combină ambele tipuri de date, de laborator și de teren, pentru o singură pagină.

Un aspect util de știut: raportul din Search Console grupează paginile pe „grupuri de URL-uri" similare, nu pagină cu pagină. Dacă zeci de pagini de produs dintr-un magazin online au aceeași structură tehnică, ele apar grupate, iar o singură optimizare la nivel de șablon rezolvă întregul grup deodată, nu pagină cu pagină.

Dacă site-ul tău are scoruri slabe constant, cel mai eficient e un audit tehnic complet, nu corectarea izolată a unei singure metrici — vezi prețurile pentru un astfel de audit sau cere o ofertă personalizată.