Una persona apre un sito dal telefono. La pagina compare subito, lei trova il servizio che cerca e tocca il pulsante per chiedere un preventivo. Per un attimo non succede niente, e tocca di nuovo. Chi gestisce il sito probabilmente non se n’è mai accorto: dal computer dell’ufficio tutto sembra funzionare.
Quando ti chiedi se un sito sia veloce, di solito pensi a quanto tempo impiega a caricarsi. Ma una pagina che si carica in fretta può comunque rispondere tardi a chi la usa, e Google tiene separati i due aspetti: li misura con indicatori diversi e li valuta entrambi.
Sito web veloce ma lento ai clic: due misure diverse #
Fra i criteri con cui Google giudica una pagina web ci sono tre indicatori che chiama Core Web Vitals. Il Largest Contentful Paint misura il caricamento: il contenuto principale dovrebbe comparire entro due secondi e mezzo. Il Cumulative Layout Shift misura gli spostamenti improvvisi degli elementi durante la lettura della pagina. Il terzo riguarda il pulsante del preventivo. Si chiama Interaction to Next Paint, in sigla INP, e misura quanto tempo passa fra un tocco, un clic o un tasto premuto e il momento in cui la pagina aggiorna lo schermo per rispondere.
Secondo web.dev, il sito di Google per gli sviluppatori, l’INP è buono fino a 200 millisecondi, da migliorare fino a 500 e scarso oltre. Per ogni visita conta, di solito, l’interazione più lenta. Google non guarda una visita sola: usa quelle reali degli utenti di Chrome che condividono le statistiche, separate fra telefono e computer, e prende il 75° percentile. Vuol dire che almeno tre visite su quattro devono essere sotto la soglia.
La documentazione di Google Search dice che i Core Web Vitals sono usati dai sistemi che ordinano i risultati. Aggiunge che buoni valori non garantiscono i primi posti: Google cerca comunque di mostrare i contenuti più pertinenti, anche quando l’esperienza offerta è scarsa.
Controllare gratis il sito web con PageSpeed Insights #
Lo strumento è PageSpeed Insights, di Google, e non richiede registrazione. Inserisci l’indirizzo di una pagina pubblica del sito, meglio se è una pagina che conta per il lavoro: quella dei servizi, quella dei contatti, la scheda di un prodotto.
Secondo la documentazione dello strumento, il rapporto mostra i dati delle visite reali degli ultimi 28 giorni, separati per telefono e computer, e fra questi è incluso l’INP. Per leggere il risultato valgono le soglie di Google: fino a 200 millisecondi va bene, fra 200 e 500 va migliorato, oltre 500 è un problema. Il punteggio da 0 a 100 messo in evidenza è un’altra cosa: viene da una simulazione, e secondo la stessa documentazione un buon punteggio non garantisce che le visite reali vadano bene.
I dati reali però ci sono solo se la pagina ha avuto visite a sufficienza. Se non bastano, lo strumento mostra quelli dell’intero sito, e a volte mancano anche quelli, se le visite sono troppo poche. Resta allora la simulazione, che non misura l’INP ma il Total Blocking Time: la somma dei tempi in cui, durante il caricamento, il browser resta bloccato da compiti lunghi. Secondo la guida di web.dev, può fare da indicatore approssimativo dell’INP, ma non lo sostituisce.
Chi usa Search Console, il servizio gratuito di Google per chi gestisce un sito, trova i tre indicatori anche nel rapporto Core Web Vitals. Il rapporto raggruppa pagine simili, e anche lui ha bisogno di un numero minimo di visite.
Se il risultato è da migliorare o scarso, oppure se i dati non ci sono, scrivimi. Mandami l’indirizzo del sito: provo da telefono le pagine che contano e ti dico che cosa rallenta la risposta.
Perché un sito web risponde tardi a un clic #
Il browser, il programma con cui si naviga, svolge la maggior parte del lavoro di una pagina su un’unica linea di esecuzione, che gli sviluppatori chiamano main thread. Lì esegue gli script del sito, risponde ai tocchi e prepara quello che compare sullo schermo, e come spiega web.dev può svolgere un solo compito alla volta. Se in quel momento è occupato da compiti lunghi, la risposta al clic resta in attesa finché non si libera. Secondo la guida sull’INP, l’attesa può dipendere anche dal codice che risponde al clic, se è lento, e dal tempo necessario per ridisegnare la pagina.
Per capire l’ordine di grandezza ho fatto una prova in Chrome 152, su una pagina costruita apposta. Uno script lavora per 300 millisecondi e nel frattempo arriva un clic. Se lo script lavora tutto di seguito, il clic aspetta 250 millisecondi, un quarto di secondo. Se lo stesso lavoro viene diviso in pezzi brevi, il clic aspetta circa 10 millisecondi. Il lavoro è lo stesso, cambia come è organizzato.
Gli script che tengono occupato il browser non sono solo quelli scritti per il sito. Possono arrivare anche da servizi esterni. QuintoAndar, la più grande piattaforma immobiliare del Brasile, per ridurre l’attesa ha tolto fra l’altro i pixel di terze parti, piccoli script che raccolgono dati per conto di altri servizi.
INP ridotto: che risultati hanno avuto tre aziende #
Su web.dev tre aziende hanno raccontato che cosa è successo dopo aver ridotto l’INP. Sono resoconti scritti dalle aziende o insieme a loro, senza un confronto controllato: mostrano che i risultati sono migliorati insieme alla reattività, non quanto dipenda dalla reattività.
redBus, un sito indiano di prenotazione di biglietti per autobus, ha migliorato del 72% l’INP della pagina di ricerca. Secondo il caso pubblicato, le vendite complessive sono cresciute del 7%.
QuintoAndar ha ridotto l’INP dell’80%. Le pagine con un INP buono sono passate dal 42 al 78 per cento, e le visite agli immobili prenotate sono cresciute del 36% rispetto all’anno precedente. Nello stesso periodo l’azienda ha lavorato anche sui contenuti delle pagine, e nel suo resoconto scrive che il risultato è legato «in modo forte, ma non esclusivo» al miglioramento dell’esperienza. Secondo la stessa azienda, un ritardo oltre i 200 millisecondi è già percepibile.
The Economic Times, quotidiano economico indiano, è partito da un INP di circa 1.000 millisecondi sull’intero sito ed è sceso a 257, ancora sopra la soglia di un valore buono. Prima ha ridotto il lavoro degli script, poi ha rifatto le pagine tematiche, che portano una parte piccola del traffico, con una nuova base tecnica, il framework Next.js. Su quelle pagine il caso pubblicato riporta un calo del 50% della frequenza di rimbalzo, cioè delle visite che si fermano a una sola pagina, e un aumento del 43% delle pagine viste.
Sono aziende grandi, con un traffico che il sito di una piccola impresa non ha, e nessuno di questi casi dice quanto valga una percentuale per un sito più piccolo. Il meccanismo però è lo stesso: un clic che aspetta la fine di uno script aspetta allo stesso modo su qualunque sito. Quanto conti per le vendite, invece, cambia da sito a sito.
Sito web lento ai clic: che cosa chiedere a chi lo sviluppa #
Di solito l’INP migliora riducendo il lavoro degli script: togliendo quelli che non servono, rimandando quelli che possono aspettare e dividendo in pezzi brevi quelli che restano. Sono gli interventi indicati dalla documentazione di Lighthouse, lo strumento su cui si basa la simulazione di PageSpeed Insights. Chi commissiona un sito nuovo o gestisce quello esistente può fare quattro domande precise.
- Qual è l’INP da telefono delle pagine principali? Se PageSpeed Insights ha i dati reali, la risposta è un numero, e l’obiettivo è restare entro i 200 millisecondi.
- Se i dati reali mancano, come vengono provate le interazioni? Un sito appena pubblicato può non averli per settimane, o non averli mai se le visite sono poche. Nel frattempo il modulo di contatto, il carrello e i menu vanno provati su un telefono di fascia media, non solo sul computer di chi ha sviluppato il sito.
- Quali script di servizi esterni carica il sito, e servono tutti? Ogni script va scaricato, letto ed eseguito dal browser: è lavoro in più.
- Il Total Blocking Time da telefono in PageSpeed Insights è entro i 200 millisecondi? Secondo Lighthouse è la soglia del verde. Non sostituisce l’INP, ma è un indizio disponibile anche senza dati reali.
Se non sai rispondere a queste domande, o chi gestisce il sito non sa farlo, scrivimi. La velocità è il primo requisito dei siti che progetto.
Domande frequenti #
Un sito web che si carica in fretta è anche veloce a rispondere? #
Non necessariamente. Google misura il caricamento con il Largest Contentful Paint e la risposta a clic e tocchi con l’INP, due indicatori separati. Una pagina può comparire in meno di due secondi e mezzo e poi far aspettare chi tocca un pulsante.
Che cos’è l’INP di un sito web? #
INP, Interaction to Next Paint, è l’indicatore con cui Google misura quanto una pagina web è rapida a rispondere a clic, tocchi e tasti. Per ogni visita conta, di solito, l’interazione più lenta. Un valore fino a 200 millisecondi è buono, fino a 500 da migliorare, oltre è scarso. Dal 12 marzo 2024 ha preso il posto del First Input Delay, che misurava solo il primo clic.
Come si controlla gratis la velocità di risposta di un sito web? #
Con PageSpeed Insights di Google: inserisci l’indirizzo di una pagina e il rapporto mostra l’INP delle visite reali degli ultimi 28 giorni, se le visite bastano. Altrimenti resta il Total Blocking Time di una simulazione, che dà un’indicazione approssimativa.
Perché il mio sito web è lento a rispondere ai clic? #
Una causa comune è che il browser è occupato a eseguire script mentre l’utente tocca la pagina: il codice del sito o quello di servizi esterni. Il browser svolge un compito alla volta, quindi la risposta al clic aspetta la fine dello script in corso. L’attesa può dipendere anche da un codice di risposta lento o dal tempo per ridisegnare la pagina.
L’INP influisce sul posizionamento su Google? #
Sì, ma senza un peso dichiarato. Google scrive che i Core Web Vitals, e quindi anche l’INP, sono usati dai suoi sistemi di classificazione, e che buoni valori non garantiscono i primi posti: Google cerca comunque di mostrare i contenuti più pertinenti.
Migliorare l’INP aumenta le vendite? #
Nei casi pubblicati su web.dev, redBus ha registrato il 7% di vendite in più e QuintoAndar il 36% di visite prenotate in più dopo aver ridotto l’INP. Sono resoconti senza un confronto controllato, e almeno due delle aziende hanno cambiato anche altro: mostrano che vendite e reattività sono migliorate insieme, non quanto dipenda dall’INP.
Fonti #
Documentazione di Google Search su Core Web Vitals e page experience, aggiornate al 10 dicembre 2025. Su web.dev: Interaction to Next Paint, aggiornato al 2 settembre 2025; INP diventa Core Web Vital, 31 gennaio 2024; ottimizzare i long task, 19 dicembre 2024; casi studio di QuintoAndar, 22 gennaio 2025, redBus e The Economic Times, aggiornati al 10 maggio 2023. Documentazione di PageSpeed Insights, aggiornata al 21 ottobre 2024, e di Lighthouse sul Total Blocking Time, aggiornata al 9 ottobre 2019. Guide di Search Console su Search Console e sul rapporto Core Web Vitals, senza data dichiarata.