Din 12 martie 2024, Google a înlocuit oficial First Input Delay (FID) cu Interaction to Next Paint (INP) ca metric Core Web Vitals. Dacă site-ul tău a trecut recent pragul de "Needs Improvement" sau "Poor" fără modificări vizibile de conținut, INP e probabil cauza.
Ce este INP și de ce FID nu mai era suficient?
FID (First Input Delay) măsura doar prima interacțiune a utilizatorului cu pagina — cât durează browserul să înceapă să proceseze primul click sau tap. Problema: FID ignora toate interacțiunile ulterioare și nu surprindea pagini care deveneau lente după ce se încărcau complet.
INP (Interaction to Next Paint) măsoară latența tuturor interacțiunilor discrete pe durata vizitei — click-uri, tap-uri, apăsări de taste — și raportează percentila 98 (al 98-lea cel mai lent eveniment). Este un indicator mult mai realist al responsivității generale a paginii.
◈Praguri INP: Sub 200ms = Good ✓ | 200-500ms = Needs Improvement ⚠ | Peste 500ms = Poor ✗
Ce cauzează un INP slab?
INP prost apare când main thread-ul browserului e blocat în momentul în care utilizatorul interacționează. Cauzele principale:
- JavaScript excesiv pe main thread — long tasks care blochează randarea pentru >50ms
- Event handlers neoptimizați — funcții care fac prea mult muncă sincronă la fiecare click
- Render-blocking third-party scripts — chat widgets, analytics, ad scripts care se execută continuu
- React/Vue re-renders excesive — componente care recalculează tot la fiecare interacțiune
- Layout thrashing — citire și scriere alternativă a proprietăților DOM care forțează reflow repetat
- Animații JavaScript care rulează pe main thread în loc de CSS sau Web Animations API
Cum măsori INP pe site-ul tău
Există două surse de date pentru INP:
- CrUX (Chrome User Experience Report) — date reale de la utilizatorii tăi, disponibile în Google Search Console → Core Web Vitals și PageSpeed Insights. Acestea sunt datele pe care Google le folosește pentru ranking.
- Lab data — Lighthouse și WebPageTest oferă simulări controlate. Utile pentru debugging, dar nu reflectă experiența reală a utilizatorilor. INP nu poate fi capturat complet în lab — necesită interacțiuni reale.
Instalează extensia Web Vitals pentru Chrome. Îți arată INP în timp real pe orice pagină în timp ce interacționezi cu ea — cel mai rapid mod să identifici problemele.
Cum optimizezi INP
Fragmentează long tasks cu scheduler API
Orice task JavaScript care durează >50ms este un "long task" și poate bloca interacțiunile. Fragmentează-le cu setTimeout(fn, 0), scheduler.yield() sau requestIdleCallback pentru a permite browserului să proceseze interacțiunile utilizatorilor între bucăți de muncă.
Mută logica grea în Web Workers
Calculele complexe, procesarea de date sau filtrarea de liste mari se pot muta în Web Workers — thread-uri separate care nu blochează main thread-ul. Rezultatele se trimit înapoi prin mesaje asincrone.
Optimizează event handlers
Event handlers trebuie să fie rapizi. Mută logica vizuală (ce utilizatorul vede imediat) la începutul handler-ului și amână operațiunile secundare (analytics, API calls, actualizări de stare non-critice) cu setTimeout sau microtasks.
Auditează și elimină third-party scripts
Third-party scripts sunt sursa numărul 1 de INP slab. Chat widgets, heatmaps, ad scripts — toate se execută pe main thread. Auditează cu Chrome DevTools → Performance → ce script ocupă cel mai mult timp pe main thread și decide care pot fi eliminate, întârziate (defer) sau înlocuite cu variante mai ușoare.
◈Un studiu pe 1 milion de pagini a arătat că site-urile cu INP sub 200ms au cu 24% mai puțin abandon și cu 15% mai mult timp petrecut pe pagină față de site-urile cu INP "Needs Improvement".
INP și impactul în SEO
Google confirmă că Core Web Vitals sunt factori de ranking în Page Experience signal. INP "Poor" nu face site-ul să dispară din Google, dar la paritate de conținut și autoritate, site-ul cu INP "Good" câștigă poziția. Pe piețe competitive, această diferență poate valorea mii de vizitatori organici pe lună.
Dacă Google Search Console îți arată URL-uri în secțiunea Core Web Vitals cu status "Poor", rezolvarea lor e prioritate — mai ales dacă sunt pagini cu potențial comercial (pagini de servicii, produse, landing pages).
