Core Web Vitals în 2026: De Ce INP Decide Ranking-ul
LCP și CLS atrag atenția, dar Interaction to Next Paint e metrica ce decide în liniște cine rankează și cine nu. Iată ce măsoară și de ce majoritatea site-urilor pică la ea.
Aproape orice proprietar de site de business a auzit de Core Web Vitals până acum, de obicei ca un badge roșu sau verde într-un raport pe care cineva i l-a trimis fără prea multe explicații. În 2026, cele trei metrici (Largest Contentful Paint, Interaction to Next Paint și Cumulative Layout Shift) sunt semnale de ranking confirmate, măsurate direct de la vizitatori reali prin Chrome și afișate în Search Console și PageSpeed Insights. Cea la care încă pică majoritatea site-urilor nu e cea de care își face lumea griji.
Metrica ce a înlocuit FID
Interaction to Next Paint a devenit metrica oficială de responsivitate în martie 2024, înlocuind First Input Delay. FID măsura doar întârzierea înainte ca browser-ul să înceapă să răspundă la primul click sau tap de pe pagină. INP măsoară fiecare interacțiune din toată vizita și raportează cea mai lentă, ceea ce o face mult mai greu de păcălit: un site poate răspunde instant la primul click și tot poate pica la INP dacă al cincilea click, pe o pagină încărcată cu JavaScript, îngheață o jumătate de secundă.
Pragul de trecere e sub 200 de milisecunde, măsurat la percentila 75 din sesiuni reale de utilizatori, alături de LCP sub 2,5 secunde și CLS sub 0,1. Site-urile care trec de toate trei au bounce rate măsurabil mai mic și ranking organic mai bun; site-urile care ratează chiar și una concurează cu un handicap pe care nicio optimizare de cuvinte cheie nu îl corectează.
| Metrică | Ce Măsoară | Pragul de Trecere în 2026 |
|---|---|---|
| LCP | Viteza de încărcare a conținutului principal | Sub 2,5 secunde |
| INP | Responsivitate pe fiecare interacțiune | Sub 200 de milisecunde |
| CLS | Stabilitate vizuală în timpul încărcării | Sub 0,1 |
De ce majoritatea site-urilor pică oricum
Eșecurile la INP aproape niciodată nu vin de la un singur vinovat evident. Vin dintr-o acumulare: un widget de chat aici, un script de analytics acolo, o librărie de carousel, un font loader, un script de A/B testing, fiecare rezonabil individual, dar împreună aduc un main thread prea ocupat ca să răspundă la un click în 200 de milisecunde. Ăsta e exact modul de eșec structural spre care sunt predispuse site-urile pe page builder sau dependente masiv de plugin-uri, pentru că fiecare plugin livrează propriul bundle de JavaScript, iar niciunul nu știe ce face celălalt.
Reparația nu e un singur switch. E o disciplină de inginerie: împărțirea task-urilor lungi în bucăți mai mici ca să poată browser-ul să „respire” între ele, amânarea a tot ce nu e critic până după ce pagina devine interactivă, mutarea calculelor grele de pe main thread cu web workers, și auditarea fiecărui script terț ca să vezi dacă își merită locul. Nimic din asta nu e exotic; toate cer ca cineva chiar să se uite, iar asta e partea pe care majoritatea site-urilor o sar.
Cum arată asta într-o construcție reală
Pe un site codat personalizat pe Next.js, disciplina asta e construită din start, nu adăugată ulterior. Componentele de server randează cea mai mare parte a paginii fără să livreze deloc JavaScript pentru ea, doar piesele interactive se hidratează pe client, iar bundle-ul pe care îl descarcă un vizitator corespunde exact cu ce e de fapt pe acea pagină, nu cu un toolkit universal. E același argument pe care l-am făcut despre page builder-e în general: e mult mai ușor să ții main thread-ul liber de întreruperi când site-ul n-a purtat niciodată funcții pe care nu le folosește.
Mai înseamnă și că INP nu e o bifă de la lansare care putrezește în liniște. Fiecare dependință adăugată ulterior, fiecare widget încorporat cerut de client, trece prin aceeași atenție ca și construcția inițială, pentru că un site inginerit pentru viteză și apoi înzestrat un an mai târziu cu o bulă de chat și trei pixeli de tracking încetează să mai fie site-ul inginerit pentru viteză.
Ce să verifici chiar acum
Dacă nu ești sigur unde stă site-ul tău, atât PageSpeed Insights cât și raportul Core Web Vitals din Search Console arată date INP reale, curente, pentru domeniul tău, nu o simulare de laborator. Numărul care contează e percentila 75 peste vizitatorii tăi reali, pe device-uri reale, care de obicei e mai prost decât ce vede un laptop rapid de birou într-un test rapid. Dacă e peste 200 de milisecunde, reparația rareori e un singur plugin de șters: de obicei e o acumulare lentă care merită auditată corect înainte de următorul refresh al site-ului, nu după.