INP e Core Web Vitals: l'Impatto della Velocità sulle Vendite

I Core Web Vitals sono un insieme di misurazioni che Google usa per riassumere l'esperienza utente di una pagina attraverso tre metriche distinte: LCP (Largest Contentful Paint) misura quanto tempo impiega il contenuto principale ad apparire, CLS (Cumulative Layout Shift) misura quanto si spostano gli elementi durante il caricamento, e INP (Interaction to Next Paint) misura quanto velocemente risponde lo schermo dopo un clic o un tocco.

Insieme rispondono a una domanda semplice: la pagina sembra veloce? Se il contenuto appare tardi (LCP alto), un pulsante salta mentre qualcuno legge (CLS alto), o lo schermo sembra bloccato dopo un tocco su un menu (INP alto), l'esperienza viene considerata scadente.

Il FID (First Input Delay) misurava solo il ritardo prima del primissimo clic; ignorava ogni interazione avvenuta dopo il caricamento della pagina. L'INP misura ogni clic, tocco e pressione di tasto per tutto il tempo in cui la pagina resta aperta e riporta il valore peggiore, il che riflette molto più fedelmente l'uso reale.

Si pensi a una pagina di prenotazione dove l'elenco degli orari si blocca per un istante dopo la scelta di una data: il FID non lo avrebbe mai colto, l'INP lo mostra direttamente. Secondo le soglie pubblicate da web.dev, un INP sotto i 200 millisecondi è considerato buono, e oltre i 500 millisecondi scarso. Più lenta è la risposta, prima un visitatore rinuncia.

Una pagina lenta significa che un visitatore se ne va prima di completare ciò per cui era venuto. Si pensi al modulo di prenotazione di una catena di spa: se scegliere una data si blocca per un secondo a ogni tocco, il visitatore potrebbe semplicemente preferire chiamare, o guardare un concorrente.

Lo stesso vale per il modulo di richiesta preventivo di un produttore. Se la schermata di conferma impiega troppo ad apparire dopo l'invio, l'utente non è sicuro che sia andato a buon fine, tocca di nuovo, a volte invia la stessa richiesta due volte, oppure abbandona senza inviarla affatto.

Il rischio qui non riguarda solo il posizionamento nei motori di ricerca; è il numero di transazioni completate.

Il primo passo è misurare. PageSpeed Insights di Google e il report Core Web Vitals in Search Console si basano su dati reali dei visitatori (field data), che, a differenza di un test di laboratorio, mostrano come il sito si comporta davvero sui dispositivi e connessioni dei visitatori.

Un lavoro di velocizzazione che salta la misurazione spesso punta al bersaglio sbagliato. Ridurre un'immagine potrebbe non cambiare nulla se il vero colpevole è un widget di chat di terze parti che rallenta l'intera pagina.

Misurare funziona meglio come abitudine regolare che come report occasionale; se lo stesso report non viene riverificato dopo un aggiornamento o una nuova funzionalità, un peggioramento può passare inosservato per settimane.

• Controllare i valori attuali di LCP, CLS e INP in PageSpeed Insights
• Leggere il report Core Web Vitals in Search Console per dati reali dei visitatori
• Valutare mobile e desktop separatamente; il mobile è di solito il più critico
• Testare separatamente gli script di terze parti (pubblicità, widget di chat, strumenti di analytics)

La velocità del sito conta ovunque, ma in alcuni settori incide direttamente sui ricavi. Su un sito e-commerce, una pagina carrello che carica lentamente è una vendita persa; per un'attività costruita attorno a prenotazioni o candidature, un modulo lento è un cliente perso.

Su un sito vetrina con poche pagine, la velocità conta comunque, ma il suo effetto passa più per la percezione del marchio; un visitatore può semplicemente ritenere meno affidabile un sito lento.

Migliorare un punteggio INP si riduce di solito a spezzare i lunghi task JavaScript che tengono occupato il main thread del browser. Se il codice eseguito subito dopo un clic impiega troppo, il browser attende che finisca prima di aggiornare lo schermo; l'utente percepisce quell'attesa come un blocco.

Gli script di terze parti, un widget di chat dal vivo, tag pubblicitari, strumenti di analytics, sono spesso la vera fonte di un INP scadente, perché condividono lo stesso main thread del codice della pagina. Ritardare uno script in modo che parta solo pochi secondi dopo il caricamento riduce i blocchi in quelle prime interazioni.

Se il filtro prodotti di un produttore ricalcola l'intero elenco a ogni opzione cliccata, spezzare quel calcolo in parti più piccole che lascino respirare il browser risolve il problema; il dettaglio tecnico spetta allo sviluppatore, ma un manager deve sapere che questa correzione è misurabile e raramente richiede una riscrittura completa.

Queste correzioni non devono avvenire tutte insieme; partire dai tre o quattro script con l'impatto maggiore è una strada più realistica di una riscrittura durata mesi.