INP: La metrica che il 35% dei siti fallisce ancora nel 2026

Il 12 marzo 2024 Google ha rimosso FID dai Core Web Vitals e lo ha sostituito con INP. La ragione? FID era troppo permissivo: il 93% dei siti mobile aveva un punteggio “good”. Ma solo il 65% passa INP. Un terzo dei siti web fallisce la nuova metrica.

Cosa misura INP (e perché è più cattivo di FID)

FID (First Input Delay) misurava solo il tempo di risposta alla prima interazione dell’utente. Scroll, click su un link, tap su un bottone: solo la prima azione contava.

INP (Interaction to Next Paint) misura tutte le interazioni durante l’intera sessione. Click, tap, pressione di tasti: ogni interazione viene monitorata. Poi Google prende il 75° percentile e quello è il tuo punteggio.

Se anche solo il 25% delle interazioni è lento, sei fuori.

I tre threshold INP

Sotto 200ms: Good. Il tuo sito risponde istantaneamente.

200-500ms: Needs Improvement. Percezione di lag, ma tollerabile.

Oltre 500ms: Poor. L’utente pensa che il sito si sia bloccato.

Secondo dati web.dev del 2024, un terzo dei siti web non raggiunge i 200ms su mobile. Questo significa che 1 utente su 3 percepisce lag durante la navigazione.

Cosa rallenta INP: I long tasks

Il nemico numero uno di INP sono i long tasks: blocchi di codice JavaScript che impiegano più di 50 millisecondi per essere eseguiti.

Quando un long task sta girando, il browser non può rispondere alle interazioni utente. Click, scroll, tap: tutto in coda. Finché il task non finisce, l’utente vede uno schermo congelato.

Esempi comuni di long tasks:

• Caricamento e parsing di librerie JavaScript pesanti
• Rendering di componenti complessi (es. tabelle con 1000+ righe)
• Calcoli lato client (filtri, ordinamenti, validazioni)
• Third-party scripts (analytics, ads, chatbot)

Come ottimizzare INP: Strategie operative

1. Identifica i long tasks con Chrome DevTools

Apri Chrome DevTools, vai su Performance, registra 10 secondi di navigazione. Cerca barre rosse etichettate “Long Task”. Ogni barra sopra i 50ms è un colpevole.

Strumenti utili:

• PageSpeed Insights (sezione “Diagnostics”)
• DebugBear (analisi INP in field data)
• Chrome UX Report (dati reali utenti del tuo sito)

2. Code splitting e lazy loading

Non caricare tutto il JavaScript in un bundle unico da 500KB. Usa code splitting per dividere il codice in chunk più piccoli caricati on-demand.

Framework moderni (Next.js, Nuxt, Astro) supportano code splitting automatico. Se usi Webpack o Vite, configura dynamic imports.

3. Debouncing e throttling per input intensivi

Se hai filtri, ricerche in tempo reale, o autocomplete, non eseguire il codice a ogni singolo keypress. Usa debouncing (esegui dopo 300ms dall’ultimo input) o throttling (esegui al massimo ogni 200ms).

4. Riduci il lavoro del main thread

Sposta operazioni pesanti in Web Workers. Calcoli complessi, parsing JSON, manipolazione dati: tutto può girare in background senza bloccare l’interfaccia.

5. Ottimizza third-party scripts

Google Analytics, Facebook Pixel, Hotjar, live chat: ogni script third-party aggiunge latenza. Caricali in modo asincrono con defer o async, o meglio ancora, tramite Google Tag Manager con trigger condizionali.

INP vs altri Core Web Vitals

I tre Core Web Vitals nel 2025 sono:

LCP (Largest Contentful Paint): Velocità di caricamento del contenuto principale. Target: sotto 2.5 secondi.

INP (Interaction to Next Paint): Reattività alle interazioni utente. Target: sotto 200ms.

CLS (Cumulative Layout Shift): Stabilità visiva durante il caricamento. Target: sotto 0.1.

INP è l’unico che misura l’esperienza post-caricamento. LCP e CLS si concentrano sulla fase iniziale. INP cattura quanto il sito sia utilizzabile dopo che l’utente inizia a interagire.

Strumenti di monitoraggio INP in produzione

PageSpeed Insights mostra INP da lab data (test sintetici). Ma il dato che conta è field data: utenti reali, device reali, connessioni reali.

Fonti di field data:

Chrome UX Report (CrUX): Dati aggregati da milioni di utenti Chrome. Accessibile via Google Search Console o BigQuery.

Google Search Console: Sezione “Core Web Vitals” mostra quali URL hanno INP poor o needs improvement.

Real User Monitoring (RUM): Strumenti come SpeedCurve, DebugBear, o Google Analytics 4 con custom events per tracciare INP in tempo reale.

Perché INP conta per la SEO

Google ha confermato che Core Web Vitals sono un fattore di ranking. Ma l’impatto diretto è modesto: non basta avere INP perfetto per rankare primi.

L’impatto indiretto è massiccio: INP alto significa utenti frustrati, bounce rate alto, tempo di permanenza basso. Google misura questi segnali comportamentali. Un sito con INP poor ha engagement peggiore, e Google lo penalizza di conseguenza.

Dati interni da e-commerce Q4 2024: Siti con INP sotto 200ms hanno conversion rate 15% più alto rispetto a siti con INP sopra 500ms. Il problema non è solo ranking, è revenue.

Conclusione: 200ms è il nuovo standard

Il 93% dei siti aveva FID “good”. Solo il 65% ha INP “good”. Google ha alzato il livello.

Se il tuo sito ha INP sopra i 200ms, non sei in zona rossa immediata. Ma sei in svantaggio rispetto ai competitor che hanno ottimizzato.

Misura INP con Chrome UX Report. Identifica long tasks con DevTools. Applica code splitting, debouncing, e lazy loading. Monitora field data, non solo lab data.

L’era del “basta che il sito carichi veloce” è finita. Ora conta quanto è reattivo mentre l’utente lo usa.