Come la velocità della landing page influisce sulle conversioni

Quando la lentezza può far perdere una conversione

Chi clicca un annuncio deve trovare la promessa che ha motivato il clic. Se la prima schermata resta vuota, può uscire prima di leggere. Se il pulsante sembra attivo ma non risponde, può toccarlo più volte. Se la conferma tarda, può inviare di nuovo lo stesso modulo: due eventi registrati possono corrispondere a una sola richiesta.

La durata del caricamento non dà da sola una previsione delle vendite. Un pubblico su telefoni meno potenti può avere sia tempi peggiori sia un intento diverso da chi arriva da desktop. Se quel pubblico converte meno, prima di attribuire il risultato alla velocità bisogna verificare anche da quali campagne arriva e che cosa cerca. Anche una pagina rapida può avere un'offerta debole: per gli ostacoli di contenuto e di usabilità, usa la guida all'ottimizzazione delle conversioni della landing page.

Quali metriche leggere e che cosa descrivono

Google valuta queste soglie dei Core Web Vitals al 75° percentile, indicato anche come p75, separatamente per mobile e desktop: almeno il 75% delle osservazioni deve rientrare nella soglia di ciascuna metrica. La mediana di tre prove locali descrive invece quei tre caricamenti nelle condizioni del test; non basta a stabilire se gli utenti reali rientrano nelle soglie.

In PageSpeed Insights, la parte sull'esperienza degli utenti reali usa CrUX e copre gli ultimi 28 giorni. Controlla se il report riguarda l'URL o l'origine, cioè l'insieme delle pagine sullo stesso protocollo, dominio e porta. Per esempio, il dato di https://qreativa.com comprende più pagine e non descrive soltanto questa guida. Se manca il campione necessario, annota «dato non disponibile»; non sostituirlo con il punteggio Lighthouse. La documentazione di PSI spiega copertura e aggregazione.

La sezione di laboratorio esegue Lighthouse in condizioni simulate. Il Total Blocking Time (TBT) aiuta a individuare attività che occupano il thread principale del browser, impedendogli di rispondere durante il caricamento. Non misura però INP: un modulo può diventare lento dopo l'avvio di una chat o durante la validazione. Le differenze tra prove di laboratorio e dati degli utenti reali spiegano perché conviene verificare anche interazioni e spostamenti durante la visita.

Come raccogliere prove confrontabili

Per una prima diagnosi puoi eseguire tre prove consecutive con il profilo mobile e tre con quello desktop, prima e dopo la modifica: 6 report iniziali e 6 finali, 12 in tutto. Le ripetizioni aiutano a vedere quanto oscillano i risultati a parità di condizioni; non dicono quante persone avranno la stessa esperienza. Se una prova fallisce, conserva l'errore e risolvi il problema prima di rifarla.

1. Registra la pagina e il contesto

   Annota l'URL finale dopo eventuali reindirizzamenti, data e ora, versione della pagina, dispositivo o profilo simulato, browser e versione dello strumento. Registra le impostazioni di rete e CPU, lo svuotamento della cache e degli altri dati del sito, il consenso e l'eventuale accesso con un account. Conserva i parametri di campagna necessari a riprodurre il percorso; non inserire dati personali nel registro.

2. Esegui la serie senza cambiare condizioni

   Puoi usare PSI per una diagnosi iniziale. Per una serie locale, apri la pagina in Chrome e poi gli strumenti per sviluppatori, con F12. Nel pannello Lighthouse scegli la modalità Navigation e il profilo Mobile, quindi avvia l'analisi tre volte; ripeti con Desktop. Usa un profilo del browser senza estensioni e chiudi le attività pesanti. Mantieni le stesse impostazioni, compresa l'opzione che cancella i dati del sito prima della prova. Salva ogni report dal menu di esportazione con nomi come prima-mobile-1. Confronta i risultati prodotti dallo stesso strumento: una prova PSI e una locale possono usare condizioni diverse.

3. Controlla il percorso su un telefono

   Apri il link usato in campagna, leggi l'offerta, apri il modulo e compila i campi. Lascia un campo obbligatorio vuoto per controllare il messaggio di errore, poi completa l'invio con dati di test concordati e verifica la conferma. Ripeti con consenso rifiutato e accettato: sono due condizioni distinte. Controlla che arrivi una sola richiesta e che il tracciamento rispetti la scelta. Registra i ritardi e gli spostamenti osservati, allegando screenshot o una registrazione dal pannello Performance di DevTools.

4. Conserva mediana, intervallo e prova del problema

   Per ogni profilo ordina i tre valori della metrica scelta e prendi quello centrale come mediana; conserva anche minimo e massimo. Indica quale immagine o blocco di testo determina LCP, oppure quale interazione rallenta, e allega il report che lo mostra. Dopo il rilascio ripeti la serie sulla nuova versione pubblica e lo stesso controllo funzionale.

