Core Web Vitals este inițiativa prin care Google măsoară și încurajează îmbunătățirea experienței utilizatorului pe internet. Pe baza acestor indicatori, HTTP Archive publică periodic statistici din lumea reală, care arată ce scoruri obțin cele mai populare sisteme de management al conținutului (CMS – Content Management System). Comparația clasică pune față în față WordPress, Drupal, Joomla, Squarespace și Wix, iar rezultatele au fost mereu mixte: niciun CMS nu domină la toate capitolele.

Core Web Vitals

Ce sunt Core Web Vitals? După cum am menționat în primul paragraf, Core Web Vitals este setul de indicatori prin care Google măsoară experiența reală a utilizatorilor pe un site web. Cei trei indicatori care compun Core Web Vitals sunt:

Largest Contentful Paint (LCP), care măsoară performanța de încărcare a site-ului: timpul până când cel mai mare element de conținut al paginii (o imagine sau un bloc de text) devine vizibil și util utilizatorului. Un scor „bun” înseamnă sub 2,5 secunde.
Interaction to Next Paint (INP), care măsoară capacitatea de răspuns a paginii: cât de repede reacționează site-ul la interacțiunile utilizatorului (click, tap, tastatură). INP a înlocuit oficial vechiul indicator First Input Delay (FID) în martie 2024. Un scor „bun” înseamnă sub 200 de milisecunde.
Cumulative Layout Shift (CLS), care măsoară stabilitatea vizuală: cât de mult se deplasează elementele paginii (butoane, formulare, linkuri) în timpul încărcării. Un scor „bun” înseamnă sub 0,1.

Definițiile oficiale și pragurile actualizate sunt documentate public în ghidul Web Vitals, iar rolul lor în căutare este descris în documentația Google despre page experience. Reține un lucru din start: sunt un semnal de departajare între rezultate comparabile, nu un înlocuitor pentru conținut relevant.

Performanță pentru desktop și mobil

Performanța pe desktop este superioară performanței de pe mobil în majoritatea cazurilor, iar aceasta este doar o reflectare a capacităților de redare ale dispozitivului și a diferențelor de rețea dintre dispozitive. Acestea fiind spuse, scorurile CWV (Core Web Vitals) de pe mobil sunt mai importante decât scorurile CWV de pe desktop, iar acest lucru se datorează faptului că majoritatea vizitatorilor accesează site-urile utilizând dispozitive mobile. Acesta este motivul pentru care Google folosește indexarea mobile-first și scorurile Core Web Vitals de pe mobil ca punct de referință pentru a clasifica site-urile web. În timp ce scorurile de pe desktop sunt importante și nu trebuie ignorate, cele mai critice sunt scorurile de pe mobil, așa că rețineți acest lucru.

În practică, asta înseamnă două lucruri. Primul: când testezi, testează în condiții de mobil – dispozitiv de gamă medie și conexiune limitată, nu laptopul tău pe fibră. Al doilea: atât în datele publice de la utilizatori reali, cât și în Search Console, rezultatele sunt separate pe tipul de dispozitiv, așa că o problemă poate exista exclusiv pe mobil și să fie complet invizibilă în cifrele de desktop. Dacă poți urmări constant un singur set de scoruri, acela trebuie să fie cel de pe mobil.

Explicarea scorurilor

Scorurile sunt extrase din vizitele reale ale utilizatorilor de Google Chrome, colectate în Chrome User Experience Report (CrUX), și sunt împărțite între desktop și mobil. Un site „trece” evaluarea Core Web Vitals atunci când cel puțin 75% dintre vizite obțin calificativul „bun” la toți cei trei indicatori. Îți poți verifica gratuit scorurile propriului site cu PageSpeed Insights sau în raportul Core Web Vitals din Google Search Console.

Detaliul care se pierde cel mai des este percentila 75. Valoarea raportată nu este media vizitelor, ci pragul sub care se încadrează 75% dintre ele. Cu alte cuvinte, sfertul cel mai lent al vizitatorilor decide dacă treci sau nu. De aceea o medie frumoasă poate ascunde un eșec: dacă majoritatea vizitatorilor au un LCP de aproximativ o secundă, dar o minoritate consistentă stă la peste patru secunde, media pare acceptabilă, în timp ce percentila 75 depășește pragul și pagina ajunge în categoria „necesită îmbunătățiri”.

