Utilizza i test A/B per valutare l'impatto della velocità del sito sulle metriche della tua attività.
Negli ultimi anni è stato consolidato che le prestazioni relative alla velocità del sito sono una parte significativa dell'esperienza utente e che il miglioramento avvantaggia diverse metriche aziendali, come i tassi di conversione e la frequenza di rimbalzo. A supporto di questo processo, sono stati pubblicati numerosi articoli e case study, tra cui How Website Performance Affects Conversion Rates di Cloudflare, Milliseconds Make Millions di Deloitte e Shopping for Speed su eBay.com, solo per citarne alcuni.
Anche se l'interesse per la velocità è chiaro, molte aziende faticano ancora a dare priorità a lavori che miglioreranno la velocità del loro sito perché non sanno esattamente in che modo questo influisce sui loro utenti e, di conseguenza, sulla propria attività.
In assenza di dati, è facile ritardare la velocità del sito e concentrarsi su altre attività. Uno scenario comune è che alcune persone in azienda riconoscano l'importanza della velocità del sito e non siano in grado di elaborare un'argomentazione e convincere più stakeholder a investire di conseguenza.
Questo articolo fornisce indicazioni di alto livello su come sfruttare i test A/B per valutare l'impatto della velocità del sito sulle metriche aziendali, in modo da rendere possibile un processo decisionale più efficace.
Passaggio 1: scegli una pagina su cui eseguire il test A/B
Il tuo obiettivo è verificare l'ipotesi che la velocità della pagina sia correlata alle metriche della tua attività. Per semplicità, all'inizio puoi limitare l'identificazione di una singola pagina per l'analisi. I lavori futuri possono estendersi a più pagine dello stesso tipo per verificare i risultati, quindi ad altre aree del sito. In fondo a questo passaggio puoi trovare alcuni suggerimenti su come iniziare. Il processo di selezione delle pagine dipende da diversi requisiti:
- Il test A/B deve essere eseguito solo sui dispositivi degli utenti di dispositivi mobili. A livello globale, i siti partner che assistiamo registrano in media oltre il 50% (e un aumento!) del traffico proveniente dai dispositivi mobili, ma questo può aumentare notevolmente in base a regione e verticale. I dispositivi mobili sono più sensibili ai siti web più lenti a causa di vincoli di elaborazione e memoria e di reti meno stabili. Inoltre, i modelli di utilizzo ovunque ti trovi indicano una maggiore velocità.
La pagina scelta per il test dovrebbe essere una parte importante della canalizzazione di conversione. Ogni sito ha uno scopo diverso, quindi ogni sito monitora metriche di successo diverse. Queste metriche sono generalmente correlate a un percorso dell'utente che viene analizzato utilizzando una canalizzazione. Ad esempio, gli utenti di un sito web di e-commerce dovranno navigare attraverso una home page, pagine di categoria, pagine di prodotto e una pagina di pagamento per completare un acquisto. Se ottimizzi per le conversioni, una di queste pagine è una buona candidata.
La pagina deve avere uno scopo specifico. A meno che il tuo sito non abbia una missione molto specifica, in genere è meglio evitare di utilizzare la home page per il test. Le home page di molti siti commerciali consentono di accedere a un'ampia varietà di funzionalità che possono rendere eccessivamente scorrevoli le tue analisi. Ad esempio, se ottimizzi le visualizzazioni di pagina per sessione su un sito di notizie, potrebbe essere meglio escludere le parti non commerciali del sito e concentrarti sulle sezioni e sugli articoli monetizzati.
La pagina scelta deve ricevere traffico sufficiente in modo da non dover attendere molto tempo prima di ottenere un risultato statisticamente significativo.
La pagina selezionata deve essere relativamente lenta. Infatti, più è lento, meglio è. Questo non significa solo che probabilmente ti sarà più facile migliorare la pagina, ma anche che i dati dovrebbero essere molto più chiari. Puoi eseguire una rapida scansione tramite il Report sulla velocità di Google Analytics o il report Segnali web essenziali di Search Console per scoprire quali delle tue pagine sono più lente.
La pagina deve essere relativamente stabile. Non aggiornare le pagine (ciò che potrebbe influire sulle metriche aziendali) fino al completamento del test. Minore è il numero di fattori esterni da considerare, più chiara sarà l'analisi.
Usando quanto riportato sopra come guida, dovrebbe essere un po' più chiaro quali sono le pagine idonee al test. Anche le pagine di destinazione degli annunci sono un'ottima scelta, perché probabilmente avrai a disposizione metriche aziendali, test A/B e analisi integrate. Nel caso in cui tu abbia ancora dubbi, di seguito puoi trovare alcune idee per ogni verticale:
- Siti web di contenuti: sezioni, articoli
- Vetrine: pagine di categoria, pagine di prodotto
- Media player: pagine di ricerca/rilevamento video, pagina di riproduzione video
- Servizi e scoperta (viaggi, auto a noleggio, registrazione ai servizi e così via): pagina iniziale di inserimento del modulo
Passaggio 2. Misura il rendimento
Esistono due modi generali per misurare le metriche: nel lab e sul campo. Abbiamo personalmente trovato che le metriche di misurazione sul campo (note anche come Real User Monitoring (RUM)) sono più utili perché rispecchiano l'esperienza di utenti reali. Esempi di librerie e servizi che possono aiutarti a generare report sui dati RUM includono Perfume, Firebase Performance Monitoring e eventi di Google Analytics.
Esistono molte metriche tra cui scegliere perché mirano ad acquisire aspetti diversi dell'esperienza utente. Ricorda che il tuo obiettivo è determinare se esiste una correlazione diretta tra la tua velocità e le metriche di business, quindi potrebbe essere utile tenere traccia di alcune metriche di velocità per determinare quale ha la correlazione più forte con il successo della tua attività. In generale, consigliamo di iniziare con i Segnali web essenziali. La libreria web-vitals.js può aiutarti a misurare alcuni dei Segnali web essenziali sul campo, ma tieni presente che il supporto del browser non è completo. Oltre ai Segnali web essenziali, vale la pena dare un'occhiata anche ad Altri Segnali web. Puoi anche definire metriche personalizzate, ad esempio "Tempo per il primo clic sull'annuncio".
Passaggio 3: crea varianti relative al rendimento della velocità
In questa fase implementerai le modifiche per creare una versione più rapida della pagina da testare rispetto alla versione attuale.
Un paio di aspetti da tenere presente:
- Evita di apportare modifiche alla UI o alla UX. Le modifiche non devono essere visibili agli utenti, se non a una pagina che sono più veloci dell'altra.
- Anche la misurazione è un aspetto chiave di questa fase. Durante lo sviluppo, è consigliabile utilizzare strumenti di test di laboratorio come Lighthouse per indicare l'effetto delle modifiche sulle prestazioni. Ricorda che le modifiche a una metrica spesso possono influire su un'altra. Una volta che le pagine sono online, attieniti al RUM per una valutazione più accurata.
Puoi creare varianti di rendimento in diversi modi. Ai fini del test, è consigliabile farlo nel modo più semplice possibile. Di seguito sono riportate alcune opzioni.
Crea una pagina più veloce
- Usa uno strumento come Squoosh per ottimizzare manualmente le immagini sulla pagina di test
- Utilizza la copertura del codice DevTools per eliminare manualmente il codice JavaScript o CSS inutilizzato solo per la pagina in questione
- Carica in modo efficiente script di terze parti
- Usa uno strumento come Critico per suddividere e incorporare i CSS essenziali
- Rimuovi il codice JavaScript non critico che non influisce sull'esperienza utente e di cui puoi fare a meno ai fini del test (ad esempio, alcune librerie di terze parti)
- Implementa il caricamento lento a livello di browser, che non è supportato da tutti i browser, ma che può comunque migliorare le prestazioni in modo significativo se supportato.
- Rimuovi i tag di analisi non critici o caricali in modo asincrono
Ulteriori ottimizzazioni da prendere in considerazione sono disponibili in Tempi di caricamento rapidi ed Elenco di controllo delle prestazioni frontend. Puoi anche utilizzare PageSpeed Insights per eseguire Lighthouse, che identifica le opportunità per migliorare il rendimento.
Rallenta la pagina
Questo potrebbe essere il modo più semplice per creare varianti e può essere ottenuto aggiungendo uno script semplice, rallentando i tempi di risposta del server, caricando immagini più grandi e così via. Il Financial Times ha optato per questa opzione per testare l'impatto delle prestazioni sulle metriche della sua attività. Per ulteriori informazioni, consulta FT.com più veloce.
Velocizzare il caricamento delle pagine
Per i casi in cui la pagina di test (ad esempio una pagina dei dettagli del prodotto) ha per lo più link che rimandano da una pagina diversa (ad esempio dalla home page), il precaricamento o il prerendering della pagina del prodotto direttamente dalla home page del gruppo di test velocizza il caricamento successivo della pagina. Tieni presente che in questo caso la suddivisione del test A/B (passaggio 4) viene eseguita nella home page. Inoltre, tutto questo potrebbe rallentare la prima pagina, quindi assicurati di misurarla e di tenerla in considerazione quando analizzi i risultati del test (passaggio 5).
Passaggio 4: crea un test A/B
Una volta create due versioni della stessa pagina in cui una è più veloce dell'altra, il passaggio successivo consiste nel suddividere il traffico per misurare l'impatto. In generale esistono molti strumenti e tecniche per eseguire i test A/B, ma tieni presente che non tutti i metodi sono adatti a misurare l'impatto sulle prestazioni in termini di velocità.
Se utilizzi uno strumento di test A/B come Optimizely o Optimize, ti consigliamo vivamente di impostare un test lato server anziché un test lato client, in quanto spesso questo test nasconde i contenuti della pagina fino al caricamento dell'esperimento, il che significa che il test A/B stesso altera le metriche da misurare. Se puoi eseguire solo i test lato client, ti consigliamo di impostare l'esperimento su una pagina diversa e di modificare i link alla pagina di test per suddividere il traffico. In questo modo la pagina di test non viene trascinata verso il basso dal test lato client.
Esempio di modifiche delle prestazioni dei test AB su una determinata pagina dei dettagli del prodotto (PDP) tramite test lato server:
La richiesta va al backend, che distribuisce gli utenti alle due diverse versioni della pagina. Sebbene questa configurazione sia generalmente buona, spesso sono necessarie risorse IT per configurare la suddivisione lato server.
Ecco un esempio di configurazione di test lato client in cui viene utilizzata la pagina precedente (la home page nel diagramma seguente) per eseguire il codice JavaScript di test:
Il codice JavaScript di test manipola il link in uscita per fornire ai due gruppi di test di utenti i link alle due versioni della pagina dei dettagli del prodotto in questione. Questa funzionalità è facile da configurare e gestire tramite strumenti di test A/B comuni come Optimize o Optimize e non influisce sul test del rendimento perché il codice JavaScript di test viene eseguito su una pagina diversa.
In alternativa, puoi scegliere due pagine che si comportano e hanno un rendimento molto simile (ad esempio per due prodotti molto simili). Applica le modifiche a una di queste e confronta la differenza nelle metriche nel tempo. Questo significa che non stai conducendo un test A/B adeguato, che può comunque essere molto approfondito.
Nel caso in cui la pagina di test venga utilizzata come pagina di destinazione per le campagne pubblicitarie, può essere utile utilizzare gli strumenti di test A/B integrati della rete pubblicitaria, come il test di suddivisione di annunci di Facebook o bozze ed esperimenti di Google Ads. Se non è un'opzione, puoi utilizzare due campagne con la stessa configurazione e impostare pagine di destinazione diverse come target.
Passaggio 5: analizza il test A/B
Dopo aver eseguito il test per un tempo sufficiente e aver raccolto dati sufficienti per acquisire fiducia sui risultati, è il momento di mettere a punto il tutto ed eseguire un'analisi. Il modo in cui eseguirlo dipende molto da come è stato eseguito il test, quindi esaminiamo le opzioni.
Se il test è stato eseguito su pagine di destinazione degli annunci utilizzando gli strumenti sopra menzionati, l'analisi deve essere semplice quanto la lettura dei risultati. Se utilizzi Bozze ed esperimenti di Google, esamina il confronto utilizzando la ScoreCard.
Piattaforme come Optimize o Optimize offrono anche modi semplici per interpretare i risultati e determinare l'impatto della velocità sulle tue pagine.
Se utilizzi Google Analytics o uno strumento simile, dovrai generare tu il report. Fortunatamente, Google Analytics semplifica la creazione di report personalizzati, quindi è da lì che puoi iniziare. Se hai inviato i dati sulla velocità a Google Analytics utilizzando una dimensione personalizzata, consulta la Guida ai report per scoprire come impostarli e includerli nei report personalizzati. Assicurati che il report copra la data dell'esperimento e sia configurato per mostrare entrambe le varianti. Che cosa deve essere incluso in questo report?
- In primo luogo, devi includere le metriche aziendali che più ti interessano: conversioni, visualizzazioni di pagina, annunci visualizzati, tasso di conversione, metriche e-commerce, percentuale di clic e così via.
- Inoltre, altre metriche standard delle pagine che sono ideali per migliorare la velocità del sito sono la frequenza di rimbalzo, la durata media della sessione e la percentuale di uscita.
Potresti anche dover applicare un filtro per i dispositivi mobili e assicurarti di escludere bot e altro traffico non correlato agli utenti. Un'analisi più avanzata filtrava anche per regione, reti, dispositivi, sorgente di traffico, profili e tipi di utenti, ad esempio nuovi utenti rispetto a visitatori abituali. Ogni gruppo di utenti può essere più o meno sensibile alle velocità inferiori e anche identificarle può essere molto utile.
Looker Studio (in precedenza Data Studio) o altri strumenti di visualizzazione dei dati semplificano l'integrazione di varie origini dati, tra cui Google Analytics. In questo modo è più facile condurre analisi e creare dashboard condivisibili con i numerosi stakeholder coinvolti nella gestione di un sito web moderno per l'ulteriore consenso. Ad esempio, il Guardian ha creato un sistema di avviso automatico che avvisava il team di redazione quando i contenuti pubblicati di recente superavano le soglie di dimensioni della pagina o di velocità, rischiando di generare utenti insoddisfatti.
Passaggio 6: trai le conclusioni e decidi i passaggi successivi
Una volta che disponi dei dati che collegano le metriche di rendimento e aziendali, puoi esaminare i risultati e iniziare a trarre conclusioni.
Se riesci a vedere chiaramente una correlazione tra il miglioramento delle prestazioni e il miglioramento delle metriche aziendali, riepiloga i risultati e segnalali a tutta l'azienda. Ora che si parla di prestazioni in termini di velocità in un "linguaggio commerciale" è più probabile che attiri l'attenzione di diversi stakeholder e tengano conto del rendimento della velocità del sito per tutti. Il passaggio successivo consiste nell'impostare i budget di rendimento in base ai risultati e pianificare il lavoro per rispettare questi budget. Poiché conosci il valore che può offrire questo lavoro, potrai stabilire le priorità di conseguenza.
Se non riesci a identificare una correlazione, esamina le avvertenze riportate di seguito e valuta se test simili devono essere eseguiti altrove sul sito (ad esempio, nell'intera canalizzazione di acquisto o su un tipo diverso di pagina).
Avvertenze
Potrebbero esserci diversi motivi per cui non è stata trovata una correlazione significativa tra le metriche di velocità del sito e quelle di business:
- La pagina scelta non ha sufficientemente influenza sulle metriche aziendali che stai esaminando. Ad esempio, una pagina di prodotto più veloce potrebbe non avere un grande effetto sui tassi di conversione se la pagina di pagamento è molto scadente o lenta. Valuta la possibilità di esaminare metriche più pertinenti come la frequenza di rimbalzo, le frequenze di aggiunta al carrello o qualsiasi altra metrica più direttamente collegata alla pagina che stai testando.
- La differenza in termini di velocità non è abbastanza significativa tra le due versioni. Deve essere valutato in base alle metriche RUM che stai misurando.
- Si è verificato un guasto nel meccanismo del test A/B. Il traffico potrebbe non essere distribuito correttamente o i dati delle analisi potrebbero non essere stati registrati correttamente. Per escludere ciò, ti consigliamo di eseguire un test A/A in cui testi la stessa versione di una pagina utilizzando lo stesso meccanismo di test e assicurati che non vi siano differenze nei risultati.
- La velocità del sito non influisce sulle metriche aziendali. Si tratta di un evento raro, ma può verificarsi nei casi in cui il tuo mercato di destinazione è meno sensibile alla velocità (ad es. si accede al sito principalmente da dispositivi potenti su una rete potente) o la domanda degli utenti è molto elevata e la scelta è limitata (ad es. un servizio di biglietteria che vende esclusivamente biglietti per spettacoli ad alta richiesta). Tieni presente che ciò non significa che un sito più veloce non migliorerà l'esperienza utente e, di conseguenza, influirà sulla reputazione del brand.
Conclusione
Anche se si è tentati di lanciare ottimizzazioni della velocità in tutto il sito, in genere è più utile nel lungo periodo capire cosa significa per gli utenti e per la società avere un sito web più veloce. È la differenza tra il dire "abbiamo migliorato FCP di 1,5 secondi" e "abbiamo migliorato FCP di 1,5 secondi e che ha migliorato i nostri tassi di conversione del 5%". In questo modo, potrai dare priorità a ulteriori attività, ottenere il consenso di diversi stakeholder e rendere le prestazioni relative alla velocità del sito un impegno a livello aziendale.