Fundamente

Core Web Vitals 2026: Pragurile LCP, INP și CLS explicate

Core Web Vitals rămân un semnal de clasare Google confirmat în 2026. Acest ghid detaliază pragurile exacte LCP, INP și CLS, ce cauzează erori și cele mai rapide soluții pentru a atinge scoruri „Bune”.

De Daniel MercerPublicat pe 24 mai 20268 min de citit

Core Web Vitals sunt cele trei valori de experiență a utilizatorului de la Google, folosite ca semnal de clasare. În 2026, valorile sunt LCP (Largest Contentful Paint), INP (Interaction to Next Paint) și CLS (Cumulative Layout Shift). Atingerea pragului „Bun” la toate cele trei se corelează direct cu o vizibilitate mai bună în căutare și rate de respingere mai mici.

Ce sunt Core Web Vitals?#

Core Web Vitals sunt un subset al semnalelor Page Experience de la Google. Fiecare valoare cuantifică o dimensiune distinctă a modului în care utilizatorii reali percep o pagină: viteza de încărcare, capacitatea de reacție la interacțiune și stabilitatea vizuală. Google le măsoară folosind datele colectate de la utilizatorii Chrome și afișează rezultatele în Search Console, PageSpeed Insights și Chrome UX Report (CrUX).

Care este pragul LCP în 2026?#

LCP măsoară cât timp durează ca cel mai mare element de conținut vizibil – de obicei o imagine principală, un bloc text mare sau un poster video – să se afișeze pe ecran. Pragurile sunt:

Bun: ≤ 2,5 secunde
Necesită îmbunătățiri: 2,5 s – 4,0 s
Slab: > 4,0 secunde

Aceste praguri nu s-au schimbat de când LCP a intrat în Core Web Vitals, iar Google nu a semnalat nicio revizuire pentru 2026. Limita de 2,5 secunde este intenționat agresivă: împinge site-urile să ofere imagini optimizate, să utilizeze un CDN rapid și să elimine resursele care blochează redarea.

Ce cauzează un LCP lent?

Cele mai comune cauze pentru un LCP lent sunt:

Imagini principale neoptimizate – PNG-uri sau JPEG-uri mari, oferite fără formate moderne, precum WebP sau AVIF.
Resurse care blochează redarea – scripturi sincrone sau CSS care întârzie prima afișare a browserului.
Răspuns lent al serverului (TTFB) – un Time to First Byte peste ~600 ms consumă direct din timpul LCP.
Încărcarea leneșă a elementului LCP – loading="lazy" pe imaginea principală amână cel mai important element.
Fără sugestie de preîncărcare – neutilizarea <link rel="preload"> pentru imaginea LCP.

Cum se remediază LCP

Identificați elementul LCP folosind PageSpeed Insights sau secțiunea „Largest Contentful Paint” din Chrome DevTools.
Convertiți imaginea în WebP sau AVIF și oferiți-o la dimensiunea de afișare corectă.
Adăugați <link rel="preload" as="image"> pentru imaginea LCP în <head>.
Treceți la o găzduire sau un CDN cu un TTFB sub 200 ms la percentila 75.
Eliminați sau amânați orice scripturi care blochează redarea deasupra foldului.

Care este pragul INP în 2026?#

INP a înlocuit First Input Delay (FID) ca Core Web Vital în martie 2024 și rămâne valoarea interactivității în 2026. INP măsoară latența tuturor interacțiunilor utilizatorului – clicuri, atingeri și evenimente de la tastatură – pe tot parcursul ciclului de viață al paginii, apoi raportează cea mai proastă valoare la percentila 98.

Bun: ≤ 200 milisecunde
Necesită îmbunătățiri: 201 ms – 500 ms
Slab: > 500 milisecunde

Spre deosebire de FID, care măsura doar prima interacțiune, INP penalizează orice interacțiune lentă în timpul unei vizite. Acest lucru îl face mult mai reprezentativ pentru frustrările reale ale utilizatorilor.

Ce cauzează un INP ridicat?

Task-uri lungi pe firul principal – JavaScript care blochează firul principal pentru mai mult de 50 ms întârzie procesarea intrărilor.
Handleri de evenimente grei – ascultători onClick sau onChange care declanșează actualizări DOM costisitoare.
Scripturi terțe – instrumente de analiză, widget-uri de chat și scripturi de anunțuri care concurează pentru timpul firului principal.
Costul de hidratare în SPA-uri – site-uri React, Vue sau Angular care rehidratează arbori de componente mari la încărcare.

