Dacă ai rulat vreodată PageSpeed Insights pe site-ul tău și ai primit o grămadă de cifre și termeni pe care nu i-ai înțeles, ești în locul potrivit. Core Web Vitals sunt acei indicatori care îi spun Google cât de bine se comportă site-ul tău în lumea reală — nu în teorie, nu în laborator, ci pe telefoanele și laptopurile utilizatorilor tăi reali.

Și da, contează pentru SEO. Nu teoretic — factual. Google a confirmat că performanța paginii este factor de ranking din 2021, iar în 2026 standardele sunt mai stricte ca oricând.

Dacă vrei să înțelegi ce este SEO și cum funcționează la nivel fundamental înainte de a intra în tehnic, am un ghid dedicat care îți explică fundațiile.

Ce sunt Core Web Vitals și de ce le pasă Google

Core Web Vitals sunt un set de trei metrici de performanță definite de Google pentru a cuantifica experiența utilizatorilor pe web. Nu sunt metrici inventate de ingineri pentru ingineri — sunt indicatori care corelează direct cu comportamentul real al utilizatorilor: dacă pagina se încarcă repede, dacă răspunde rapid la interacțiuni și dacă elementele nu sar pe ecran în timp ce cineva încearcă să citească sau să cumpere ceva.

Cele trei metrici Core Web Vitals în 2026:

Graficul de mai jos compară pragurile oficiale Google (verde = bun) cu mediile reale înregistrate pe site-urile românești auditate de noi în Q1 2026. Datele proprii sunt scoruri editoriale Omubo bazate pe audituri interne, Q1 2026.

Notă editorială:

Sursa pragurilor: Google Web Vitals, web.dev/vitals, 2026. Mediile “România Q1 2026” reprezintă scoruri editoriale Omubo bazate pe audituri de performanță efectuate în Q1 2026, nu date statistice naționale.

⚠️ Important: Cele trei metrici au unități diferite (secunde, milisecunde, scor 0–1) — chart-ul este pentru comparație relativă prag vs. medie, nu pentru comparație directă între metrici.

Google colectează aceste date real din milioane de sesiuni reale prin CrUX (Chrome User Experience Report) — nu din teste artificiale. Asta înseamnă că scorul tău reflectă experiența utilizatorilor tăi actuali, pe conexiunile și dispozitivele lor reale.

Vestea mai puțin bună: dacă nu cunoști aceste metrici, concurenții care le optimizează te depășesc în căutări — chiar dacă conținutul tău e mai bun.

INP: Noul metric care a înlocuit FID din 2024

INP (Interaction to Next Paint) este schimbarea cea mai importantă din Core Web Vitals în ultimii doi ani, și mulți proprietari de site-uri încă nu știu că FID (First Input Delay) nu mai există oficial din martie 2024.

Ce măsoară INP

INP urmărește latența fiecărei interacțiuni a utilizatorului cu pagina — orice click, tap pe mobil sau apăsare de tastă — pe întreaga durată a sesiunii. Scorul final raportat este cel mai mare percentil 98 al tuturor interacțiunilor înregistrate.

Pe scurt: INP îți penalizează cel mai lent moment al sesiunii, nu doar primul. Dacă un utilizator dă click pe un buton de filtrare după 30 de secunde de navigare și pagina îngheață 800ms, aceea e o problemă INP — indiferent că restul paginii a fost rapid.

De ce e mai strict decât FID

FID măsura doar prima interacțiune și doar input delay-ul (cât durează browserul să înceapă să proceseze). INP măsoară întreaga durată a interacțiunii (processing + rendering) pentru toate interacțiunile din sesiune.

Rezultatul: site-uri care aveau FID bun pot eșua la INP. Aplicațiile cu JavaScript complex, filtre de produse, selectoare de date sau animații interactive sunt primele afectate.

Praguri INP în 2026

• Sub 200ms → Bun ✅
• 200–500ms → Necesită îmbunătățiri ⚠️
• Peste 500ms → Slab ❌

