Core Web Vitals 2026: INP a înlocuit FID — ce s-a schimbat

ℹ️ Articol disponibil în engleză. O versiune română completă va fi publicată în curând.

INP measures the latency between any user interaction (tap, click, key press) and the next visual update. Unlike its predecessor FID, which only sampled the first input, INP tracks all interactions and reports the 98th percentile. That makes it harder to game and more reflective of real-world feel.

Thresholds

• Good: ≤200ms
• Needs improvement: 200–500ms
• Poor: >500ms

Common INP killers

The biggest offenders we see in audits: third-party tag managers (GTM, Segment) loading sync; React event handlers with synchronous state cascades that block rendering; expensive DOM measurements (getBoundingClientRect) inside scroll/resize listeners without rAF batching; large input event handlers that trigger virtual-DOM reconciliation across the whole tree.

How to fix

1. Profile in DevTools Performance tab — record an interaction, look for long tasks >50ms.
2. Move heavy work off the main thread: scheduler.yield(), requestIdleCallback, web workers.
3. Defer third-party scripts. Use <script async> + tag-manager loading on user interaction, not on page load.
4. Use React 19's useTransition or useDeferredValue to keep input responsive even during expensive renders.
5. Audit autocomplete/search inputs — they are frequent INP culprits because every keystroke triggers a query.

Auditope runs Lighthouse with throttled CPU and reports INP per page. Run it before and after each performance fix to verify the regression is gone.