Indicator	Bun	Necesită îmbunătățiri	Slab	Ce măsoară
LCP	cel mult 2,5 s	2,5 – 4,0 s	peste 4,0 s	viteza de afișare a conținutului principal
INP	cel mult 200 ms	200 – 500 ms	peste 500 ms	capacitatea de răspuns la interacțiuni
CLS	cel mult 0,1	0,1 – 0,25	peste 0,25	stabilitatea vizuală a paginii

Pragurile oficiale Core Web Vitals. Evaluarea se face la percentila 75 a vizitelor reale.

Al doilea detaliu tehnic util: datele de la utilizatori reali se calculează pe o fereastră glisantă de 28 de zile. Chiar dacă rezolvi problema astăzi, raportul nu se schimbă mâine – îmbunătățirea apare treptat, pe măsură ce vizitele vechi ies din fereastră. Așteaptă-te la trei-patru săptămâni până când efectul complet devine vizibil în Search Console și nu trage concluzii după 48 de ore.

Date din teren și date de laborator

Există două tipuri de măsurători, iar confuzia dintre ele produce cele mai multe discuții inutile. Datele din teren (field data) provin de la utilizatori reali, cu dispozitivele, rețelele și obiceiurile lor de navigare; ele decid dacă treci sau nu evaluarea. Datele de laborator (lab data) provin dintr-un test sintetic, rulat într-un mediu controlat, cu o singură încărcare de pagină și fără interacțiune umană; ele sunt reproductibile și îți arată cauza tehnică, dar nu reflectă publicul tău real. Un test de laborator nu poate raporta INP în mod fidel, pentru că nimeni nu apasă nimic în timpul lui.

Regula practică este simplă: datele din teren îți spun dacă ai o problemă, datele de laborator îți spun de unde vine. Începe întotdeauna cu primele, altfel vei petrece săptămâni optimizând ceva care nu deranja pe nimeni.

Unealtă	Tip de date	Bună pentru	Limitare
PageSpeed Insights	teren + laborator	verificarea rapidă a unei singure pagini	secțiunea de teren apare doar dacă URL-ul are trafic suficient
Raportul Core Web Vitals din Search Console	teren	monitorizarea întregului site, pe grupuri de pagini similare	fereastră de 28 de zile, fără detalii tehnice despre cauză
Lighthouse și panoul Performance din Chrome DevTools	laborator	diagnostic detaliat, reproducerea problemei pas cu pas	nu reflectă utilizatorii reali; INP nu poate fi măsurat automat
Biblioteca open-source web-vitals	teren (propriu)	colectarea valorilor direct de la vizitatorii tăi	necesită implementare și un loc unde să trimiți datele
GA4 sau alt sistem de analiză	teren (propriu)	segmentare pe pagini, dispozitive, țări, surse de trafic	depinde de evenimentele pe care le configurezi corect

Largest Contentful Paint (LCP)

Largest Contentful Paint arată cât de repede vede utilizatorul conținutul principal al paginii. În rapoartele HTTP Archive, LCP este de regulă indicatorul la care CMS-urile stau cel mai prost: imaginile neoptimizate, timpul de răspuns al serverului și resursele care blochează redarea trag scorurile în jos. Pentru un LCP „bun”, optimizează imaginile (formate moderne precum WebP sau AVIF), folosește caching și un hosting rapid și încarcă cu prioritate elementul principal al paginii.

Ca să nu optimizezi la întâmplare, merită să știi că LCP se descompune în patru intervale succesive: timpul până la primul octet trimis de server (TTFB), întârzierea până când browserul descoperă resursa LCP, timpul efectiv de descărcare a acelei resurse și întârzierea până la randarea ei pe ecran. Chrome DevTools îți arată această descompunere, iar reparația corectă depinde de intervalul dominant – degeaba comprimi imaginea dacă problema reală este un TTFB de o secundă și jumătate.

