Core Web Vitals pe înțelesul managerilor: ce măsoară și ce cereți de la un site nou
Ce măsoară LCP, INP și CLS, cum influențează cererile și poziția în Google și ce întrebări puneți înainte să aprobați refacerea site-ului.
- Nº
- 14
- Publicat
- Lectură
- 11 min
- Categorie
- Notes
- Scris de
- Revylio
Core Web Vitals pe scurt: trei indicatori de viteză pe care îi citește Google
Core Web Vitals pe înțelesul managerilor înseamnă trei întrebări simple. Cât așteaptă clientul conținutul principal? Cât de repede reacționează pagina când apasă un buton? Stă pagina pe loc cât timp o citește?
Google răspunde cu trei cifre, LCP, INP și CLS, măsurate pe vizite reale. Le puteți citi singur, gratuit, în Google Search Console.
Core Web Vitals sunt un set de trei indicatori tehnici prin care Google măsoară calitatea experienței reale a utilizatorilor pe un site. Setul folosit astăzi de Google Search și de Search Console este format din LCP (viteza de încărcare percepută), INP (reacția la interacțiuni) și CLS (stabilitatea vizuală).
INP a înlocuit în martie 2024 vechiul indicator FID. Motivul este concret: FID măsura doar prima interacțiune și rata interacțiunile lente de mai târziu. Dacă un raport primit de la furnizorul site-ului vorbește încă despre FID, raportul este depășit.
Ghidul de față vă arată ce măsoară fiecare indicator, unde îl citiți, cum influențează cererile și căutarea și ce întrebări puneți înainte să semnați o refacere. La final veți putea decide singur ce trebuie reparat primul pe site.
LCP măsoară cât așteaptă vizitatorul conținutul principal
LCP (Largest Contentful Paint) este timpul scurs din momentul în care un utilizator dă clic pe link până când cel mai mare element vizibil pe ecran este complet încărcat. De obicei, acest element este imaginea mare din capul paginii, un bloc de text sau un cadru video. Pentru vizitator, LCP este momentul în care pagina pare gata.
Pentru o afacere, LCP se traduce în răbdarea clientului. Site24x7, un producător de software de monitorizare, notează că o încărcare de una până la patru secunde este privită ca o întârziere obișnuită. O pagină care se încarcă în peste cinci secunde îi poate face pe clienți să plece.
Ținta recomandată de Google pentru LCP este sub 2,5 secunde. Peste 4 secunde, valoarea este considerată slabă.
Ce încetinește de obicei LCP
Cauzele frecvente sunt tehnice, dar ușor de recunoscut într-o discuție cu furnizorul:
- imagini necomprimate sau prea mari pentru ecranul pe care apar;
- prea multe redirecționări înainte de pagina finală;
- pagini fără cache, adică regenerate de server la fiecare vizită;
- fișiere CSS sau JavaScript încărcate înaintea conținutului, în loc de încărcare asincronă;
- un server care răspunde lent.
Pentru ultimul punct există un indicator separat, TTFB (Time to First Byte), timpul până la primul octet primit de browser. Google recomandă ca TTFB să rămână sub 200 de milisecunde.
Sursa: site24x7.com
INP măsoară cât de repede răspunde pagina la clic
INP (Interaction to Next Paint) este timpul scurs între acțiunea vizitatorului și momentul în care ecranul oferă un răspuns vizual concret. Acțiunea poate fi un clic, o atingere pe ecran sau o tastă apăsată. Google evaluează INP pe toată durata vizitei, nu doar la prima interacțiune.
În termeni de afaceri, INP este clientul care apasă „Trimite” pe formularul de ofertă și nu vede nimic. Apasă încă o dată sau închide pagina. Exact în acest moment, la conversie, un INP slab costă cel mai mult.
Un scor bun pentru INP înseamnă o întârziere sub 200 de milisecunde. Peste 500 de milisecunde, pagina este încadrată ca slabă.
De unde vin problemele de INP
Problemele de INP sunt cauzate aproape exclusiv de cod JavaScript aglomerat. În practică, codul vine din teme încărcate, module adăugate de-a lungul anilor, widgeturi de chat sau scripturi de urmărire. Fiecare adaugă muncă pentru browser exact când vizitatorul vrea să interacționeze.
Întrebarea utilă pentru furnizor este simplă. Ce scripturi rulează pe pagina de contact și de ce este nevoie de fiecare? Un răspuns vag sau „așa vine tema” arată unde trebuie să căutați.
CLS măsoară cât se mișcă pagina sub degetul vizitatorului
CLS (Cumulative Layout Shift) este suma tuturor deplasărilor neașteptate de layout care au loc în timp ce pagina se încarcă. Spre deosebire de LCP și INP, CLS nu se măsoară în timp. Este un scor fără unitate, iar un scor mai mic înseamnă o pagină mai stabilă.
Efectul de afaceri se vede pe telefon. Vizitatorul vrea să apese pe „Sună acum”, dar se încarcă o imagine deasupra. Butonul coboară și degetul nimerește altceva. Site24x7 explică de ce deranjează: ochiului uman îi trebuie cel puțin câteva sute de milisecunde ca să observe noua poziție a unui element mutat.
Un scor CLS de cel mult 0,1 este considerat excelent. Valorile de peste 0,25 semnalează o pagină instabilă.
Cauzele obișnuite ale unui CLS mare
Câteva cauze apar pe aproape orice site cu probleme de stabilitate:
- imagini fără dimensiuni definite, pentru care browserul rezervă inițial spațiu zero și apoi împinge conținutul în jos;
- reclame sau bannere plasate peste alte elemente;
- fonturi personalizate care schimbă dimensiunea textului după încărcare;
- scripturi care inserează conținut după ce pagina s-a afișat.
Remediul de bază este rezervarea spațiului: fiecare imagine primește lățime și înălțime sau un raport de aspect fixat în cod.
Pragurile Google pentru LCP, INP și CLS: bun, necesită îmbunătățiri, slab
Google încadrează fiecare pagină, pentru fiecare indicator, într-una din trei categorii: bună, necesită îmbunătățiri sau slabă. Tabelul de mai jos adună pragurile și ce simte clientul în fiecare caz. Este tabelul pe care îl puteți ține deschis lângă raportul din Search Console.
| Indicator | Ce simte clientul | Bun | Necesită îmbunătățiri | Slab |
|---|---|---|---|---|
| LCP | Cât așteaptă conținutul principal | sub 2,5 s | între 2,5 și 4 s | peste 4 s |
| INP | Cât așteaptă reacția la clic | sub 200 ms | între 200 și 500 ms | peste 500 ms |
| CLS | Cât se mișcă pagina | cel mult 0,1 | între 0,1 și 0,25 | peste 0,25 |
Două reguli schimbă felul în care citiți tabelul. Prima: Google evaluează valoarea de la percentila 75 a vizitelor reale. Altfel spus, cel puțin trei vizite din patru trebuie să fie la nivelul „bun”, nu doar media. Ghidul Google este să țintiți „bun” la percentila 75 pentru fiecare indicator.
A doua regulă: în Search Console, statusul unui grup de adrese este dat de cel mai slab indicator al său. O pagină cu LCP și INP bune, dar cu CLS slab, apare ca slabă. Nu puteți compensa un indicator prost cu doi buni.
Efectul Core Web Vitals asupra cererilor și a poziției în Google
Core Web Vitals influențează două lucruri diferite: câți vizitatori ajung să trimită o cerere și cât de vizibil este site-ul în căutare. Pentru cei mai mulți manageri, primul efect contează mai mult.
Cererile și vânzările
Un studiu citat de Nostra a arătat că o încărcare mai rapidă cu 0,1 secunde poate crește rata de conversie în retail cu 8,4%. Cifra vine din comerț, nu din servicii B2B. Totuși, direcția este clară: fiecare fracțiune de secundă câștigată lasă mai mulți vizitatori în pagină. Pentru o estimare pe propriul site, folosiți metoda din ghidul despre calculul cererilor pierdute din cauza unui site lent.
Poziția în căutare și reclamele
Core Web Vitals fac parte din semnalele Google privind experiența paginii. Ele nu înlocuiesc relevanța conținutului. O pagină rapidă, dar care nu răspunde la ce caută clientul, nu va urca doar datorită vitezei. Între două pagini cu conținut comparabil, experiența mai bună este un avantaj.
Google folosește indexarea axată pe mobil. Prin urmare, scorul pe telefon este cel care contează cel mai mult pentru pozițiile în căutări. Performanța site-ului influențează și reclamele: Nostra arată că afectează ad rank-ul și Quality Score în Google Ads.
Date din teren și date de laborator: care contează pentru Google
Datele din teren sunt măsurători făcute pe vizitele reale ale utilizatorilor Chrome. Google le adună în Chrome User Experience Report (CrUX), un set public de date disponibil prin API, BigQuery și panouri de raportare. Pe aceste date se bazează raportul Core Web Vitals din Search Console.
Datele de laborator vin dintr-o simulare. Lighthouse încarcă pagina în condiții controlate și arată ce fișiere o încetinesc. PageSpeed Insights combină cele două surse: date de laborator din Lighthouse și date din teren din CrUX, pentru mobil și pentru desktop.
Ce citește un manager și unde
Pentru o decizie, citiți întâi datele din teren din Search Console. Raportul împarte adresele în trei categorii: bune, necesită îmbunătățiri și slabe. Indicatorii sunt calculați pe o medie mobilă de 28 de zile. O reparație făcută azi apare complet în raport abia după aproximativ patru săptămâni.
Folosiți PageSpeed Insights pentru o pagină anume și pentru lista de cauze. Problemele marcate cu triunghi roșu contribuie la un scor slab și trebuie tratate primele. Cele marcate cu cerc gri au impact neglijabil.
O limită de știut: dacă INP nu are suficiente date, Search Console poate evalua doar LCP și CLS. Pe un site cu trafic mic, lipsa unei valori INP nu înseamnă că totul este în regulă.
Exemplu lucrat: o pagină de produs citită indicator cu indicator
Exemplul de mai jos folosește cifrele unui caz ilustrativ dintr-un articol de specialitate despre Core Web Vitals. Pagina analizată este o pagină de produs, cu valori măsurate la percentila 75. Urmăriți pașii și îi veți putea repeta pe propriul raport.
Valorile de pornire sunt LCP 4,3 secunde, INP 300 de milisecunde și CLS 0,25. Cu tabelul de praguri, citirea se face în trei pași:
- LCP de 4,3 secunde depășește pragul de 4 secunde, deci este slab.
- INP de 300 de milisecunde este între 200 și 500, deci necesită îmbunătățiri.
- CLS de 0,25 este la limita de sus a benzii „necesită îmbunătățiri”.
Statusul paginii în Search Console este dat de cel mai slab indicator. Pagina apare deci ca slabă, din cauza LCP. Decizia de prioritate rezultă direct: întâi se repară încărcarea conținutului principal. INP și CLS urmează, pentru că amândouă sunt aproape de pragul slab.
După lucrări, articolul raportează LCP 2,1 secunde, INP 80 de milisecunde și CLS 0,03. Toate trei sunt acum în banda „bun”, iar pagina trece evaluarea. Observați că o singură reparație nu ar fi fost suficientă. Dacă doar LCP scădea, pagina rămânea la „necesită îmbunătățiri” din cauza INP și CLS.
Ce reparați primul pe site: ordinea de prioritate pentru Core Web Vitals
Reparați întâi indicatorul aflat în banda „slab” pe paginile care aduc cereri. Statusul se calculează după cel mai slab indicator, deci acolo câștigați cel mai mult. Între pagini, începeți cu cele care primesc trafic din căutare și cu cele de contact sau ofertă.
Tabelul de mai jos leagă fiecare indicator de cauzele obișnuite și de tipul de lucrare. Îl puteți folosi ca listă de verificare într-o discuție cu furnizorul.
| Indicator slab | Cauze frecvente | Tipul de lucrare |
|---|---|---|
| LCP | Imagini necomprimate, redirecționări, lipsă cache, server lent | Optimizarea imaginilor, cache, găzduire, încărcare asincronă |
| INP | Cod JavaScript aglomerat, scripturi terțe | Reducerea și optimizarea scripturilor |
| CLS | Imagini fără dimensiuni, reclame plasate peste conținut, fonturi | Spațiu rezervat în cod, plasarea atentă a elementelor |
Măsurați înainte și după fiecare schimbare, pe aceleași pagini. La Svennis, pentru site-urile Revylio, notăm valorile din Search Console și din PageSpeed Insights pentru paginile care aduc cereri înainte de orice schimbare de design. După lansare comparăm aceleași pagini abia când media datelor reale s-a reînnoit complet, nu în ziua lansării.
Comparația contează mai ales la o migrare, unde se schimbă și adresele paginilor. Pașii sunt descriși în ghidul despre lansarea unui site nou fără pierderea traficului din Google.
Întrebările de pus înainte să aprobați refacerea site-ului
Înainte să aprobați o refacere, cereți ca performanța să fie scrisă în contract ca rezultat măsurabil, nu ca promisiune. Întrebările de mai jos vă ajută să separați un furnizor care măsoară de unul care doar afirmă că site-ul va fi rapid:
- Care sunt valorile actuale LCP, INP și CLS din Search Console pentru paginile noastre principale, pe mobil?
- Ce valori țintiți după lansare și la ce percentilă le măsurați?
- Vă bazați pe date din teren sau doar pe un test de laborator făcut o singură dată?
- Ce scripturi terțe rămân pe site și ce impact are fiecare asupra INP?
- Cum rezervați spațiul pentru imagini, reclame și fonturi, ca să țineți CLS sub 0,1?
- Ce timp de răspuns are serverul propus și cum se compară cu ținta de 200 de milisecunde pentru TTFB?
- Când comparăm rezultatele, ținând cont de media de 28 de zile din Search Console?
Un răspuns bun conține cifre și o dată. Un răspuns de tipul „scorul în PageSpeed va fi 100” pe desktop nu spune nimic despre clienții reali de pe telefon. Puneți aceste cerințe direct în brieful pentru refacerea site-ului, ca să devină criterii de acceptanță.
Ce înseamnă Core Web Vitals pentru o firmă din România
Pentru o firmă din România, Core Web Vitals arată experiența clienților dumneavoastră reali, nu pe cea din biroul agenției. Datele din teren vin de la vizitatorii care folosesc Chrome, pe telefoanele și conexiunile lor. Un site care pare rapid pe calculatorul din birou poate arăta altfel în Search Console.
Diferența se vede mai ales pe mobil. Google indexează întâi versiunea pentru telefon, așa că scorul de pe mobil cântărește cel mai mult în căutare. Verificați în Search Console separat rapoartele pentru mobil și desktop, nu doar o medie.
Multe firme mici au trafic redus. În acest caz, Search Console poate lipsi complet de date pentru unele pagini sau poate evalua doar LCP și CLS. Atunci PageSpeed Insights și testele de laborator rămân singura sursă de diagnostic, iar datele din teren vor apărea pe măsură ce crește traficul.
Viteza nu este singura cerință tehnică pentru un site nou. Dacă firma oferă servicii acoperite de Legea nr. 232/2022, de exemplu servicii de comerț electronic, aceeași refacere trebuie să acopere și accesibilitatea. Legea transpune EAA și se aplică din 28 iunie 2025. Microîntreprinderile care prestează servicii sunt scutite de această obligație. Merită verificate împreună, cu ghidul despre accesibilitatea site-ului firmei după EAA.
Pașii următori: de la raportul din Search Console la decizia de refacere
Primul pas este să deschideți raportul Core Web Vitals din Google Search Console și să notați câte adrese sunt bune, câte necesită îmbunătățiri și câte sunt slabe, pe mobil. Apoi lucrați în ordinea de mai jos:
- Pentru fiecare grup slab, notați indicatorul care îl trage în jos.
- Deschideți câte o pagină reprezentativă în PageSpeed Insights și notați problemele cu triunghi roșu.
- Comparați valorile cu tabelul de praguri din acest ghid.
- Decideți dacă reparațiile țintite ajung sau dacă problemele vin din temă, module și găzduire.
- Puneți valorile actuale și țintele în brief, ca bază de comparație după lansare.
Dacă problemele sunt răspândite pe tot site-ul, o reparație punctuală rareori ajunge. Criteriile pentru această decizie sunt explicate în ghidul despre momentul în care merită refacerea site-ului. Pentru a vedea ce include o refacere care tratează viteza, accesibilitatea, SEO și GDPR împreună, citiți pagina despre web design pentru companii: accesibil, rapid și conform GDPR.



