Core Web Vitals 2026 înseamnă, în esență, același set de trei metrici pe care Google le folosește din 2021 — Largest Contentful Paint (LCP), Interaction to Next Paint (INP) și Cumulative Layout Shift (CLS) — verificate cu pragurile și instrumentele actuale. Optimizarea lor înseamnă o pagină care se încarcă vizual suficient de rapid, care răspunde rapid la interacțiuni (click, tap, tastare) și care nu își mișcă elementele pe ecran în timp ce utilizatorul citește sau completează un formular.
Pentru fiecare metrică, Google publică praguri clare de „bun", „necesită îmbunătățiri" și „slab", calculate din date reale de la utilizatori Chrome, la percentila 75. Un site care trece toate cele trei praguri „bun" oferă semnale alinate cu ceea ce sistemele de ranking ale Google urmăresc să recompenseze, fără ca asta să garanteze automat o poziție mai bună dacă relevanța conținutului este mai slabă decât a concurenței. Ultima actualizare: 22.06.2026.
Articolul explică pas cu pas ce este fiecare metrică, cum verifici scorurile reale ale site-ului tău, cum optimizezi practic LCP, INP și CLS, ce greșeli frecvente apar și ce afirmații despre „actualizări 2026" circulă online fără confirmare oficială. Este util pentru proprietari de afaceri care vor să înțeleagă raportul din Search Console, pentru specialiști SEO și pentru dezvoltatori care implementează optimizările tehnice.
Ce sunt Core Web Vitals și de ce contează pentru SEO și experiența utilizatorului
Core Web Vitals este un subset de metrici din programul mai larg de „page experience" (experiența paginii) definit de Google, axat strict pe trei aspecte măsurabile direct în browser: viteza de încărcare, capacitatea de răspuns la interacțiuni și stabilitatea vizuală. Sunt metrici de experiență reală a utilizatorului, nu doar indicatori tehnici abstracți.
Câteva definiții rapide, utile înainte de a continua:
- LCP (Largest Contentful Paint) = timpul până când cel mai mare element vizibil din zona inițială a paginii (de obicei imaginea principală sau titlul) se afișează complet.
- INP (Interaction to Next Paint) = timpul de răspuns vizual al paginii la o interacțiune a utilizatorului (click, tap, apăsare de tastă), măsurat pe toată sesiunea.
- CLS (Cumulative Layout Shift) = cât de mult se „mișcă" elementele vizibile ale paginii în timpul încărcării sau al interacțiunii, fără ca utilizatorul să fi cerut asta.
- CrUX (Chrome User Experience Report) = baza de date Google cu metrici reale, anonimizate, colectate de la utilizatorii reali ai browserului Chrome.
Practic, un site cu Core Web Vitals bune se simte „rapid și stabil" pentru cine îl folosește, nu doar pe hârtie: textul și imaginile apar prompt, butoanele reacționează imediat la click și nimic nu „sare" pe ecran cât utilizatorul citește sau completează un formular.
LCP, INP și CLS explicate: ce măsoară fiecare metrică și ce înseamnă un scor bun
Google publică praguri explicite pentru fiecare metrică, evaluate separat pentru mobil și desktop, pentru că cele două medii au, de regulă, performanțe diferite. Tabelul de mai jos rezumă pragurile oficiale, confirmate direct în documentația Google și în raportul Core Web Vitals din Search Console.
| Metrică | Bun | Necesită îmbunătățiri | Slab |
|---|---|---|---|
| LCP (viteza de încărcare) | ≤ 2,5 secunde | 2,5 - 4 secunde | peste 4 secunde |
| INP (răspuns la interacțiune) | ≤ 200 milisecunde | 200 - 500 milisecunde | peste 500 milisecunde |
| CLS (stabilitate vizuală) | ≤ 0,1 | 0,1 - 0,25 | peste 0,25 |
De ce contează percentila 75, nu media
Google evaluează aceste praguri la percentila 75 a vizitelor reale, nu la media lor. Practic, pentru ca o pagină să fie clasificată „bună", cel puțin 75% din vizitele reale trebuie să respecte pragul „bun" pentru fiecare metrică, separat pe mobil și pe desktop. O medie bună, cu vârfuri ocazionale foarte slabe, nu garantează un scor „bun" la percentila 75.
De ce INP a înlocuit FID
Până în martie 2024, a treia metrică oficială era First Input Delay (FID), care măsura doar întârzierea primei interacțiuni a utilizatorului. INP a devenit Core Web Vital oficial la 12 martie 2024, înlocuind FID, pentru că măsoară capacitatea de răspuns pe întreaga sesiune de vizită, nu doar la primul click. Această schimbare este confirmată oficial de Google și este singura modificare majoră de metrică din ultimii ani.
Core Web Vitals sunt factor de ranking în Google? Ce spune oficial Search Central
Google declară explicit, în documentația Search Central, că semnalele de experiență a paginii, inclusiv Core Web Vitals, „se aliniază cu ceea ce sistemele noastre de ranking de bază urmăresc să recompenseze". Cu alte cuvinte, Core Web Vitals fac parte din contextul mai larg al experienței paginii, nu sunt un semnal izolat care „bate" relevanța conținutului.
În practică, asta înseamnă că un scor Core Web Vitals excelent nu compensează un conținut slab sau irelevant pentru intenția de căutare. În schimb, între două pagini cu relevanță similară pentru aceeași căutare, performanța tehnică poate face diferența. Nu există nicio confirmare oficială Google că Core Web Vitals ar garanta o poziție anume; nu promitem poziții garantate în Google și recomandăm tratarea oricărei astfel de promisiuni cu rezervă.
Cum verifici Core Web Vitals pentru site-ul tău: Search Console, PageSpeed Insights sau date proprii
Una dintre cele mai frecvente confuzii este diferența dintre date de teren (field data) și date de laborator (lab data). Datele de teren vin din vizite reale, prin CrUX; datele de laborator vin dintr-o simulare unică, controlată, de obicei prin Lighthouse. Cele două pot arăta scoruri diferite pentru aceeași pagină, fără ca vreuna să fie „greșită".
| Instrument | Tip de date | Cel mai util pentru |
|---|---|---|
| Search Console - raport Core Web Vitals | Teren (CrUX), grupat pe URL-uri similare | Monitorizare continuă, prioritizare pe grupuri de pagini |
| PageSpeed Insights | Teren (CrUX, fereastră de 28 zile) + laborator (Lighthouse) | Diagnostic punctual pe o singură pagină, cu recomandări concrete |
| RUM propriu (script de monitorizare instalat pe site) | Teren, în timp real, pe trafic propriu | Site-uri cu trafic redus, segmentare pe pagini/categorii specifice |
Google precizează explicit că PageSpeed Insights raportează datele de teren reale ale utilizatorilor pentru ultimele 28 de zile; dacă o pagină nu are suficient trafic pentru date proprii, instrumentul „cade" automat pe date la nivel de domeniu (origine), iar dacă nici acelea nu sunt suficiente, nu afișează deloc date reale de utilizator, ci doar rezultatul simulării Lighthouse.
Recomandarea practică: folosește raportul din Search Console pentru monitorizare constantă și prioritizare, PageSpeed Insights pentru diagnostic detaliat pe o pagină anume și un RUM propriu doar dacă site-ul are trafic insuficient pentru date CrUX relevante sau ai nevoie de segmentare fină (de exemplu, pe categorii de produse).
Cum optimizezi practic LCP, INP și CLS
Optimizarea Core Web Vitals nu este o singură acțiune, ci o serie de ajustări tehnice, fiecare legată de una dintre cele trei metrici. Mai jos sunt tacticile cu impact real, verificate ca practici standard recomandate de documentația tehnică Google pentru performanță web.
Optimizare LCP (viteza de încărcare)
- Reduce timpul de răspuns al serverului (TTFB): hosting performant, caching la nivel de server sau CDN pentru resurse statice.
- Comprimă și servește imaginile principale în format modern (WebP sau AVIF), la dimensiunea reală afișată, nu la rezoluția originală a fișierului.
- Pre-încarcă explicit elementul LCP (de exemplu imaginea principală) cu
<link rel="preload">, dacă este o resursă critică pentru prima vizualizare. - Elimină sau întârzie CSS și JavaScript care blochează randarea inițială a paginii.
- Nu aplica lazy loading pe imaginea care reprezintă elementul LCP; lazy loading este util doar pentru conținutul aflat sub prima zonă vizibilă.
Optimizare INP (capacitate de răspuns)
- Sparge sarcinile JavaScript lungi (peste 50 de milisecunde, conform standardului Long Tasks) în bucăți mai mici, pentru a nu bloca firul principal de execuție.
- Reduce volumul de JavaScript executat la încărcare; aplică code splitting și încarcă codul necesar doar atunci când este nevoie de el.
- Evită calcule grele direct în handler-ele de evenimente (click, scroll, input); mută munca suplimentară în afara firului principal, unde este posibil.
- Auditează scripturile terțe (chat live, pixeli de marketing, widget-uri) și elimină pe cele care nu aduc valoare reală, pentru că adesea sunt principala cauză a unui INP slab.
Optimizare CLS (stabilitate vizuală)
- Setează explicit dimensiunile (
width/heightsauaspect-ratio) pentru toate imaginile și clipurile video din pagină. - Rezervă spațiu fix pentru reclame, embed-uri și widget-uri înainte ca acestea să se încarce.
- Folosește
font-display: swapși pre-încarcă fonturile critice, pentru a reduce saltul vizual de la fontul de rezervă la fontul final. - Evită inserarea de conținut nou peste conținutul existent, fără spațiu rezervat în avans (bannere de cookie, notificări, formulare de abonare).
Exemplu practic: pe un magazin online cu galerie de produse, un INP slab este frecvent cauzat de un script de chat sau de un pixel de remarketing încărcat sincron, care blochează firul principal exact când utilizatorul dă click pe „adaugă în coș". Întârzierea încărcării acelui script până după interacțiunea inițială poate aduce o îmbunătățire vizibilă, fără să elimini funcționalitatea.
Există și un trade-off real: o galerie foto mare, cu multe imagini de înaltă rezoluție, ajută la conversie pe un site de eCommerce, dar poate încărca LCP dacă nu este optimizată corect. Soluția nu este eliminarea galeriei, ci optimizarea formatului, dimensiunii și ordinii de încărcare a imaginilor.
Greșeli frecvente când optimizezi Core Web Vitals și cum le eviți
- Optimizezi doar scorul Lighthouse (laborator), fără să verifici datele de teren din Search Console → mitigare: confirmă orice optimizare și cu date reale de utilizatori, nu doar cu un test izolat.
- Aplici lazy loading pe imaginea LCP, întârziind exact elementul care ar trebui încărcat prioritar → mitigare: marchează explicit elementul LCP ca prioritar, nu ca „lazy".
- Testezi doar pe desktop, deși majoritatea traficului poate fi mobil → mitigare: verifică separat scorurile pe mobil și pe desktop, pentru că pragurile se evaluează independent.
- Ignori INP pentru că „nu poate fi testat în laborator" → mitigare: folosește date de teren (Search Console, CrUX, RUM propriu) special pentru INP, nu te baza doar pe Lighthouse pentru această metrică.
- Acumulezi scripturi terțe fără audit periodic (chat, pixeli, widget-uri de recenzii) → mitigare: revizuiește trimestrial scripturile active și elimină pe cele neutilizate sau cu impact redus.
- Iei decizii tehnice pe baza unor afirmații nesursate despre „actualizări 2026" → mitigare: verifică direct în documentația oficială Google (Search Central, web.dev) înainte de a schimba strategia tehnică pe baza unui articol extern.
Plan practic de optimizare Core Web Vitals în 30-60-90 de zile
Optimizarea Core Web Vitals este un proces continuu, nu un proiect cu final fix. Planul de mai jos este orientativ și trebuie adaptat după dimensiunea și complexitatea tehnică a site-ului.
Primele 30 de zile: diagnostic
- Verifică raportul Core Web Vitals din Search Console, separat pe mobil și desktop.
- Rulează PageSpeed Insights pe paginile cu cel mai mare trafic (pagina principală, categorii sau servicii principale, paginile de produs cele mai vizitate).
- Identifică, pentru fiecare pagină problematică, care dintre LCP, INP sau CLS este sub prag.
- Listează scripturile terțe active și resursele care blochează randarea inițială.
Zilele 31-60: optimizări tehnice
- Optimizează imaginile principale (format, dimensiune, preload pentru elementul LCP).
- Elimină sau întârzie scripturile terțe fără valoare directă pentru utilizator.
- Setează dimensiuni explicite pentru imagini, video, reclame și embed-uri.
- Aplică code splitting și reduce JavaScript-ul executat la încărcarea inițială.
Zilele 61-90: măsurare și consolidare
- Compară din nou raportul Core Web Vitals din Search Console față de luna inițială.
- Verifică dacă optimizările au îmbunătățit și conversiile sau timpul petrecut pe site, nu doar scorurile tehnice.
- Documentează modificările aplicate, pentru a putea reveni rapid dacă o actualizare viitoare a site-ului reintroduce o regresie de performanță.
- Stabilește un audit trimestrial de performanță, integrat în rutina obișnuită de mentenanță.
Ce s-a schimbat real la Core Web Vitals și ce afirmații despre „actualizări 2026" nu sunt confirmate
Singura schimbare majoră, oficială, confirmată de Google în ultimii ani este înlocuirea FID cu INP, la 12 martie 2024. În rest, pragurile pentru LCP (2,5 secunde), INP (200 milisecunde) și CLS (0,1) rămân cele descrise mai sus, conform documentației oficiale verificate direct la data acestui articol.
În cercetarea pentru acest ghid am analizat peste 15 articole publicate recent despre „Core Web Vitals 2026", majoritatea pe bloguri de agenții sau platforme de conținut SEO. O parte dintre ele afirmă lucruri precum o reducere a pragului „bun" pentru LCP la 2,0 secunde printr-o pretinsă „actualizare din martie 2026" sau apariția unei a patra metrici, numită generic „Visual Stability Index". Nicio sursă oficială Google (Search Central, web.dev, Search Console Help) verificată direct pentru acest articol nu confirmă aceste afirmații. Mai multe dintre articolele respective conțin și statistici de adopție contradictorii între ele, fără citare a unei surse primare verificabile.
Recomandarea practică este simplă: când citești despre o presupusă schimbare majoră la Core Web Vitals, verifică direct în documentația Google Search Central sau pe web.dev înainte să schimbi strategia tehnică a site-ului pe baza unui singur articol extern, indiferent cât de recent pare.
FAQ - Core Web Vitals 2026
1. Ce este Core Web Vitals, în câteva cuvinte?
Core Web Vitals este un set de trei metrici Google — LCP, INP și CLS — care măsoară viteza de încărcare, capacitatea de răspuns la interacțiuni și stabilitatea vizuală a unei pagini web, pe baza unor date reale de la utilizatori.
2. Core Web Vitals sunt obligatorii pentru a apărea în Google?
Nu. Un site poate fi indexat și poate apărea în rezultate fără să treacă toate pragurile „bun". Core Web Vitals fac parte din semnalele de experiență a paginii, nu sunt o condiție de indexare.
3. De ce am scoruri diferite în PageSpeed Insights și în Search Console?
PageSpeed Insights combină date de teren (28 de zile) cu o simulare de laborator pentru o singură pagină, iar Search Console arată date de teren agregate pe grupuri de URL-uri similare. Diferențele sunt normale și nu înseamnă că unul dintre rapoarte este greșit.
4. Cât de des ar trebui verificate Core Web Vitals?
Orientativ, o verificare lunară este suficientă pentru majoritatea site-urilor, plus o verificare suplimentară imediat după lansarea unei modificări majore de design, temă sau funcționalitate.
5. Optimizarea Core Web Vitals garantează creșterea poziției în Google?
Nu. Performanța tehnică bună susține relevanța conținutului, dar nu o înlocuiește. Google nu confirmă oficial nicio poziție garantată pe baza scorurilor Core Web Vitals.
6. INP înlocuiește complet vechiul FID din toate rapoartele?
Da, oficial, de la 12 martie 2024. FID a fost eliminat ca Core Web Vital, iar INP este metrica de referință pentru capacitatea de răspuns la interacțiuni în toate instrumentele actuale Google.
Concluzie
Core Web Vitals 2026 înseamnă, în continuare, optimizarea corectă a LCP, INP și CLS, verificată cu date de teren reale, nu doar cu un test izolat de laborator. Un plan de optimizare în 30-60-90 de zile, bazat pe diagnostic corect și pe surse oficiale verificate, aduce rezultate măsurabile atât pentru SEO tehnic, cât și pentru experiența reală a utilizatorilor.
Ai probleme de indexare sau de viteză a site-ului? Vezi serviciile noastre de SEO, exemple din portofoliu sau citește și ghidul introductiv SEO și articolul despre investiția pe termen lung în SEO pentru context general. Pentru un audit tehnic personalizat, scrie-ne pe pagina de contact.
Imagine generată cu AI, folosită în scop ilustrativ.
Scrie un comentariu