Identifică elementul LCP concret: în panoul Performance din Chrome DevTools apare marcat explicit. De cele mai multe ori este imaginea principală, un titlu mare sau un banner.
Vezi care dintre cele patru intervale consumă cel mai mult timp. Acolo trebuie să intervii, restul sunt detalii.
Dacă domină TTFB: activează caching la nivel de pagină, mută site-ul pe un hosting decent, pune un CDN în față și redu interogările lente către baza de date.
Dacă descoperirea resursei întârzie: pune imaginea direct în HTML-ul inițial, nu prin JavaScript sau ca fundal CSS, adaugă fetchpriority="high" pe imaginea LCP și, dacă e cazul, un preload.
Dacă descărcarea durează: convertește imaginea în WebP sau AVIF, servește-o la dimensiunea reală de afișare și folosește srcset pentru variante pe mobil.
Nu aplica niciodată loading="lazy" pe imaginea LCP. Este cea mai frecventă cauză de regresie după instalarea unui plugin de optimizare care aplică lazy loading global.
Elimină CSS-ul și JavaScriptul care blochează redarea în partea de sus a paginii și încarcă fonturile cu font-display: swap, plus preload pentru fontul folosit în titlu.
Retestează în laborator imediat, apoi urmărește datele de teren după câteva săptămâni.

Pentru fiecare dintre acești pași există documentație tehnică detaliată în ghidul Optimize LCP.

Interaction to Next Paint (INP)

Interaction to Next Paint a înlocuit First Input Delay ca indicator oficial al capacității de răspuns. Spre deosebire de FID, care măsura doar prima interacțiune, INP evaluează toate interacțiunile utilizatorului pe parcursul vizitei, motiv pentru care este un test mult mai exigent. Principalul vinovat pentru scorurile INP slabe este JavaScriptul excesiv: scripturi de tracking, plugin-uri și teme supraîncărcate care blochează răspunsul paginii. Reducerea și amânarea scripturilor neesențiale aduce, de obicei, cele mai vizibile îmbunătățiri.

Și INP se descompune, la rândul lui, în trei componente: întârzierea de intrare (cât așteaptă interacțiunea până când firul principal al browserului se eliberează), durata de procesare (cât rulează efectiv codul tău de răspuns) și întârzierea de prezentare (cât durează până browserul desenează rezultatul pe ecran). Fiecare componentă are soluții diferite, așa că măsoară înainte să repari.

Identifică interacțiunile lente reale, nu cele presupuse: meniuri mobile, filtre de produse, adăugare în coș, carusele, formulare cu validare.
Inventariază scripturile terțe. Fiecare chat, hartă, pixel publicitar și test A/B are un cost pe firul principal; multe pot fi încărcate abia după prima interacțiune a utilizatorului.
Amână tot ce nu este esențial pentru primul ecran, folosind defer sau async, și încarcă widgeturile grele doar când devin vizibile.
Sparge sarcinile JavaScript lungi în bucăți mai mici și cedează periodic controlul firului principal, ca browserul să poată răspunde între ele.
În handlerul de interacțiune, fă doar minimul necesar pentru feedback vizual imediat, apoi execută restul muncii asincron.
Redu numărul de elemente din DOM și evită animațiile care recalculează aspectul întregii pagini.
Testează pe un telefon de gamă medie, nu în emulatorul de pe desktop – diferența este mai mare decât te aștepți.

Detalii și exemple de cod găsești în ghidul Optimize INP.

Cumulative Layout Shift (CLS)

Cumulative Layout Shift măsoară cât de mult se schimbă elementele paginii atunci când aceasta se încarcă, elemente precum butoane, formulare și linkuri. Elementele care se tot mișcă în pagină nu sunt bune pentru experiența utilizatorului: este greu să citești un text în timp ce se deplasează în interiorul paginii și este și mai greu să dai click pe linkuri. Pentru un CLS „bun”, rezervă spațiu pentru imagini și reclame (setează dimensiuni explicite), evită inserarea de conținut deasupra celui deja afișat și încarcă fonturile astfel încât textul să nu se rearanjeze.

În practică, aproape toate deplasările vin din cinci surse:

imagini și videoclipuri fără atribute width și height sau fără aspect-ratio în CSS;
reclame, embed-uri și iframe-uri cu înălțime variabilă, inserate în fluxul paginii;
fonturi web care înlocuiesc fontul de rezervă și schimbă înălțimea rândurilor;
bannere de cookie-uri, bare de anunțuri și notificări adăugate deasupra conținutului deja afișat;
conținut injectat de JavaScript după randarea inițială (recomandări, recenzii, prețuri actualizate).

Regula generală: dacă un element apare mai târziu, rezervă-i spațiul de la început. Un container cu înălțime fixă pentru zona de reclamă costă puțin spațiu alb, dar salvează scorul. Bannerele de consimțământ ar trebui suprapuse peste conținut, nu inserate în flux. Iar fonturile web merită preîncărcate și potrivite ca metrici cu fontul de rezervă, astfel încât schimbarea să fie imperceptibilă. Pașii concreți sunt descriși în ghidul Optimize CLS.

Un flux de diagnostic pas cu pas

Să luăm un scenariu ipotetic, dar foarte tipic: un magazin online trece la CLS și INP, însă cade la LCP pe mobil. Iată cum arată o investigație corectă, în ordine:

Deschizi raportul Core Web Vitals din Search Console și confirmi că problema apare doar pe mobil și afectează un grup de pagini – de exemplu paginile de produs – nu întreg site-ul.
Alegi trei URL-uri reprezentative din acel grup și le treci prin PageSpeed Insights, notând valorile din secțiunea de date reale.
Deschizi una dintre pagini în Chrome DevTools, cu profil de dispozitiv mobil și rețea limitată, și înregistrezi încărcarea. Identifici elementul LCP: imaginea principală de produs.
Citești descompunerea LCP. Dacă TTFB este rezonabil, dar intervalul până la descoperirea resursei este mare, cauza nu este serverul, ci felul în care este livrată imaginea – de pildă un slider care o încarcă din JavaScript.
Aplici o singură modificare: prima imagine a sliderului se randează direct în HTML, fără lazy loading, cu prioritate mare de descărcare; celelalte imagini rămân leneșe.
Retestezi imediat în laborator. Dacă intervalul problematic nu s-a scurtat, ipoteza a fost greșită – întoarce-te la pasul 4 în loc să adaugi încă o modificare peste.
Aștepți patru săptămâni și verifici din nou datele de teren, ca fereastra glisantă să reflecte schimbarea.
Documentezi modificarea în tema copil sau în procedura de deploy, ca să nu fie anulată de următoarea actualizare de temă ori de plugin.

Principiul de bază este „o singură schimbare, o singură măsurătoare”. Dacă modifici cinci lucruri simultan și scorul se mișcă, nu vei ști niciodată care a contat și ce trebuie păstrat.

Greșeli frecvente

Optimizarea pentru scorul din Lighthouse în locul datelor reale. Scorul sintetic este un instrument de diagnostic, nu criteriul de evaluare.
Lazy loading aplicat global. Este util pentru imaginile de mai jos, dar dezastruos pentru imaginea LCP din partea de sus.
Adăugarea unui al patrulea plugin de optimizare. Pluginurile de cache și de minificare se suprapun și se anulează reciproc; unul singur, configurat corect, bate trei configurate la întâmplare.
Testarea exclusiv pe desktop, pe conexiune rapidă. Publicul real folosește telefoane obișnuite, pe rețele obișnuite.
Concluzii trase la 48 de ore. Fereastra de 28 de zile face imposibilă o verificare rapidă în datele de teren.
Ignorarea șabloanelor. Problemele apar aproape întotdeauna la nivel de șablon, nu de pagină individuală; repară șablonul și repari mii de URL-uri deodată.
Așteptarea unui salt de poziții. Un scor bun nu compensează un conținut slab sau lipsa autorității.

Câștigătorii și cei „nu atât de câștigători”

