Core Web Vitals: LCP, INP, CLS și de ce contează pentru SEO

Core Web Vitals sunt trei metrici definite de Google pentru a măsura experiența reală a utilizatorilor pe o pagină web: LCP (Largest Contentful Paint), INP (Interaction to Next Paint) și CLS (Cumulative Layout Shift). Din mai 2021 sunt factor oficial de ranking în algoritmul de căutare. Nu sunt metrici teoretice; sunt calculate din comportamentul utilizatorilor reali și intră direct în scorul de performanță al oricărei pagini publice.

Spre deosebire de alte semnale de performanță, Core Web Vitals reflectă trei dimensiuni diferite ale experienței: cât de repede apare conținutul principal (LCP), cât de repede răspunde pagina la acțiuni (INP) și cât de stabil rămâne layout-ul în timp ce se încarcă (CLS). Optimizarea uneia nu le rezolvă automat pe celelalte.

Care sunt cele trei metrici Core Web Vitals (LCP, INP, CLS)?

Fiecare metrică captează o clasă distinctă de probleme de performanță:

• LCP (Largest Contentful Paint). Măsoară timpul până când cel mai mare element vizibil din viewport este randat complet. Elementul candidat poate fi o imagine, un bloc video sau un bloc de text mare (titlu, paragraf hero). Un LCP bun înseamnă că utilizatorul vede rapid conținutul principal, nu un schelet gol. Prag good: ≤2,5s.
• INP (Interaction to Next Paint). Înlocuiește FID din martie 2024. Măsoară latența dintre o acțiune a utilizatorului (click, tap, tastare) și momentul în care pagina produce un update vizibil ca răspuns. INP ia percentila 75 sau 98 din toate interacțiunile sesiunii, nu doar prima. O pagină care înghețase la al cincilea click arăta bine la FID și prost la INP. Prag good: ≤200ms.
• CLS (Cumulative Layout Shift). Suma scorurilor de deplasare neașteptată a elementelor din pagină pe parcursul întregii sesiuni. Un banner care apare și împinge textul în jos, o imagine care se încarcă fără dimensiuni rezervate, un font care înlocuiește un fallback și schimbă înălțimea unui paragraf: toate contribuie la CLS. Prag good: ≤0,1.

Cele trei praguri se aplică la percentila 75 a utilizatorilor reali, nu la medie. Dacă 26% din vizitatori văd LCP peste 2,5s, pagina nu este în zona good, chiar dacă mediana e excelentă.

Cum se măsoară fiecare (field data vs lab data)?

Există două tipuri de măsurătoare și nu sunt echivalente:

• Lab data. Rulezi Lighthouse sau WebPageTest într-un mediu controlat: conexiune simulată, hardware fix, o singură execuție. Util pentru detectarea regresiilor în CI și pentru reproductibilitate în dezvoltare. Nu reflectă variabilitatea reală a utilizatorilor: telefoane mai lente, rețele 4G fluctuante, browsere vechi.
• Field data. Date colectate de la utilizatori reali prin Chrome UX Report (CrUX). Agregat per origin pe o fereastră de 28 de zile. Aceasta este sursa pe care o folosește Google pentru ranking, nu Lighthouse. Google Search Console afișează valorile CrUX direct în raportul „Core Web Vitals".

Discrepanța obișnuită: Lighthouse arată LCP de 1,2s, CrUX arată 3,1s. Cauza tipică este că Lighthouse rulează pe desktop cu conexiune rapidă, iar traficul real vine majoritar de pe telefoane 4G. Optimizezi pentru field data, nu pentru lab data; lab data te ajută să reproduci problemele.

Care sunt pragurile good, needs improvement și poor?

Google definește trei zone pentru fiecare metrică:

• LCP: good ≤2,5s, needs improvement 2,5–4s, poor >4s.
• INP: good ≤200ms, needs improvement 200–500ms, poor >500ms.
• CLS: good ≤0,1, needs improvement 0,1–0,25, poor >0,25.

