Prontezza INP

Prontezza INP è una forma abbreviata per indicare quanto una pagina sia pronta a superare Interaction to Next Paint (Interazione al prossimo rendering) nel mondo reale, non solo in un test di laboratorio. Per i team SEO conta perché INP è un Core Web Vital e perché le interfacce lente rovinano il completamento dei form, il tasso di aggiunta al carrello e la qualità dei lead.

Che cosa significa davvero “prontezza INP”

INP misura la latenza di un’interazione dell’utente fino al successivo aggiornamento visivo. Clic. Tap. Pressione di un tasto. Google classifica 200 ms o meno come “buono”, 200-500 ms come “da migliorare” e 500 ms+ come “scarso”.

La parte importante: si tratta soprattutto di dati di campo. Google Search Console e PageSpeed Insights si basano fortemente sui dati del Chrome UX Report quando esiste traffico sufficiente. Lighthouse può indicare cause probabili, ma non dimostra che la tua pagina sia pronta in produzione.

Perché gli SEO dovrebbero interessarsene

INP ha sostituito FID come Core Web Vital nel marzo 2024. Questa modifica è stata significativa perché FID era troppo permissivo. Una pagina poteva rispondere rapidamente al primo tap, poi bloccarsi al secondo, terzo o quarto, e risultare comunque “ok” sotto FID. INP è più rigoroso. È una metrica migliore. Più difficile da “far finta”.

Detto questo, non esagerare sull’impatto in ranking. Google non ha mai affermato che i Core Web Vitals siano un fattore di ranking “pesante”. John Mueller di Google ha più volte inquadrato i segnali di esperienza pagina come tie-breaker quando altri segnali sono simili. Di solito il business case è più forte del caso legato al ranking.

Come valutare la prontezza

• Google Search Console: Controlla il report Core Web Vitals per i gruppi di URL mobile e desktop. È la tua vista SEO di livello più alto.
• PageSpeed Insights: Confronta i dati di campo di CrUX con le diagnosi di Lighthouse. Se l’INP di campo è 280 ms e quello di laboratorio è 90 ms, i tuoi utenti reali stanno incontrando problemi che il test non ha rilevato.
• Chrome DevTools: Usa il pannello Performance per individuare long task, ritardi dei gestori di eventi (event handler) e colli di bottiglia del rendering.
• Screaming Frog: Esegui la scansione dei template e mappa quali tipi di pagina caricano heavy JS, widget di terze parti o librerie di componenti gonfie.
• Ahrefs o Semrush: Dai priorità alle correzioni sui template che generano il maggior numero di accessi organici, non su pagine casuali a basso traffico.

Cosa tende a far crollare l’INP

• Long main-thread task oltre 50 ms
• Rendering lato client pesante in app React, Vue o Angular
• Script di terze parti come chat, test A/B, strumenti di consenso e heatmap
• Aggiornamenti DOM costosi e “layout thrashing” dopo l’input
• Dispositivi Android di fascia bassa con CPU deboli, dove “va bene su desktop” non significa nulla

La nota sincera: i dati INP possono essere rumorosi. Le pagine con poco traffico potrebbero non avere abbastanza dati CrUX. Il raggruppamento degli URL in GSC può nascondere quale template specifico stia fallendo. E alcune interazioni semplicemente non sono abbastanza comuni da emergere finché una feature non ottiene un uso reale.

Che cosa fanno i team bravi

Trattano la prontezza INP come un problema di template e di ricavi, non come un punteggio “vanity”. Correggono prima checkout, form per i lead, filtri prodotto, ricerca interna e navigazione. Se una categoria riceve 50.000 visite organiche al mese ed è ferma a 260 ms di INP, merita attenzione prima di rifinire un template blog che magari è già a 140 ms.

Surfer SEO, Moz, Ahrefs e Semrush non diagnosticano INP in modo diretto. Ti aiutano a capire dove il lavoro sulla performance conta di più. Il debug continua ad avvenire in GSC, PageSpeed Insights, Chrome DevTools e nella tua configurazione RUM.