Pe scurt
- Core Web Vitals sunt trei măsurători: LCP (cât de repede apare conținutul principal), INP (cât de repede răspunde pagina la un clic sau o atingere) și CLS (cât de mult „sare” conținutul pe ecran).[1]
- Pragurile pentru „bun” sunt: LCP în cel mult 2,5 secunde, INP de cel mult 200 de milisecunde, CLS de cel mult 0,1, atinse la 75% dintre vizite.[1]
- INP a înlocuit FID ca indicator oficial la 12 martie 2024. Dacă un raport îți vorbește încă despre FID, este vechi.[2]
- Google confirmă că sistemele sale de clasare folosesc Core Web Vitals, dar precizează că rezultatele bune nu garantează primele locuri și că relevanța conținutului rămâne prioritară.[3]
- În septembrie 2026, 55,54% din afișările de pagini din România au venit de pe telefoane mobile.[4]
- Scorul de la 0 la 100 din PageSpeed Insights este un test de laborator. Evaluarea Core Web Vitals se face pe date de la utilizatori reali.[5]
De ce te interesează, ca om de afaceri
Un site lent costă vânzări. Omul care a dat clic pe rezultatul tău în Google și așteaptă să apară ceva pe ecran are la un deget distanță butonul „înapoi” și următorul rezultat din listă.
În România, vizitatorul tipic stă cu telefonul în mână. StatCounter arată următoarea împărțire a afișărilor de pagini în septembrie 2026:[4]
Două precizări despre cifre. StatCounter numără afișări de pagini, nu vizitatori unici, pe o rețea de peste un milion de site-uri care îi folosesc codul de măsurare.[6] Iar datele pot fi revizuite timp de 45 de zile de la publicare, deci valoarea pentru septembrie se mai poate ajusta ușor.[6] Este o medie pe toată țara: un magazin de modă poate avea mult peste jumătate din trafic de pe mobil, iar un furnizor B2B, mult sub.
Cele trei măsurători, pe rând
LCP: cât de repede văd ceva util
Largest Contentful Paint măsoară momentul în care apare cel mai mare element vizibil pe ecran: o imagine, un bloc de text sau un video.[7] Pe o pagină de produs este, de regulă, fotografia principală. Pe o pagină de servicii, bannerul sau titlul mare de sus.
INP: cât de repede îmi răspunde
Interaction to Next Paint măsoară timpul dintre un clic, o atingere sau o apăsare de tastă și momentul în care ecranul se actualizează. Derularea paginii și trecerea cu mouse-ul peste elemente nu se iau în calcul. Valoarea finală este cea mai lentă interacțiune observată, fără excepțiile izolate.[8]
CLS: cât de mult se mișcă pagina
Cumulative Layout Shift măsoară deplasările neașteptate ale conținutului. Este situația în care vrei să apeși „Adaugă în coș”, apare un banner deasupra și atingi altceva. CLS este un scor, nu un timp.[9]
Ce s-a întâmplat cu FID
Până în 2024, al doilea indicator era FID (First Input Delay), care măsura doar întârzierea la prima interacțiune. Google a anunțat că INP devine oficial Core Web Vital și înlocuiește FID la 12 martie 2024, iar FID este scos din program.[2] Diferența practică: INP se uită la toate interacțiunile din timpul vizitei, deci este mai greu de trecut pentru site-urile încărcate cu scripturi.
Pragurile oficiale
Fiecare indicator are trei trepte. Google recomandă să măsori la percentila 75, separat pe mobil și pe desktop.[1] Pe românește: pragul trebuie atins de trei sferturi dintre vizite, nu de vizita medie și nu de cea făcută de tine, din birou, pe Wi-Fi.
| Indicator | Bun | Necesită îmbunătățiri | Slab |
|---|---|---|---|
| LCP | până la 2,5 s | până la 4 s | peste 4 s |
| INP | până la 200 ms | până la 500 ms | peste 500 ms |
| CLS | până la 0,1 | până la 0,25 | peste 0,25 |
Valorile sunt cele afișate de Google în raportul Core Web Vitals din Search Console.[10] Starea unui grup de pagini este dată de cel mai slab dintre cei trei indicatori pe tipul respectiv de dispozitiv.[10] Două note bune și una slabă înseamnă, în raport, „slab”.
Cât contează pentru poziția în Google
Aici circulă două exagerări opuse: „viteza este totul” și „viteza nu contează”. Documentația Google spune altceva, mai nuanțat. Redăm ideile principale din pagina despre experiența în pagină, actualizată la 22 septembrie 2026:[3]
- Sunt folosite în clasare. Formularea Google: „Core Web Vitals are used by our ranking systems.”
- Nu există un semnal unic de „experiență în pagină”. Sistemele de clasare se uită la mai multe semnale care, împreună, descriu experiența.
- Rezultatele bune nu garantează nimic. Google spune că valorile bune nu garantează că paginile tale vor ajunge în topul rezultatelor.
- Relevanța trece înainte. Google caută să afișeze conținutul cel mai relevant chiar și atunci când experiența în pagină este sub medie. O experiență foarte bună ajută cel mai mult acolo unde există multe pagini utile pentru aceeași căutare.
- Scorul perfect nu este un scop. Google notează că efortul de a obține un scor perfect doar din motive de SEO s-ar putea să nu fie cea mai bună folosire a timpului tău.
Pagina dedicată Core Web Vitals din Google Search Central adaugă recomandarea ca proprietarii de site-uri să obțină valori bune „pentru succes în Căutare” și pentru o experiență bună în general.[11]
Două feluri de date pe care lumea le confundă
Aproape orice neînțelegere despre viteză pornește de aici.
| Date de laborator | Date reale (de teren) | |
|---|---|---|
| De unde vin | Un test făcut pe loc, într-un mediu controlat | Vizitele reale ale utilizatorilor de Chrome, din ultimele 28 de zile |
| Ce primești | Scorul de performanță de la 0 la 100 și o listă de recomandări | Valorile LCP, INP și CLS și verdictul „trecut” sau „picat” |
| La ce folosesc | Să găsești și să repari problemele | Să afli cum merge site-ul în viața reală |
Documentația PageSpeed Insights descrie exact această diferență și precizează că datele reale acoperă perioada anterioară de colectare de 28 de zile.[5] O pagină trece evaluarea Core Web Vitals dacă toți cei trei indicatori sunt „buni” la percentila 75. Dacă nu există destule date pentru INP, este suficient ca LCP și CLS să fie bune.[5]
Testul de laborator pentru mobil simulează un telefon de clasă medie pe o rețea mobilă; documentația dă ca exemplu un Moto G4.[5] De aceea scorul pentru mobil iese aproape mereu mai mic decât cel pentru desktop și mai mic decât ce vezi tu pe telefonul tău nou. În scorul de laborator, 90 sau peste înseamnă bun, 50–89 necesită îmbunătățiri, iar sub 50 este slab.[5]
Cum măsori, pas cu pas, fără costuri
Deschide raportul Core Web Vitals din Search Console
Îl găsești în meniul din stânga, cu secțiuni separate pentru mobil și desktop. Raportul folosește datele reale din CrUX și grupează paginile cu experiență asemănătoare, astfel că starea afișată se aplică întregului grup.[10]
Notează grupurile cu probleme
Uită-te la ce tip de pagini sunt: pagini de produs, de categorie, articole. Problemele de viteză țin aproape mereu de șablon, nu de o singură adresă. Reparând șablonul, repari tot grupul.
Testează câte o pagină din fiecare grup în PageSpeed Insights
Sus vezi datele reale, dacă există. Jos vezi testul de laborator, cu elementul care dă LCP-ul și cu lista de cauze. Aceasta este lista pe care o trimiți programatorului.[5]
Repară și pornește validarea
După modificări, apasă butonul de validare a remedierii din Search Console. Google urmărește paginile timp de 28 de zile; dacă problema nu mai apare pe nicio adresă în acest interval, este considerată rezolvată.[10]
Dacă raportul este gol
La site-urile mici se întâmplă des. Un grup de adrese apare în raport doar dacă are destule date pentru LCP și CLS, iar raportul include numai adrese indexate.[10] Lipsa datelor nu înseamnă că site-ul este rapid și nici că este lent. Înseamnă că nu are încă destule vizite din Chrome. În acest caz te bazezi pe testul de laborator și pe bun-simț: deschide site-ul pe un telefon obișnuit, pe date mobile, și vezi cum se simte.
Primești o analiză gratuită în cel mult 24 de ore. Plătești doar dacă apar rezultatele din contract.
Cauze frecvente și ce se face cu ele
Când LCP este prea mare
Google împarte LCP în patru bucăți: timpul până la primul răspuns al serverului, întârzierea până începe încărcarea resursei, durata încărcării și întârzierea până la afișare. Orientativ, prima și a treia ar trebui să ia fiecare în jur de 40% din timp, iar celelalte două sub 10% fiecare.[13]
- Server lent. Un timp mare până la primul răspuns poate face pragul de 2,5 secunde greu sau imposibil de atins. Cauzele citate de Google: redirecționări multiple, vizitatori aflați departe de server, lipsa unui CDN.[13]
- Imaginea principală încărcată „leneș”. Regula Google este categorică: imaginea care dă LCP-ul nu se încarcă niciodată cu lazy-loading. I se poate da prioritate cu atributul fetchpriority="high".[13]
- Imagini prea grele. Se servesc la dimensiunea potrivită, comprimate, în formate moderne precum AVIF sau WebP.[13]
- Scripturi și stiluri care blochează afișarea. Scripturile sincrone din antetul paginii întârzie tot ce urmează.[13]
Când INP este prea mare
O interacțiune are trei faze: așteptarea până pornește codul, execuția lui și afișarea rezultatului.[8] Problemele apar când browserul este ocupat cu altceva.
- Prea mult JavaScript rulat deodată. Sarcinile lungi se sparg în bucăți mai mici, ca browserul să poată răspunde între ele. Sfatul general al Google: fă cât mai puțin în codul care răspunde la clic.[14]
- Scripturi evaluate în timpul încărcării. Dacă omul apasă cât pagina încă se încarcă, așteaptă până termină browserul de procesat scripturile.[14]
- Pagini cu prea multe elemente. Un DOM mare înseamnă mai multă muncă la fiecare redesenare. Meniurile uriașe, sliderele și listele lungi de produse sunt suspecții obișnuiți.[14]
Când CLS este prea mare
- Imagini și videoclipuri fără dimensiuni. Se adaugă atributele de lățime și înălțime, ca browserul să rezerve spațiul dinainte.[15]
- Reclame, hărți și alte elemente încorporate. Li se rezervă spațiu în pagină din start, iar locul rămâne ocupat chiar dacă reclama nu se încarcă.[15]
- Fonturi web. Când fontul ales se încarcă târziu și înlocuiește fontul de rezervă, textul își schimbă dimensiunea și împinge restul paginii.[15]
- Conținut introdus deasupra celui existent. Bannere de cookie-uri, bare de promoții, notificări care apar după încărcare.[9]
Ce repari mai întâi, dacă bugetul este limitat
Nu toate paginile merită același efort. Ordinea de mai jos este cea pe care o folosim noi în partea de optimizare on-page:
- Șabloanele care aduc bani. Pagina de produs și cea de categorie la un magazin, pagina de serviciu și cea de contact la o firmă de servicii.
- Indicatorul marcat „slab”, înaintea celui marcat „necesită îmbunătățiri”. Starea grupului este dată de cel mai slab indicator.
- Mobilul înaintea desktopului, dacă de acolo vine majoritatea vizitelor tale.
- Modificările care nu cer redesign: imagini, lazy-loading greșit, dimensiuni lipsă, scripturi de la terți care nu mai sunt folosite.
La un magazin online, scripturile adăugate în timp (chat, recenzii, pixeli de publicitate, ferestre promoționale) sunt de obicei primul loc în care merită căutat. Dacă site-ul este vechi și greu de reparat, uneori iese mai ieftin un site de prezentare nou, construit rapid de la început.
Primești o analiză gratuită în cel mult 24 de ore. Plătești doar dacă apar rezultatele din contract.
Întrebări frecvente
Trebuie să am scor 100 în PageSpeed Insights?
Nu. Scorul de la 0 la 100 este un test de laborator, util pentru depanare. Evaluarea Core Web Vitals se face pe date reale, la percentila 75. Google spune că un scor perfect urmărit doar pentru SEO s-ar putea să nu fie cea mai bună folosire a timpului.
De ce am scor bun pe desktop și slab pe mobil?
Testul pentru mobil simulează un telefon de clasă medie pe o rețea mobilă, deci condiții mai grele decât calculatorul tău. Este normal ca scorul să fie mai mic. Contează dacă datele reale de pe mobil trec pragurile.
Raportul din Search Console spune că nu are date. Ce fac?
Înseamnă că site-ul nu are destule vizite din Chrome pentru ca Google să poată calcula valorile. Folosește testul de laborator din PageSpeed Insights pe paginile importante și repară ce semnalează. Datele apar pe măsură ce crește traficul.
Am reparat problema. În cât timp se vede?
Datele reale acoperă ultimele 28 de zile, deci valorile se îmbunătățesc treptat, pe măsură ce vizitele vechi ies din interval. Validarea din Search Console urmărește paginile tot 28 de zile. Testul de laborator arată schimbarea imediat.
Dacă trec toate cele trei praguri, urc în Google?
Nu neapărat. Google spune explicit că valorile bune nu garantează primele locuri și că afișează conținutul cel mai relevant chiar dacă experiența în pagină este sub medie. Viteza ajută mai ales când concurezi cu pagini la fel de utile ca a ta.
Mai contează FID?
Nu. INP a înlocuit FID ca indicator Core Web Vitals la 12 martie 2024, iar FID a fost scos din program. Rapoartele și modulele care afișează încă FID nu mai reflectă evaluarea actuală.
Surse
- Web Vitals — web.dev (Google), ultima actualizare 31 octombrie 2024. Accesat la 10 octombrie 2026.
- Interaction to Next Paint becomes a Core Web Vital on March 12 — web.dev (Google), ultima actualizare 31 ianuarie 2024. Accesat la 10 octombrie 2026.
- Understanding Google Page Experience — Google Search Central, ultima actualizare 22 septembrie 2026. Accesat la 10 octombrie 2026.
- Desktop vs Mobile vs Tablet Market Share Romania — Statcounter Global Stats, date pentru septembrie 2026. Accesat la 10 octombrie 2026.
- About PageSpeed Insights — Google for Developers, ultima actualizare 21 octombrie 2024. Accesat la 10 octombrie 2026.
- FAQ — Statcounter Global Stats (metodologie). Accesat la 10 octombrie 2026.
- Largest Contentful Paint (LCP) — web.dev (Google), ultima actualizare 4 septembrie 2025. Accesat la 10 octombrie 2026.
- Interaction to Next Paint (INP) — web.dev (Google), ultima actualizare 2 septembrie 2025. Accesat la 10 octombrie 2026.
- Cumulative Layout Shift (CLS) — web.dev (Google), ultima actualizare 12 aprilie 2023. Accesat la 10 octombrie 2026.
- Core Web Vitals report — Search Console Help, Google. Accesat la 10 octombrie 2026.
- Understanding Core Web Vitals and Google search results — Google Search Central, ultima actualizare 10 decembrie 2025. Accesat la 10 octombrie 2026.
- CrUX methodology — Chrome for Developers, ultima actualizare 20 iunie 2024. Accesat la 10 octombrie 2026.
- Optimize Largest Contentful Paint — web.dev (Google), ultima actualizare 31 martie 2025. Accesat la 10 octombrie 2026.
- Optimize Interaction to Next Paint — web.dev (Google), ultima actualizare 2 septembrie 2025. Accesat la 10 octombrie 2026.
- Optimize Cumulative Layout Shift — web.dev (Google), ultima actualizare 7 februarie 2025. Accesat la 10 octombrie 2026.