Core Web Vitals — Ce Sunt și Cum Le Optimizezi în 2026

Core Web Vitals sunt un set de trei metrici de performanță definite de Google care măsoară experiența reală a utilizatorilor pe website-ul tău. Din martie 2024, aceste metrici includ LCP (Largest Contentful Paint), INP (Interaction to Next Paint) și CLS (Cumulative Layout Shift). Nu sunt doar numere tehnice — sunt factori direcți de ranking în Google și determină dacă vizitatorii rămân pe site sau pleacă.

În acest ghid, vom explica fiecare metrică, de ce contează, cum o măsori și — cel mai important — cum o optimizezi concret, cu exemple practice.

De ce contează Core Web Vitals în 2026

Google folosește Core Web Vitals ca parte a semnalului Page Experience pentru ranking. Impactul este real și măsurabil:

• 23% mai mult trafic pierdut pentru website-urile cu LCP slab (conform studiilor din decembrie 2025)
• 31% mai mult trafic pierdut pentru website-urile cu INP slab
• 19% mai mult trafic pierdut pentru website-urile cu CLS slab
• 43% din website-uri încă nu trec pragul INP — o oportunitate enormă pentru cei care optimizează

Pe scurt: un website rapid și stabil are un avantaj competitiv real în rezultatele Google față de concurența lentă.

Cele 3 metrici Core Web Vitals explicate

1. LCP — Largest Contentful Paint

Ce măsoară: Cât de repede se încarcă cel mai mare element vizibil din viewport (de obicei o imagine hero, un titlu mare sau un bloc de text principal).

Praguri:

• Bun: ≤ 2.5 secunde
• Necesită îmbunătățire: 2.5 – 4.0 secunde
• Slab: > 4.0 secunde

De ce contează: LCP reflectă percepția utilizatorului despre cât de repede se încarcă pagina. Dacă elementul principal apare după 4 secunde, utilizatorul simte că site-ul este lent — chiar dacă restul paginii s-a încărcat deja.

2. INP — Interaction to Next Paint

Ce măsoară: Cât de repede răspunde pagina la interacțiunile utilizatorului (click-uri, tap-uri, apăsări de taste). INP a înlocuit FID (First Input Delay) în martie 2024 și este considerabil mai exigent.

Praguri:

• Bun: ≤ 200 milisecunde
• Necesită îmbunătățire: 200 – 500 milisecunde
• Slab: > 500 milisecunde

Diferența față de FID: FID măsura doar întârzierea primei interacțiuni. INP măsoară toate interacțiunile de-a lungul întregii sesiuni și raportează cea mai slabă (cu o ajustare statistică). Este mult mai greu de optimizat, de aceea 43% din website-uri încă nu trec pragul.

Cele 3 faze ale INP:

1. Input Delay — timpul de așteptare până când browser-ul începe să proceseze interacțiunea (cauzat de task-uri JavaScript care blochează thread-ul principal)
2. Processing Time — timpul de execuție al event handler-elor (codul JavaScript care rulează ca răspuns la interacțiune)
3. Presentation Delay — timpul necesar pentru ca browser-ul să calculeze layout-ul și să afișeze rezultatul vizual

3. CLS — Cumulative Layout Shift

Ce măsoară: Cât de mult se mută elementele pe pagină în mod neașteptat — de exemplu, un buton care sare în jos când se încarcă o reclamă deasupra lui.

Praguri:

• Bun: ≤ 0.1
• Necesită îmbunătățire: 0.1 – 0.25
• Slab: > 0.25

De ce contează: CLS este poate cea mai frustrantă problemă pentru utilizatori. Ai încercat vreodată să apeși pe un buton, dar exact în acel moment pagina s-a mutat și ai apăsat pe altceva? Exact asta măsoară CLS.

Cum măsori Core Web Vitals

Există două tipuri de măsurători:

Date de laborator (Lab Data)

Simulate de un instrument, în condiții controlate. Utile pentru debugging și dezvoltare:

• PageSpeed Insights (pagespeed.web.dev) — cel mai popular, oferă și date reale și simulate
• Lighthouse — integrat în Chrome DevTools (tab-ul Performance)
• WebPageTest — teste avansate cu locații multiple și condiții de rețea variabile

Date de teren (Field Data / RUM)

Măsurători reale de la utilizatori adevărați. Acestea sunt cele care contează pentru Google:

• Google Search Console — raportul Core Web Vitals arată performanța pe URL-uri grupate
• Chrome UX Report (CrUX) — baza de date publică cu date agregate de la utilizatorii Chrome
• DebugBear / SpeedCurve — monitorizare continuă cu alerte

Important: Google folosește percentila 75 din datele de teren (p75). Asta înseamnă că 75% din vizitele pe pagina ta trebuie să fie sub prag. Nu media, nu mediana — percentila 75.

Cum optimizezi LCP — pas cu pas

LCP depinde de 4 sub-componente. Optimizează-le pe rând:

1. Reduce TTFB (Time to First Byte)

Primul byte al răspunsului trebuie să ajungă cât mai repede la browser:

• Folosește un CDN — servește conținutul de la un server aproape de utilizator (Cloudflare, Bunny CDN, CloudFront)
• Activează caching-ul — seturi corecte de headere Cache-Control pe server
• Optimizează backend-ul — query-uri SQL lente, lipsa caching-ului pe server, lipsa OPcache (PHP)
• Folosește HTTP/2 sau HTTP/3 — multiplexare de conexiuni, compresie headere

2. Optimizează imaginile (cel mai frecvent element LCP)

• Format modern: folosește WebP sau AVIF în loc de JPEG/PNG (reducere 25-50% din dimensiune)
• Imagini responsive: atributul srcset cu dimensiuni multiple, nu o singură imagine mare
• Preload imaginea LCP: <link rel="preload" as="image" href="hero.webp" fetchpriority="high">
• fetchpriority="high" pe elementul <img> LCP — spune browser-ului să-l prioritizeze
• Evită lazy loading pe imaginea LCP — loading="lazy" întârzie exact elementul care trebuie să se încarce primul
• Specifică width și height — permite browser-ului să rezerve spațiu înainte de încărcare

3. Optimizează fonturile

• font-display: swap — afișează textul imediat cu un font fallback, apoi înlocuiește când fontul custom se încarcă
• Preload fonturile critice: <link rel="preload" as="font" type="font/woff2" href="font.woff2" crossorigin>
• Self-host fonturile în loc de Google Fonts — elimină un DNS lookup și o conexiune HTTP suplimentară

4. Elimină resursele care blochează randarea

• CSS critic inline — pune CSS-ul necesar pentru above-the-fold direct în <head>
• Defer JavaScript: <script defer> sau <script type="module">
• Elimină CSS nefolosit — fiecare KB de CSS trebuie parsat înainte de prima afișare

Cum optimizezi INP — pas cu pas

INP este metrica cea mai dificilă. Trebuie să optimizezi fiecare din cele 3 faze:

1. Reduce Input Delay

Input Delay apare când thread-ul principal este ocupat cu alte task-uri JavaScript când utilizatorul interacționează:

• Sparge task-urile lungi — un task JavaScript care durează > 50ms blochează interacțiunile. Folosește scheduler.yield() sau setTimeout() pentru a împărți munca în bucăți mici
• Reduce JavaScript-ul third-party — analytics, chat widgets, reclame adaugă sute de KB de JS care rulează pe thread-ul principal
• Amână scripturile non-critice — încarcă doar ce este necesar pentru interacțiunea curentă

2. Reduce Processing Time

Optimizează codul care rulează ca răspuns la interacțiune:

• Evită re-render-uri inutile — în React/Vue, folosește useMemo, useCallback, React.memo
• Debounce event handlers — nu procesa fiecare keystroke, așteaptă 150-300ms
• Mută calculele grele în Web Workers — procesare off-thread care nu blochează UI-ul
• Virtualizează listele lungi — nu randa 1000 de rânduri în DOM dacă utilizatorul vede doar 20

3. Reduce Presentation Delay

Minimizează munca browser-ului după procesare:

• Reduce dimensiunea DOM-ului — un DOM cu > 1500 de noduri încetinește layout-ul și painting-ul
• Evită layout thrashing — nu citi și scrie alternativ proprietăți de layout (offsetHeight, scrollTop)
• Folosește CSS containment — contain: layout limitează zona afectată de recalculările de layout
• Preferă transform și opacity pentru animații — sunt procesate de GPU, nu de CPU

Cum optimizezi CLS — pas cu pas

CLS este de obicei cea mai ușor de rezolvat, dar necesită atenție la detalii:

1. Specifică dimensiunile pe imagini și video