Cauzele comune ale INP slab

Long Tasks JavaScript — Taskuri JS care durează peste 50ms blochează main thread-ul și amână răspunsul la interacțiuni. Pe un WordPress cu 15 plugin-uri fiecare cu propriul JS, acumularea devine rapid vizibilă.

Long Animation Frames (LoAF) — Cadre de animație care durează prea mult, introduse în Chrome 116 ca instrument de diagnosticare precis pentru INP.

Input handlers blocanți — Funcții JavaScript atașate pe click sau scroll care execută calcule grele sincron înainte de a permite browser-ului să redeseneze.

Soluții practice:

• Împarte taskurile JS lungi în bucăți mai mici cu setTimeout sau scheduler.postTask()
• Elimină sau amână JS terțiar neesențial (chat widgets, heatmap scripts, marketing pixels)
• Folosește content-visibility: auto pentru secțiunile off-screen
• Auditează și elimină plugin-urile WordPress care adaugă JS inutil

LCP: De ce imaginea ta hero e probabil problema

LCP (Largest Contentful Paint) măsoară cât durează să se încarce elementul cel mai mare vizibil în viewport la momentul încărcării paginii. De obicei acest element este imaginea hero, imaginea produsului principal sau titlul H1 dacă e afișat pe un fundal solid.

Praguri LCP în 2026

• Sub 2,5 secunde → Bun ✅
• 2,5–4 secunde → Necesită îmbunătățiri ⚠️
• Peste 4 secunde → Slab ❌

Un LCP slab înseamnă că utilizatorul stă și privește o pagină albă sau incompletă prea mult timp. Pe mobil cu 4G mediu românesc, pragul de 2,5 secunde e ambițios dacă nu ești atent la câteva lucruri fundamentale.

Cele mai frecvente cauze ale LCP slab

Imagini neoptimizate — Imaginea hero de 3MB în format JPEG necomprimat e probabil cel mai comun killer de LCP pe site-urile românești. Conversia la WebP reduce dimensiunea cu 25–35% fără pierdere vizibilă de calitate.

Lipsa fetchpriority="high" — Fără această instrucțiune, browserul nu știe că imaginea hero e prioritară și o descarcă împreună cu alte zeci de resurse. Adaugă fetchpriority="high" la imaginea LCP și reducerea poate fi spectaculoasă.

Render-blocking resources — CSS și JavaScript care blochează randearea paginii înainte ca browser-ul să poată afișa elementul LCP. Fiecare resursă blocantă adaugă direct la scorul LCP.

Server response time lent (TTFB) — Time to First Byte peste 800ms sabotează LCP independent de optimizările frontend. Un hosting shared lent din România fără cache configurat poate da TTFB de 1,5–2 secunde singur — și LCP-ul tău nu poate fi niciodată mai mic decât TTFB-ul.

Lazy loading greșit aplicat — A pune loading="lazy" pe imaginea hero e o greșeală clasică. Lazy loading e pentru imaginile de mai jos în pagină — imaginea LCP trebuie să se încarce cu prioritate maximă.

Soluții pentru LCP sub 2,5s

1. Convertește toate imaginile la WebP sau AVIF
2. Adaugă fetchpriority="high" la imaginea hero
3. Elimină loading="lazy" de pe imaginea principală
4. Configurează cache server (Redis, Memcached sau plugin de cache pe WordPress)
5. Folosește un CDN — chiar și Cloudflare free tier reduce TTFB semnificativ
6. Preload-ează fonturile cu <link rel="preload" as="font">

CLS: De ce pagina ta “sare” și ce pierzi din cauza asta

CLS (Cumulative Layout Shift) măsoară instabilitatea vizuală a paginii — cât de mult se deplasează elementele pe ecran în timp ce pagina se încarcă. Dacă ai dat vreodată click pe un link și ai ajuns pe altul pentru că pagina s-a mișcat exact în acel moment, ai trăit un CLS slab.

Praguri CLS în 2026

