INP e Core Web Vitals nel 2026: Perché l’Interazione Conta Più della Velocità

La maggior parte dei siti che avevano “superato” i Core Web Vitals nel 2024 sta fallendo silenziosamente nel 2026 — e il responsabile è una metrica che la maggior parte degli sviluppatori non comprende ancora pienamente. Interaction to Next Paint (INP) è diventato un Core Web Vital nel marzo 2024, sostituendo il molto più semplice First Input Delay. Ora, diciotto mesi dopo, i dati di campo CrUX mostrano che oltre il 40% delle pagine web mobile ottiene ancora un punteggio nella fascia “da migliorare” o “scarso” per INP — nonostante i proprietari credano che il loro sito sia veloce.

In sintesi: INP misura la velocità con cui la pagina risponde visivamente a ogni interazione dell’utente — non solo alla prima. Un LCP e CLS verdi non significano nulla se cliccare un pulsante, aprire un menu o inviare un modulo risulta lento. Google utilizza l’INP come segnale di ranking adesso, e il requisito è più severo di quanto la maggior parte delle persone realizzi.

Cosa Misura Davvero l’INP (e Perché È Più Difficile del FID)

Il First Input Delay misurava solo il ritardo prima che il browser iniziasse a elaborare la tua prima interazione — non si preoccupava di quanto durasse quell’elaborazione, e guardava a un solo evento. L’INP è categoricamente diverso:

• Monitora ogni interazione — clic, tocchi e pressioni di tasti — durante l’intera sessione sulla pagina.
• Misura la latenza completa dell’interazione: ritardo di input + tempo di elaborazione + ritardo di presentazione (il tempo fino a quando il frame successivo viene effettivamente dipinto).
• Riporta l’interazione nel caso peggiore (98° percentile) della sessione, non la media.

Le soglie sono severe: ≤200 ms = Buono, 200–500 ms = Da migliorare, >500 ms = Scarso. Un singolo gestore di eventi JavaScript pesante — un widget di filtraggio, un’animazione modale, una callback di analytics — può portare l’intero punteggio nel rosso.

Quel grafico riflette la distribuzione reale approssimativa nel web oggi. La maggior parte dei siti vive nella fascia gialla — tecnicamente non in “rosso”, ma assolutamente superata in classifica da competitor che raggiungono il verde.

I Principali Killer dell’INP nel 2026

Dopo aver analizzato decine di siti quest’anno, gli stessi problemi emergono ripetutamente. Nessuno di essi appare in un’esecuzione base di Lighthouse, perché Lighthouse simula condizioni di laboratorio, non il comportamento reale degli utenti.

1. Task JavaScript Lunghi sul Thread Principale

Qualsiasi task JS che dura più di 50 ms è classificato come “long task” e blocca il browser dal rispondere all’input dell’utente. Le fonti principali nel 2026 sono i payload gonfiati di Google Tag Manager (i container GTM con 40+ tag sono diffusissimi), l’idratazione non ottimizzata di React o Vue, e i widget di chat di terze parti che eseguono script di inizializzazione pesanti a ogni interazione.

2. Script di Terze Parti che Bloccano il Rendering

Strumenti di live chat, widget di recensioni, piattaforme di consenso ai cookie e pulsanti di condivisione social iniettano regolarmente script sincroni pesanti. Ognuno compete per il tempo sul thread principale. La latenza delle interazioni si accumula: se l’utente clicca mentre due di questi si stanno inizializzando simultaneamente, il browser mette tutto in coda.

3. Dimensione DOM Eccessiva

Google raccomanda di mantenere il DOM sotto 1.400 nodi. Molti temi WordPress — specialmente i template dei page builder con wrapper profondamente annidati — producono regolarmente 3.000–6.000 nodi. Ogni ricalcolo di stile e reflow di layout innescato da un’interazione è proporzionalmente più costoso quanto più grande è il DOM.

4. Gestori di Eventi Non Ottimizzati

I listener di eventi sincroni che eseguono calcoli pesanti (ordinamento, filtraggio, manipolazione del DOM) senza cedere il controllo al browser sono responsabili di una grande quota di punteggi INP scarsi. La soluzione richiede modifiche architetturali, non solo la modifica di un’impostazione in un plugin.

INP e Ranking: Cosa Dicono i Dati nel Settembre 2026

Google è stato chiaro: i Core Web Vitals — incluso l’INP — influenzano il segnale di ranking della page experience. Ciò che è diventato più evidente nell’ultimo anno è l’effetto composto. Un sito con Buono LCP, Buono CLS e Buono INP riceve il pieno potenziamento di page experience. Un sito con Buono LCP, Buono CLS, ma Scarso INP perde parte di quel vantaggio — e questo delta è ora misurabile nelle SERP competitive.