Se vuoi misurare gli utenti reali della sola pagina, chi sviluppa può raccogliere Web Vitals con un sistema RUM, cioè di monitoraggio delle visite effettive, registrando versione, dispositivo e periodo. Per leggere le conversioni insieme alle prestazioni occorre poter associare prestazioni e risultato della stessa visita, nel rispetto del consenso. Il report aggregato di CrUX non permette di ricostruire l'esito commerciale della singola visita.

Dal sintomo all'intervento: che cosa verificare prima

In DevTools avvia la registrazione di un caricamento nel pannello Performance e seleziona l'evento LCP; nei report Lighthouse consulta l'elemento e la scomposizione LCP, quando disponibili. Nel pannello Network segui HTML e risorsa principale. Se cambi strumento o condizioni per approfondire, conserva questa traccia come diagnosi separata dalla serie confrontabile.

Se il modulo non recapita la richiesta o la invia due volte, correggi prima quel difetto. Per gli altri rallentamenti, valuta quante visite coinvolgono e quanto ostacolano l'azione richiesta. Se l'offerta compare tardi a tutti gli utenti mobile, l'intervento avrà di solito precedenza su un widget lento aperto da pochi. Per ogni correzione annota chi se ne occupa, il costo stimato e quale prova userai per verificare che abbia risolto il problema.

Per LCP, la guida di Google all'ottimizzazione distingue attesa dell'HTML, ritardo nell'avvio della risorsa, trasferimento e ritardo di rendering. Per le interazioni, usa la diagnosi di INP. Rimuovi i tag duplicati o inutilizzati, ma verifica consenso ed eventi necessari dopo ogni modifica: eliminare analytics può far sparire il dato senza risolvere il ritardo che interessa il cliente.

Un esempio: LCP da 4,0 a 2,4 secondi

Immagina una landing mobile con un'immagine principale caricata da JavaScript. La traccia mostra che la richiesta parte tardi e che il file è più grande del necessario. Chi sviluppa rende l'immagine presente nell'HTML iniziale, toglie il caricamento lazy e serve una variante più leggera. Testo, offerta e modulo restano uguali.

Supponiamo che le tre prove mobile restituiscano LCP di 3,9 / 4,0 / 4,2 secondi prima e 2,3 / 2,4 / 2,6 dopo. Le mediane passano da 4,0 a 2,4 secondi: la riduzione è di 1,6 secondi, pari al 40% del valore iniziale (1,6 / 4,0 × 100). Il TBT mediano resta a 180 ms e il CLS mediano a 0,02. Abbiamo quindi una pagina che mostra prima l'elemento LCP nelle prove di laboratorio; per le interazioni e i Core Web Vitals degli utenti reali servono le verifiche descritte sopra.

Se la pagina pubblicata conferma questi tempi e il modulo continua a funzionare, possiamo mantenere la modifica. Nel caricamento illustrato rimane però 1,1 secondo tra la fine del trasferimento e la comparsa dell'immagine. Il passo successivo è capire che cosa la trattiene: se deve aspettare del codice JavaScript, alleggerire ancora il file potrebbe non farla comparire prima.

Come valutare l'effetto sulle conversioni

Decidi prima che cosa conta come conversione. Per una landing di raccolta contatti, puoi contare gli utenti che hanno inviato almeno una richiesta ricevuta correttamente: due invii della stessa persona valgono una conversione. Il tasso è il numero di questi utenti diviso per tutti gli utenti inclusi nel confronto, moltiplicato per 100. Se stai valutando solo il traffico mobile, entrambi i conteggi devono riguardare quel pubblico e lo stesso periodo. Un clic sul pulsante, da solo, non conferma l'arrivo della richiesta.

Controlla anche quanti di questi utenti diventano contatti adatti al servizio, secondo i criteri del reparto commerciale, o completano un acquisto. Concedi a ogni richiesta lo stesso tempo per essere valutata, altrimenti quelle più recenti sembreranno di qualità peggiore soltanto perché nessuno le ha ancora esaminate.

Se puoi distribuire due versioni equivalenti nello stesso periodo, assegna casualmente gli utenti ad A o B e mantieni la variante nelle visite successive. Modifica soltanto il gruppo di interventi tecnici da valutare. Verifica che cache, server o codice sperimentale non facciano arrivare a entrambi la stessa ottimizzazione o introducano un ritardo diverso. Definisci campione, durata, indicatore principale e regola di decisione prima di partire: la guida CRO approfondisce la progettazione del test A/B.