• Sub 0,1 → Bun ✅
• 0,1–0,25 → Necesită îmbunătățiri ⚠️
• Peste 0,25 → Slab ❌

CLS slab nu doar enervează utilizatorii — pe e-commerce poate genera conversii false (click pe butonul greșit), abandonuri și recenzii negative. Pe un magazin online WooCommerce sau Shopify cu mai multe imagini de produs și bannere dinamice, CLS neoptimizat e practic garantat dacă nu ai fost atent explicit la el.

Cauzele principale ale CLS

Imagini fără dimensiuni explicite — Dacă nu specifici width și height pe imagini, browser-ul nu rezervă spațiu pentru ele în layout și le inserează abrupt când se descarcă, împingând tot conținutul de dedesubt.

html

<!-- Greșit — cauzează CLS -->
<img src="produs.webp" alt="Produs">

<!-- Corect — browser rezervă spațiu -->
<img src="produs.webp" alt="Produs" width="800" height="600">

Reclame și bannere inserate dinamic — Google Ads, bannere de tip cookie consent, chat widgets — toate inserează elemente în pagină după ce utilizatorul a început să citească. Rezervă spațiu explicit pentru ele sau inserează-le în afara flow-ului principal al documentului.

Fonturi web cu FOUT (Flash of Unstyled Text) — Dacă fontul web se încarcă după ce textul a fost randat cu fontul fallback, iar dimensiunile diferă, textul se reașează și provoacă CLS. Soluție: font-display: optional sau size-adjust pe fontul fallback.

Conținut injectat deasupra celui existent — Orice element adăugat dinamic deasupra conținutului vizibil (bannere promoționale, notificări, cookie banners) provoacă CLS dacă nu e prezent de la prima randare.

Soluții pentru CLS sub 0,1

1. Adaugă width și height pe toate imaginile
2. Rezervă spațiu pentru reclame cu min-height pe container
3. Mută cookie banner-ul în afara flow-ului (position: fixed)
4. Folosește font-display: swap cu fallback size-adjust
5. Evită inserarea de conținut deasupra zonei vizibile după load

Cum măsori Core Web Vitals — instrumente practice

Există o distincție importantă pe care mulți o ignoră: date de laborator vs. date de teren (field data).

• Date de laborator (Lab Data) — Simulate în condiții controlate. Instrumente: Lighthouse, WebPageTest. Utile pentru debugging și identificarea problemelor.
• Date de teren (Field Data / CrUX) — Colectate din sesiuni reale ale utilizatorilor reali. Acestea sunt datele pe care Google le folosește pentru ranking.

Nu optimiza exclusiv pentru date de laborator. Un scor Lighthouse de 95 pe desktop nu garantează că utilizatorii tăi pe telefoane Android mid-range din România au o experiență bună.

Instrumentul 1: PageSpeed Insights

URL: pagespeed.web.dev

PageSpeed Insights este instrumentul principal — combină date de laborator (Lighthouse) cu date reale din CrUX. Cu 1.900 de căutări lunare în România, e evident că mulți antreprenori și developeri îl folosesc deja. Dar puțini știu să citească raportul corect.

Cum să îl folosești eficient:

• Testează URL-ul de mobil întotdeauna primul — Google indexează mobile-first
• Verifică secțiunea “Field Data” (deasupra) înainte de “Lab Data”
• Dacă site-ul tău e nou sau mic, CrUX s-ar putea să nu aibă date suficiente — în acest caz vei vedea doar date de laborator

Instrumentul 2: Google Search Console

Secțiunea: Experiență → Core Web Vitals

Search Console arată datele CrUX agregate pentru toate paginile site-ului tău, grupate în “bun”, “necesită îmbunătățiri” și “slab”. E locul unde afli scara problemei — câte URL-uri sunt afectate și ce tip de problemă au.

Fluxul recomandat: Search Console identifică problema la scară → PageSpeed Insights diagnostichează pagina specifică → Lighthouse din DevTools găsește elementul exact.