Pragurile sunt aplicate la percentila 75 din sesiunile colectate în CrUX. O pagină primește calificativul good pentru un URL dacă 75% din utilizatorii reali înregistrează valori în zona verde. Dacă oricare dintre cele trei metrici este în zona poor, pagina în ansamblu este clasificată poor, indiferent de celelalte două.

Un detaliu practic: CrUX are un prag minim de vizitatori pentru a afișa date per URL. Paginile cu trafic mic (pagini noi, pagini de nișă) pot să nu apară în raport; în acest caz, Google folosește datele la nivel de origin dacă sunt disponibile.

Cum optimizăm Core Web Vitals pe crawlerra.com (SSR + caching + image sizing)?

Pe crawlerra.com folosim Angular SSR pentru paginile publice. Body-ul HTML SSR-uit are ~47 KB¹ (JSON-LD + meta + navigare + footer), suficient pentru LCP rapid pe rețele 4G obișnuite. Imaginile dimensionate explicit în CSS și folosirea formatelor moderne (AVIF/WebP) elimină layout shift și reduc payload-ul.

Câteva principii care se traduc direct în îmbunătățiri măsurabile pentru orice implementare:

• SSR pentru LCP. Când conținutul principal ajunge în primul răspuns HTTP (nu după ce se execută JavaScript-ul), browserul poate randează elementul LCP imediat ce primește HTML-ul. CSR amână randul LCP până ce bundle-ul JavaScript este descărcat, evaluat și cererea API întoarce datele.
• Preload pentru resurse critice. O imagine care este candidat LCP probabil trebuie preloaded cu <link rel="preload">. Browserul descoperă resursa mai devreme și nu mai pierde timp așteptând ca parser-ul HTML să o întâlnească în <body>.
• Dimensiuni explicite pentru CLS zero. Fiecare imagine și <iframe> trebuie să declare width și height sau aspect-ratio în CSS. Fără acestea, browserul nu rezervă spațiu și orice element care se încarcă asincron deplasează conținutul existent.
• Fonturi cu font-display: swap. Reduc blocajul de randat la primul text vizibil. Elimină complet shift-ul prin font-display: optional dacă fontul nu este critic pentru identitate vizuală.
• Lazy loading pentru imagini non-critice. Imaginile sub fold nu trebuie încărcate la prima randare. Atributul loading="lazy" amână descărcarea și eliberează lățimea de bandă pentru elementul LCP.
• Hydration progresivă. Componentele interactive se activează după randul inițial. Hydration completă înainte ca utilizatorul să interacționeze ține INP scăzut; JavaScript blocat în faza de hydration crește INP direct.

De ce contează concret pentru ranking-ul Google?

Google a integrat Core Web Vitals în algoritmul de ranking ca parte din Page Experience Update (mai 2021, extins la desktop în martie 2022). Sunt un factor de departajare confirmat: la relevanță egală, pagina cu Core Web Vitals în zona good câștigă locul față de una cu metrici poor.

Efectele concrete documentate de Google și de studii independente în ultimii trei ani:

• Paginile în zona good la toate trei metricile au o rată de abandon cu ~24% mai mică față de paginile poor.
• Fiecare secundă suplimentară de LCP peste 2,5s corelează cu o creștere a ratei de abandon și o scădere a conversiilor.
• CLS ridicat (layout shift vizibil) produce click-uri accidentale și corelează cu rating-uri negative ale experienței utilizatorului.

În afara ranking-ului direct, Core Web Vitals influențează eligibilitatea pentru Top Stories carousel pe mobil (unde sunt un criteriu de calificare, alături de conținut și structură). Un sitemap.xml corect și un hreflang bine configurat aduc Googlebot pe paginile corecte; Core Web Vitals determină dacă acele pagini se califică pentru pozițiile premium. Monitorizarea continuă a performanței în producție intră în același stack cu care urmărim orice altă metrică de sănătate, descris în intrarea despre observabilitate.

1. Mărimea HTML-ului SSR pentru un articol din blog, măsurată cu curl -sS https://crawlerra.com/blog/cum-scriem-articolele | wc -c. [crawlerra.ssr_body_size]