Cum se remediază INP

Deschideți Chrome DevTools → panoul Performance → înregistrare o interacțiune și identificați task-urile lungi.
Împărțiți task-urile lungi în bucăți mai mici folosind scheduler.yield() sau setTimeout(..., 0) pentru a ceda browserului.
Auditați scripturile terțe cu panourile Coverage și Network; amânați sau eliminați cele non-critice.
Utilizați startTransition (React) sau API-uri de framework echivalente pentru a deprioritiza actualizările de stare non-urgente.
Reduceți dimensiunea DOM – paginile cu zeci de mii de noduri au o recalculare mai lentă a stilurilor după fiecare interacțiune.

Care este pragul CLS în 2026?#

CLS măsoară schimbările vizuale neașteptate – elemente care sar în timp ce pagina se încarcă. Este notat ca un agregat fără unități al tuturor modificărilor de aspect care nu sunt cauzate de introducerea utilizatorului.

Bun: ≤ 0,1
Necesită îmbunătățiri: 0,1 – 0,25
Slab: > 0,25

Un CLS de 0,1 poate suna abstract, dar în practică înseamnă că impactul combinat al modificărilor trebuie să fie mic în raport cu fereastra de vizualizare. Un singur banner mare sau o imagine fără dimensiuni poate împinge instantaneu o pagină în banda „Slab”.

Ce cauzează un CLS ridicat?

Imagini fără atribute width și height – browserul nu poate rezerva spațiu înainte de încărcarea imaginii.
Conținut injectat dinamic – reclame, bannere cookie sau pop-up-uri de newsletter care împing conținutul în jos.
Fonturi web care cauzează FOUT/FOIT – schimbări de fonturi care modifică lungimea liniilor și rearanjează blocurile de text.
Încărcări întârziate – iframe-uri pentru YouTube sau Twitter care nu au un container cu raport de aspect rezervat.

Cum se remediază CLS

Specificați întotdeauna width și height pe etichetele <img> sau utilizați aspect-ratio în CSS.
Rezervați spațiu pentru sloturile de anunțuri cu un container de înălțime minimă chiar înainte de încărcarea anunțului.
Utilizați font-display: optional sau preîncărcați fonturile web critice pentru a preveni schimburile întârziate.
Înfășurați iframe-urile într-un container CSS cu raport de aspect (truc padding-top sau aspect-ratio: 16/9).
Evitați inserarea de conținut deasupra conținutului existent după încărcarea inițială.

Cum sunt măsurate Core Web Vitals?#

Google folosește date de teren (măsurători de la utilizatori reali din CrUX) ca semnal de clasare, nu date de laborator. PageSpeed Insights le arată pe ambele, dar numai datele de teren afectează clasările. O pagină trebuie să treacă toate cele trei valori la percentila 75 de încărcări ale paginii pentru a fi considerată „Bună” pentru Page Experience.

Instrumentele de laborator – Lighthouse, WebPageTest – sunt de neprețuit pentru diagnosticare, dar nu pot înlocui datele CrUX. Dacă CrUX are trafic insuficient pentru un URL, Google cumulează la nivel de origine.

Cum se monitorizează Core Web Vitals la scară#

Pentru site-uri cu sute sau mii de pagini, verificarea manuală este nepractică. Abordarea corectă:

Search Console → raportul Core Web Vitals – vizualizare grupată a URL-urilor Bune/Necesită îmbunătățiri/Slab pe valoare.
CrUX API sau BigQuery – extrageți date de teren brute programatic pentru tablouri de bord personalizate.
Real User Monitoring (RUM) – biblioteci precum web-vitals.js trimit LCP, INP și CLS de la sesiuni reale la analiza dvs.
Audituri automatizate – instrumente precum SeoChatAI pot scoate la iveală probleme Core Web Vitals alături de audituri tehnice SEO, de accesibilitate și de pregătire AI, dintr-o singură trecere.

Trecerea de Core Web Vitals garantează o clasare mai bună?#

Trecerea tuturor celor trei valori la pragul „Bun” este o condiție necesară, dar nu suficientă pentru primele clasări. Core Web Vitals sunt un semnal de departajare: atunci când calitatea, relevanța și autoritatea conținutului sunt egale, pagina cu semnale de experiență mai bune va fi clasată mai sus. Google nu a dezvăluit niciodată ponderea exactă, dar semnalul este real și documentat în documentația sistemelor lor de clasare.

Concluzia practică: remediați Core Web Vitals pentru a elimina un prag minim de clasare, apoi concentrați-vă pe conținut și autoritate pentru a-l depăși.