Instrumentul 3: Extensia Web Vitals pentru Chrome

Instalează extensia oficială Google “Web Vitals” din Chrome Web Store. Afișează INP, LCP și CLS în timp real pe orice pagină vizitezi — inclusiv pe site-ul concurenților tăi.

Instrumentul 4: Lighthouse în Chrome DevTools

F12 → Lighthouse → Generate Report

Util pentru debugging granular. Lighthouse îți arată exact ce resurse blochează randearea, ce imagini nu sunt optimizate și ce taskuri JS sunt prea lungi. Important: rulează Lighthouse în modul Incognito pentru a elimina impactul extensiilor Chrome instalate.

Core Web Vitals și SEO — cât de mult contează în 2026

Să fim direcți cu privire la ceva care circulă confuz în comunitate: Core Web Vitals nu sunt singurul factor de ranking și nu compensează conținut slab. Un articol bine documentat cu LCP de 3,2s va bate un articol gol cu LCP de 1,8s.

Dar — și ăsta e un “dar” important — în condiții de egalitate de conținut, Core Web Vitals pot face diferența. Google folosește Page Experience ca factor de tie-breaker între pagini cu autoritate și relevanță similare.

Impactul practic în 2026:

• Site-urile cu toate cele trei metrici în zona “bun” primesc indicatorul vizual “Experiență excelentă” în Search Console
• Paginile cu CWV slab pot fi excluse din unele funcționalități de SERP (ex: Top Stories pe mobil necesita, cândva, AMP — acum necesită CWV bun)
• Pe mobil, unde Google indexează prioritar, impactul e mai mare decât pe desktop

Dacă faci un audit SEO complet al site-ului tău, Core Web Vitals ar trebui să fie prima secțiune tehnică verificată — problema de performanță blochează orice alte câștiguri SEO.

Core Web Vitals pentru WordPress și WooCommerce

WordPress alimentează aproximativ 43% din toate site-urile web la nivel global (W3Techs, 2026), iar WooCommerce e cel mai popular ecosistem de e-commerce pe WordPress. Prin urmare, o bună parte din problemele de Core Web Vitals pe care le vedem în România vin de pe site-uri WordPress.

Stack recomandat pentru CWV bun pe WordPress în 2026:

Greșeala #1 pe WordPress: Prea multe plugin-uri activi fiecare cu propriul JS și CSS. Un site cu 40 de plugin-uri active are, în medie, 15–20 surse de JS extern — unele blocante, toate contribuind la INP. Audierea și eliminarea plugin-urilor inactive sau redundante e primul pas.

Dacă te confrunți cu decizii de platformă și vrei să înțelegi mai bine impactul tehnic al alegerii între WooCommerce și alternative, articolul nostru despre optimizare performanță WooCommerce acoperă și impactul arhitecturii asupra vitezei.

Verdictul: Ce prioritizezi în 2026

Dacă trebuie să alegi ordinea de atac:

1. LCP mai întâi — Cel mai mare impact vizibil și perceptibil pentru utilizatori. Optimizarea imaginii hero + hosting/cache rezolvă de obicei 60–70% din problemă.

2. CLS al doilea — Fix rapid (adaugă dimensiuni la imagini, rezervă spațiu pentru reclame) cu impact imediat asupra experienței pe mobil.

3. INP ultimul — Cel mai complex de rezolvat, necesită debugging JavaScript, dar impactul e cel mai mare pe site-uri cu interactivitate ridicată (filtre, căutare live, coș de cumpărături).

Dacă nu ai timp sau resurse să te ocupi de acestea singur, echipa noastră de servicii SEO profesionale include audit de performanță și implementare Core Web Vitals ca parte din pachetele de optimizare.

Vrei să construiești de la zero un site optimizat pentru Core Web Vitals? Totul e mai simplu când arhitectura e gândită corect din start — nu remediat ulterior. Discuție despre o creare magazin online optimizat costă zero și îți economisește luni de remedieri.

Întrebări frecvente (FAQ)