• Adaugă întotdeauna width și height pe <img> și <video>
• Folosește aspect-ratio în CSS — aspect-ratio: 16/9 rezervă spațiu proporțional
• Container cu dimensiuni fixe — învelește elementele media într-un div cu dimensiuni cunoscute

2. Gestionează fonturile corect

• font-display: swap previne text invizibil, dar poate cauza un mic CLS când fontul se schimbă
• font-display: optional — varianta ideală: folosește fontul custom doar dacă e deja în cache, altfel rămâne pe fallback (zero CLS)
• Alege un font fallback cu metrici similare — size-adjust, ascent-override, descent-override în CSS

3. Rezervă spațiu pentru conținut dinamic

• Reclame: definește min-height pe containerul de reclame înainte de încărcare
• Embeds (iframe): specifică width și height pe <iframe>
• Notificări / bannere: nu împinge conținutul în jos — folosește position: fixed sau position: sticky

4. Evită inserția de conținut deasupra conținutului existent

• Cookie banners: overlay peste pagină, nu insert înainte de conținut
• Lazy-loaded content: placeholder cu dimensiuni identice cu conținutul final
• Web fonts: încarcă stilurile CSS înainte de scripturi — ordinea în <head> contează

Checklist rapid de optimizare

Folosește acest checklist pentru a verifica rapid ce ai de optimizat:

Metrică	Acțiune	Impact
LCP	Comprimă imaginile în WebP/AVIF	Ridicat
LCP	Preload imaginea hero cu fetchpriority="high"	Ridicat
LCP	Activează CDN	Ridicat
LCP	Self-host fonturile cu font-display: swap	Mediu
INP	Sparge task-urile JS lungi (> 50ms)	Ridicat
INP	Reduce JavaScript third-party	Ridicat
INP	Virtualizează listele lungi	Mediu
INP	Folosește Web Workers pentru calcule grele	Mediu
CLS	Adaugă width/height pe toate imaginile	Ridicat
CLS	Rezervă spațiu pentru reclame și embeds	Ridicat
CLS	Folosește font-display: optional	Mediu
CLS	Nu insera conținut deasupra fold-ului	Mediu

Instrumente de măsurare recomandate

Instrument	Tip date	Cost	Când îl folosești
PageSpeed Insights	Lab + Field	Gratuit	Verificare rapidă, prima analiză
Google Search Console	Field	Gratuit	Monitorizare continuă, probleme pe grupuri de URL-uri
Lighthouse (Chrome DevTools)	Lab	Gratuit	Debugging detaliat, dezvoltare locală
WebPageTest	Lab	Gratuit	Teste avansate, comparații între locații
DebugBear	Lab + Field	Plătit	Monitorizare automată cu alerte
Chrome UX Report (CrUX)	Field	Gratuit	Date agregate pentru orice website cu trafic suficient

Greșeli frecvente de evitat

• Optimizezi doar pentru Lighthouse: Scorul Lighthouse este laborator. Google folosește datele de teren (CrUX). Un scor de 100 în Lighthouse nu garantează Core Web Vitals bune în producție
• Lazy loading pe imaginea LCP: Cel mai frecvent anti-pattern. loading="lazy" pe elementul LCP îl întârzie semnificativ
• Ignori INP: 43% din website-uri eșuează la INP. Este noua metrică (din martie 2024) și mulți dezvoltatori încă nu o optimizează
• Măsori doar pe desktop: Google folosește indexarea mobile-first. Core Web Vitals pe mobil sunt cele care contează pentru ranking
• Font-uri multiple neoptimizate: Fiecare font custom adaugă latență. Limitează-te la 1-2 familii de fonturi și preload-ează varianta critică

Concluzie: Core Web Vitals nu sunt opționale

În 2026, Core Web Vitals sunt un factor de ranking confirmat și în creștere. Website-urile care ignoră LCP, INP și CLS pierd trafic organic în favoarea competitorilor care le optimizează. Vestea bună: cele mai mari câștiguri vin din optimizări simple — compresie imagini, dimensiuni explicite, reducerea JavaScript-ului inutil.

Nu trebuie să fii expert în performanță web. Începe cu o măsurare (PageSpeed Insights sau Google Search Console), identifică cele mai mari probleme și rezolvă-le pe rând, în ordinea impactului.

Vrei să vezi cum stă website-ul tău la Core Web Vitals și la alte 100+ verificări de performanță, securitate și SEO?

Rulează un audit gratuit pe SoftAudit.ro și primești un raport complet în câteva secunde.