Oltre al ranking, l’impatto sulle conversioni è significativo. Gli studi mostrano costantemente che le interazioni percepite come lente — anche solo 300–400 ms di ritardo — riducono i tassi di completamento dei moduli del 15–20% e aumentano l’abbandono del carrello. Il tuo punteggio INP non è una metrica di vanità per sviluppatori; è fatturato.

Perché Correggere l’INP Non È un’Ottimizzazione Semplice

A differenza della compressione delle immagini o dell’abilitazione di un CDN, migliorare l’INP richiede di comprendere l’intero modello di esecuzione JavaScript del tuo sito. Non è un’impostazione di plugin — è un lavoro architetturale:

1. Profilare le interazioni reali degli utenti con Chrome DevTools Performance panel e la Long Animation Frames API (LoAF), diventata ampiamente disponibile a fine 2024 e ora lo strumento principale per diagnosticare le regressioni INP.
2. Suddividere i task lunghi usando scheduler.yield() o pattern di elaborazione a blocchi — approcci che richiedono il refactoring manuale di JS.
3. Verificare e ridurre gli script di terze parti — valutare quali tag nel container GTM stanno effettivamente apportando valore di business vs. quelli inutilizzati.
4. Rifattorizzare la struttura DOM — che, in un contesto WordPress, spesso significa sostituire il page builder con markup più leggero.
5. Validare con dati di campo post-correzione — poiché i dati CrUX hanno una finestra mobile di 28 giorni, è necessario monitorare il punteggio per settimane dopo le modifiche per confermare il miglioramento.

È esattamente per questo che un adeguato audit di performance WordPress va ben oltre l’esecuzione di Lighthouse. I nostri audit rivelano il quadro INP degli utenti reali, tracciano ogni long task alla sua origine e producono un piano di rimediazione prioritizzato — non una checklist generica. Se hai bisogno del punteggio garantito, il nostro servizio Speed Fix punta a un PageSpeed mobile superiore a 80 e affronta l’INP come parte dell’intervento.

INP in WordPress: Una Sfida Particolare

WordPress alimenta circa il 43% del web, e ha un problema specifico con l’INP. L’ecosistema di plugin significa che il negozio WooCommerce medio esegue le interazioni attraverso più librerie JS in competizione: jQuery (ancora presente), il runtime dell’editor a blocchi, un framework di page builder, un plugin di form e un SDK di live chat — tutti in lotta per lo stesso thread principale.

Il panorama WordPress 2026 è migliorato: il Full Site Editor è maturato e i temi basati su blocchi sono generalmente più leggeri dei classici page builder. Ma la lunga coda di siti ancora con Divi, Elementor o WPBakery su PHP 8.1 con 35 plugin attivi è enorme — e sono quei siti ad avere punteggi INP nella fascia 600–900 ms.

L’Ecosistema di Metriche Intorno all’INP

L’INP non vive in isolamento. L’Interaction to Next Paint di Google è diagnosticato più accuratamente insieme a due metriche complementari introdotte con la Long Animation Frames API:

• Input Delay: Tempo dall’azione dell’utente a quando il browser inizia l’elaborazione — influenzato dall’occupazione del thread principale.
• Processing Duration: Tempo impiegato nell’esecuzione dei gestori di eventi — influenzato dalla complessità JS.
• Presentation Delay: Tempo dalla fine dell’elaborazione al frame successivo dipinto — influenzato dai costi di layout e rendering.

Capire quale delle tre componenti domina il tuo punteggio INP determina dove concentrare lo sforzo ingegneristico. È una diagnosi, non un toggle su una dashboard — ed è il tipo di analisi strutturata che distingue un engagement di performance significativo da un “abbiamo eseguito Lighthouse”. Puoi vedere come appare una vera indagine sulle performance nei nostri case study.

Cosa Serve Davvero per un Punteggio INP Verde

Per mettere un numero: raggiungere un INP costantemente Buono (<200 ms al 75° percentile delle sessioni di campo) su un tipico sito WordPress o WooCommerce richiede tipicamente:

• Ridurre il total blocking time del 60–80% tramite differimento degli script e suddivisione dei long task
• Ridurre il numero di nodi DOM a meno di 1.500 sulle landing page principali
• Verificare e rimuovere o caricare in modo asincrono almeno il 30–50% degli script di terze parti in termini di peso
• Sostituire o modificare significativamente almeno un plugin pesante o un componente del page builder

È un investimento ingegneristico significativo — e ripaga. Interazioni più veloci significano maggior coinvolgimento, tassi di rimbalzo più bassi e un incremento misurabile del tasso di conversione. Per i siti e-commerce, il ROI del miglioramento dell’INP è frequentemente visibile entro un singolo mese di dati di campo migliorati.