Quando il traffico è insufficiente per un test A/B, oppure la modifica coinvolge un server usato da entrambe le versioni, puoi pubblicarla e monitorare ciò che accade. Annota anche i cambiamenti di budget, pubblico, creatività, offerta e tracciamento: potrebbero spiegare una variazione delle conversioni. Pubblicare gradualmente la modifica, senza assegnare gli utenti a caso, non elimina questo problema. La guida web.dev sul rapporto tra velocità e risultati aziendali descrive il collegamento delle metriche e l'uso degli esperimenti.

Immaginiamo di osservare la stessa landing per 14 giorni prima e 14 giorni dopo la correzione. In ciascun periodo registriamo 5.000 utenti mobile. Contiamo ogni utente una sola volta e valutiamo le richieste entro 7 giorni dal loro arrivo.

Il tasso di richiesta passa da 200 / 5.000 × 100 = 4,0% a 230 / 5.000 × 100 = 4,6%. Cresce quindi di 0,6 punti percentuali, pari al 15% rispetto al valore iniziale: (4,6 − 4,0) / 4,0 × 100. Anche il numero di utenti con una richiesta accettata sale, da 120 a 140: sul totale di 5.000 utenti, il tasso passa dal 2,4% al 2,8%. Leggiamo questi risultati 7 giorni dopo la fine di ciascun periodo, così anche le ultime richieste hanno avuto tutto il tempo previsto per la valutazione.

Supponiamo però che all'inizio del secondo periodo sia cambiata anche la creatività degli annunci. I 30 utenti in più che hanno inviato una richiesta potrebbero dipendere dalla pagina più rapida, dall'annuncio o da entrambi. Possiamo conservare la correzione tecnica già verificata, ma usare quel +15% per prevedere nuove vendite sarebbe ingiustificato. Per stimare l'effetto della velocità, il confronto più utile resta un test tra gruppi nello stesso periodo, quando è fattibile. Raccogliere altri dati prima e dopo aiuta il monitoraggio, ma non separa da solo l'effetto degli altri cambiamenti.

Se gli utenti escono prima che il tag si avvii, la misurazione può perdere proprio le visite più lente. Specifica quindi da dove provengono i conteggi: richieste di pagina ricevute dal server, visite registrate dagli analytics o utenti che hanno dato il consenso. Non dividere le conversioni di un gruppo per le visite di un altro. La guida su come misurare l'efficacia di una landing page approfondisce eventi e qualità dei dati.

Il registro prima/dopo e la decisione di rilascio

Compila una scheda per ogni pagina e modifica, allegando i report originali e le registrazioni del problema. Puoi copiare il modello qui sotto oppure usare il PDF stampabile. Alla fine indica se la correzione ha ridotto il ritardo e, separatamente, che cosa mostrano i dati sulle conversioni.

URL finale e versione prima/dopo:
Data e ora, profilo mobile/desktop, browser e versione dello strumento:
Rete e CPU, cancellazione dei dati del sito, consenso e accesso con account:
Problema osservato, elemento o interazione, report o registrazione allegata:
Causa da verificare, modifica proposta e persona che se ne occupa:
Mobile prima: prove 1 / 2 / 3; mediana, minimo e massimo per ogni metrica
Mobile dopo: prove 1 / 2 / 3; mediana, minimo e massimo per ogni metrica
Desktop prima: prove 1 / 2 / 3; mediana, minimo e massimo per ogni metrica
Desktop dopo: prove 1 / 2 / 3; mediana, minimo e massimo per ogni metrica
Per ogni prova: LCP in secondi, TBT in millisecondi e CLS; report allegato
Dati reali: fonte, URL o origine, periodo, dispositivo e 75° percentile;
se mancano, scrivere «non disponibili»
Prova sul telefono: offerta, modulo, errori, invio, conferma e consenso
Conversioni: periodo, pubblico incluso, fonte e regole di conteggio;
utenti totali e utenti con almeno una richiesta valida
Qualità: utenti con richiesta accettata o acquisto e tempo concesso per valutarli
Altre modifiche alle campagne o alla pagina, errori e dati mancanti:
Esito tecnico: mantenere, correggere o ritirare la modifica, e perché
Esito commerciale: che cosa si può concludere e prossimo controllo:

Scarica il registro stampabile in PDF

Se il modulo smette di funzionare dopo la modifica, correggila oppure ripristina la versione precedente. Se tutto funziona e il ritardo si riduce nelle stesse condizioni di prova, puoi mantenere la correzione e continuare a osservare le visite reali. Se invece i tempi restano nell'intervallo già rilevato prima, il test non mostra una riduzione chiara: rivedi la registrazione del problema prima di ripetere le prove.