Core Web Vitals: INP Explicat Simplu

Istoria scurta: de ce Google a inlocuit FID cu INP

In martie 2024, Google a retras First Input Delay (FID) din Core Web Vitals si l-a inlocuit cu Interaction to Next Paint (INP). Motivul: FID masura doar prima interactiune a utilizatorului cu pagina. INP masoara toate interactiunile pe durata sesiunii — un indicator mult mai relevant pentru experienta reala a utilizatorului.

Exemplu concret: un utilizator deschide un articol (FID masura click-ul initial), citeste, da click pe un link intern, se intoarce, completeaza un formular. FID vedea doar primul click. INP vede tot — si penalizeaza site-urile unde interactiunile sunt lente pe parcursul intregii sesiuni.

Pentru site-urile cu JavaScript greu (ecommerce, SPA-uri, site-uri cu multe widget-uri), INP a adus surprize neplacute — site-uri cu FID bun aveau INP slab si au vazut scaderi de ranking dupa martie 2024.

Cele trei Core Web Vitals in 2026 — explicatii simple

LCP — Largest Contentful Paint

"Cat dureaza pana apare ceva util pe ecran." Masurat din momentul inceperii navigarii pana cand cel mai mare element vizibil (imagine, video, bloc de text) devine vizibil.

Prag bun: sub 2.5 secunde. Target competitiv in 2026: sub 1.8s.

Cauzele principale ale LCP slab: imagini neoptimizate (cel mai frecvent), hosting lent (TTFB mare), CSS sau JavaScript blocant care intarzie randarea.

INP — Interaction to Next Paint

"Cat de repede raspunde pagina la ce fac eu." Masurat ca latenta intre orice interactiune (click, apasare tasta, touch) si urmatoarea actualizare vizibila a paginii.

Prag bun: sub 200 milisecunde. Sub 500ms = acceptabil. Peste 500ms = slab.

Cauzele principale ale INP slab: JavaScript greu care blocheaza thread-ul principal, handler-uri de evenimente ineficiente, re-randari excesive in React/Vue/Angular.

CLS — Cumulative Layout Shift

"Cat se misca pagina in timp ce se incarca." Masurat ca suma tuturor schimbarilor neasteptate de layout pe durata intregii sesiuni.

Prag bun: sub 0.1. Cauzele frecvente: imagini fara dimensiuni specificate in HTML, continut incarcat dinamic care impinge elementele existente, bannere cookie care apar dupa ce pagina e deja randara.

Cum masori INP corect

INP e mai greu de masurat decat LCP sau CLS pentru ca depinde de interactiunile reale ale utilizatorilor. Ai doua tipuri de masuratori:

Lab data (simulated)

PageSpeed Insights si Lighthouse simuleaza interactiuni. Util pentru debugging dar nu reflecta neaparat comportamentul real al utilizatorilor tai.

Field data (real users)

Google Search Console → Core Web Vitals → INP. Acestea sunt datele reale de la utilizatorii reali ai site-ului tau pe ultimele 28 de zile. Aceasta e metrica care conteaza pentru ranking.

Daca ai putini vizitatori (sub 1.000 pe luna), Google s-ar putea sa nu aiba suficiente date pentru a afisa INP in Search Console — e normal, nu inseamna ca nu esti masurat.

INP pe WordPress — cele mai frecvente probleme si solutii

Problema 1: Plugin-uri cu event listeners costisitoare

Fiecare plugin de WordPress adauga JavaScript. Unele plugin-uri (chat live, popup-uri, form builders) au event listeners care ruleaza la fiecare interactiune si incetinesc INP.

Diagnostic: deschide Chrome DevTools → Performance → Record, da click pe elemente din pagina si cauta "long tasks" in timeline. Orice task peste 50ms e un candidat pentru optimizare.

Solutie: dezactiveaza plugin-urile pe rand si re-masoara. Identifica vinovatul. Gaseste o alternativa mai usoara sau elimina daca nu e esential.

Problema 2: WooCommerce cu cos de cumparaturi

Paginile de produs si cosul din WooCommerce sunt notori pentru INP slab — multe re-calcule de pret, update-uri de stoc, event listeners pe butoane. Solutia frecventa: Fragment Caching pentru componentele dinamice, lazy loading pentru componentele non-critice ale paginii de produs.

Problema 3: Google Tag Manager suprafolosit

GTM cu 15-20 de taguri active (analytics, pixel Facebook, chat, heatmap, A/B testing) poate devasta INP. Fiecare tag executa JavaScript la interactiunile utilizatorului. Audit regulat al tagurilor GTM si stergerea celor neutilizate e o practica obligatorie.

INP pe site-uri React/Next.js — specificul framework-urilor

Site-urile React au un avantaj potential — logica este predefinita si poate fi executata eficient. Dar pot suferi de INP slab daca:

• Handler-urile de eventi declanseza re-renderari inutile ale componentelor parinte (rezolva cu React.memo, useMemo, useCallback)
• State updates in bucati mari se fac sincron (rezolva cu React 18 Transitions)
• Bundle-ul JavaScript initial e prea mare (rezolva cu code splitting si lazy loading)

Next.js 13+ cu Server Components reduce masiv JavaScript-ul trimis clientului — implicit imbunatateste INP pentru componentele statice.

Impactul CWV asupra SEO — ce stim cu siguranta in 2026

Google a confirmat ca CWV sunt un "ranking signal" dar nu un factor masiv — nu bat calitatea continutului sau autoritatii domeniului. In practica, CWV conteaza mai ales la egalitate: daca doua site-uri au continut similar si autoritate similara, cel cu CWV mai bun rankeaza mai sus.

Unde conteaza cu siguranta: experienta utilizatorului si rata de conversie. Un LCP de 4s pe mobile inseamna 35-50% rata de abandon inainte ca utilizatorul sa vada ceva util. Acesta e impactul direct si imediat, independent de SEO.

Concluzie practica: optimizeaza CWV pentru utilizatori, nu pentru Google. Utilizatorii multumiti raman mai mult, convertesc mai mult, dau mai multe recenzii — toate semnale pozitive care imbunatatesc indirect rankingul oricum.