Concluzia rapoartelor HTTP Archive rămâne aceeași de la an la an: niciun CMS nu câștigă la toate capitolele. Drupal a stat în mod tradițional bine la LCP și CLS, WordPress domină piața, dar rămâne la mijlocul clasamentului, iar platformele de tip website builder, precum Wix și Squarespace, au recuperat vizibil în ultimii ani. Mai important decât platforma aleasă este însă modul în care este implementat și optimizat site-ul: aceeași temă WordPress poate obține scoruri excelente sau dezastruoase, în funcție de hosting, plugin-uri și optimizare. Iar HTTP Archive subliniază constant că toate platformele mai au de lucru la acest capitol.

Merită adăugat un nuanțator important: comparațiile între CMS-uri sunt influențate de profilul site-urilor care le folosesc, nu doar de calitatea platformei în sine. WordPress rulează un număr uriaș de site-uri mici, pe găzduire ieftină, cu teme cumpărate din marketplace-uri și zeci de plugin-uri active – un context care trage media în jos indiferent de platformă. Un site construit cu atenție pe oricare dintre aceste sisteme poate trece confortabil pragurile. Disciplina tehnică – găzduire decentă, un număr rezonabil de plugin-uri, imagini optimizate și un buget de JavaScript pe care chiar îl respecți – contează mai mult decât eticheta de pe platformă.

Întrebări frecvente

Core Web Vitals influențează direct poziția în Google?

Da, dar modest. Sunt un semnal folosit pentru a departaja rezultate altfel comparabile ca relevanță. Între două pagini care răspund la fel de bine intenției de căutare, cea cu experiență mai bună are avantaj. Un scor perfect nu ridică însă o pagină slabă peste una excelentă, iar un scor mediocru nu anulează un conținut care chiar rezolvă problema utilizatorului.

De ce PageSpeed Insights îmi arată alte valori decât Search Console?

Pentru că nu compară același lucru. PageSpeed Insights afișează și un test de laborator rulat acum, în condiții simulate, pe lângă datele reale. Search Console folosește exclusiv date reale, agregate pe 28 de zile și grupate pe URL-uri similare. Diferențele sunt normale; decizia de trecere sau picare se ia doar pe baza datelor reale.

Cât durează până se văd îmbunătățirile?

În laborator, imediat după implementare. În datele reale, între trei și patru săptămâni, din cauza ferestrei glisante de 28 de zile. Dacă după o lună completă raportul nu se mișcă deloc, ipoteza inițială a fost greșită sau modificarea nu a ajuns în producție pe toate șabloanele afectate.

Ce fac dacă nu am destul trafic pentru date reale?

Site-urile și paginile cu trafic redus nu apar în raportările publice bazate pe utilizatori reali, pentru că nu există suficiente vizite pentru un eșantion valid. În acest caz ai două opțiuni: te bazezi pe teste de laborator, aplicând bunele practici cunoscute, sau îți colectezi propriile date cu biblioteca open-source web-vitals și le trimiți în sistemul tău de analiză. A doua variantă este mai bună, pentru că măsoară exact publicul tău.

Un scor de 100 în Lighthouse înseamnă că am trecut Core Web Vitals?

Nu. Lighthouse calculează un scor compozit dintr-un set de indicatori sintetici, măsurați într-un singur test, fără interacțiune reală. Poți avea 100 în laborator și un INP slab în teren, pentru că utilizatorii chiar apasă butoane pe care testul automat nu le atinge niciodată.

Trebuie să optimizez fiecare pagină?

Nu, și nici nu ar fi eficient. Lucrează pe șabloane, nu pe pagini: pagina de produs, articolul de blog, pagina de categorie, pagina principală. Prioritizează după traficul organic și valoarea comercială a fiecărui tip de pagină, iar restul se rezolvă de la sine, pentru că folosesc aceeași structură.

Chiar dacă Core Web Vitals este mai mult despre experiența utilizatorului și mai puțin despre clasarea în căutarea Google, acești indicatori sunt însă importanți. Dacă un utilizator are o experiență excelentă atunci când folosește site-ul tău web, este mai probabil ca acesta să revină și să recomande site-ul altcuiva, ceea ce va fi benefic în cele din urmă și pentru clasamentele SEO. Iar dacă scorurile site-ului tău au nevoie de îmbunătățiri, un audit de SEO tehnic este cel mai bun punct de plecare.

Core Web Vitals – Măsurarea Performanței Unui Website