Core Web Vitals și căutarea AI în 2026#

Pe măsură ce prezentările generale generate de AI (fostul SGE) apar acum în rezultatele Google Search, semnalele de experiență a paginii influențează dacă o pagină este citată ca sursă. Paginile care sunt lente, vizual instabile sau care nu răspund sunt mai puțin susceptibile de a fi prezentate. Rularea unui audit complet al site-ului prin SeoChatAI vă oferă o vizualizare combinată a scorurilor dvs. CWV, a pregătirii datelor structurate și a eligibilității pentru citarea AI – care este din ce în ce mai relevantă pe măsură ce motoarele de răspuns AI depășesc clicurile tradiționale pe linkuri albastre.

Referință rapidă: praguri Core Web Vitals 2026#

Valoare	Bun	Necesită îmbunătățiri	Slab
LCP	≤ 2,5 s	2,5 s – 4,0 s	> 4,0 s
INP	≤ 200 ms	201 ms – 500 ms	> 500 ms
CLS	≤ 0,1	0,1 – 0,25	> 0,25

Toate pragurile se aplică la percentila 75 a datelor de teren. O singură pagină cu un număr de încărcări foarte lente poate trage agregatul în teritoriul „Slab” – motiv pentru care monitorizarea la nivel de percentile contează mai mult decât scorurile mediane.

Core Web Vitals 2026: LCP, INP, and CLS Thresholds Explained — illustration 1

Distribuiți acest articolX LinkedIn

Publicat pe 24 mai 2026

Întrebări frecvente

Care sunt pragurile Core Web Vitals în 2026?

În 2026, pragurile „Bune” sunt: LCP ≤ 2,5 secunde, INP ≤ 200 milisecunde și CLS ≤ 0,1. Toate trei sunt măsurate la percentila 75 a datelor de teren de la utilizatori reali. Paginile trebuie să le treacă pe toate trei pentru a fi considerate „Bune” pentru semnalul Page Experience de la Google.

A înlocuit Google FID cu INP?

Da. Google a înlocuit oficial First Input Delay (FID) cu Interaction to Next Paint (INP) în martie 2024. INP măsoară latența tuturor interacțiunilor în timpul unei vizite pe pagină, nu doar a primei, făcându-l o valoare mai cuprinzătoare și reprezentativă a capacității de reacție.

Îmbunătățește trecerea de Core Web Vitals clasările Google?

Trecerea de Core Web Vitals elimină un prag minim de clasare, mai degrabă decât să garanteze poziții de top. Google folosește semnalul ca o departajare între paginile cu o calitate și relevanță similară a conținutului. Eșecul CWV poate suprima clasările; trecerea lor deblochează greutatea completă a semnalelor dvs. de conținut și autoritate.

Cum îmi verific scorul Core Web Vitals?

Utilizați raportul Core Web Vitals al Google Search Console pentru datele de teren grupate după URL. PageSpeed Insights arată atât date de laborator, cât și date de teren pentru paginile individuale. Pentru monitorizarea utilizatorilor reali pe toate paginile, implementați biblioteca web-vitals.js sau utilizați o platformă care cumulează automat datele CrUX.

De ce este LCP-ul meu lent, chiar dacă imaginile mele sunt optimizate?

Imaginile optimizate sunt necesare, dar nu suficiente. Cauzele comune trecute cu vederea includ un TTFB lent (răspunsul serverului peste ~600 ms), aplicarea încărcării leneșe imaginii LCP în sine, lipsa unei sugestii de preîncărcare în antetul HTML și scripturile care blochează redarea și întârzie momentul în care browserul poate începe chiar să preia imaginea.

Ce este un scor INP bun și cum îl pot reduce?

Un INP la sau sub 200 ms este „Bun”. Pentru a reduce INP, împărțiți task-urile JavaScript lungi în bucăți mai mici folosind scheduler.yield(), auditați și amânați scripturile terțe, minimizați dimensiunea DOM și utilizați API-uri de framework, precum startTransition al React, pentru a deprioritiza actualizările UI non-urgente.

Afectează CLS paginile care se încarcă rapid?

Da. CLS este independent de viteza de încărcare. O pagină poate atinge un LCP rapid, dar totuși să aibă un CLS slab dacă imaginile nu au atribute de dimensiune, reclamele injectează conținut deasupra foldului sau fonturile web determină rearanjarea textului. Stabilitatea vizuală trebuie abordată separat de optimizările timpului de încărcare.