Utilizza i test A/B per valutare l'impatto della velocità del sito sulle metriche della tua attività.
Negli ultimi anni è stato ampiamente dimostrato che la velocità del sito rappresenta una parte significativa dell'esperienza utente e che il suo miglioramento è vantaggioso per diverse metriche aziendali, come i tassi di conversione e di abbandono. Per avvalorare questa affermazione sono stati pubblicati diversi articoli e case study, tra cui How Website Performance Affects Conversion Rates (In che modo il rendimento del sito web influisce sui tassi di conversione) di Cloudflare, Milliseconds Make Millions (I millisecondi fanno milioni) di Deloitte e Shopping for Speed on eBay.com (Shopping per la velocità su eBay.com), per citarne alcuni.
Anche se la necessità di velocità è chiara, molte aziende hanno ancora difficoltà a dare la priorità alle attività che miglioreranno la velocità del sito perché non sanno esattamente in che modo influiscono sui loro utenti e, di conseguenza, sulla loro attività.
In assenza di dati, è facile ritardare il lavoro sulla velocità del sito e concentrarsi su altre attività. Uno scenario comune è che alcune persone dell'azienda riconoscano l'importanza della velocità del sito, ma non siano in grado di argomentare la questione e convincere più stakeholder a investire di conseguenza.
Questo articolo fornisce indicazioni generali su come utilizzare i test A/B per valutare l'impatto della velocità del sito sulle metriche aziendali, in modo da poter prendere decisioni più efficaci in merito.
Passaggio 1: scegli una pagina da sottoporre a test A/B
Il tuo scopo è verificare l'ipotesi che la velocità della pagina sia correlata alle tue metriche aziendali. Per semplicità, inizialmente puoi limitarti a identificare una singola pagina per l'analisi. Il lavoro futuro può essere esteso a più pagine dello stesso tipo per verificare i risultati e poi ad altre aree del sito. Alcuni suggerimenti su come iniziare sono riportati nella parte inferiore di questo passaggio. La procedura di selezione delle pagine è basata su diversi requisiti:
- Il test A/B deve essere eseguito solo sui dispositivi degli utenti di dispositivi mobili. A livello mondiale, i siti partner che supportiamo registrano in media più del 50% (e in crescita) del loro traffico proveniente da dispositivi mobili, ma questo valore può aumentare notevolmente in base alla regione e al verticale. I dispositivi mobili sono più sensibili ai siti web più lenti a causa di vincoli di elaborazione e memoria e reti meno stabili. Inoltre, i modelli di utilizzo in movimento fanno sì che le aspettative in termini di velocità siano più elevate.
La pagina scelta per il test deve essere una parte importante della canalizzazione di conversione. Ogni sito ha uno scopo diverso, pertanto monitora metriche di successo diverse. Queste metriche sono in genere correlate al percorso dell'utente, che viene analizzato utilizzando una canalizzazione. Ad esempio, per completare un acquisto, gli utenti di un sito web di e-commerce dovranno visitare una home page, pagine di categoria, pagine di prodotto e una pagina di pagamento. Se stai ottimizzando per le conversioni, una di queste pagine sarebbe una buona candidata.
La pagina deve avere un unico scopo. A meno che il tuo sito non abbia un'esplicita finalità, in genere è meglio evitare di utilizzare la home page per il test. Le home page di molti siti commerciali sono portali che offrono una vasta gamma di funzionalità che rendono la tua analisi poco chiara. Ad esempio, se stai ottimizzando per le visualizzazioni di pagina per sessione su un sito di notizie, potrebbe essere meglio escludere le parti non commerciali del sito e concentrarti su sezioni e articoli monetizzati.
La pagina scelta deve ricevere traffico sufficiente per non dover attendere molto prima di ottenere un risultato statisticamente significativo.
La pagina selezionata deve essere relativamente lenta. Anzi, più lento è, meglio è. Ciò significa non solo che probabilmente avrai più facilità a migliorare la pagina, ma anche che i dati dovrebbero essere molto più chiari. Puoi eseguire una rapida indagine tramite il report 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 (qualsiasi elemento che possa influire sulle metriche dell'attività) fino al completamento del test. Meno fattori esterni sono da considerare, più accurata sarà l'analisi.
Se segui le indicazioni riportate sopra, dovresti avere un quadro più chiaro delle pagine adatte al test. Anche le pagine di destinazione degli annunci sono una buona scelta, perché probabilmente avrai a disposizione metriche aziendali, test A/B e analisi integrate. Se hai ancora dubbi, ecco alcune idee per verticale:
- Siti web di contenuti: sezioni, articoli
- Vetrine: pagine delle categorie, pagine dei prodotti
- Media player: pagine di ricerca/scoperta di video, pagina di riproduzione di video
- Servizi e scoperta (viaggi, auto a noleggio, registrazione di servizi e così via): pagina di inserimento iniziale del modulo
Passaggio 2: misura il rendimento
Esistono due modi generali per misurare le metriche: in laboratorio e sul campo. Personalmente, abbiamo riscontrato che la misurazione delle metriche sul campo (nota anche come monitoraggio degli utenti reali (RUM)) è più utile perché riflette l'esperienza degli utenti reali. Esempi di librerie e servizi che possono aiutarti a generare report sui dati RUM include Perfume, Firebase Performance Monitoring ed Eventi Google Analytics.
Esistono molte metriche tra cui scegliere perché hanno lo scopo di acquisire diversi aspetti dell'esperienza utente. Ricorda che il tuo obiettivo è determinare se esiste una correlazione diretta tra la velocità e le metriche aziendali, pertanto potrebbe essere utile monitorare alcune metriche di velocità per determinare quale ha la correlazione più stretta con il successo della tua attività. In generale, ti consigliamo di iniziare con i Segnali web essenziali. La libreria web-vitals.js può aiutarti a misurare alcuni dei Core Web Vitals sul campo, anche se tieni presente che il supporto dei browser non è del 100%. Oltre ai Core Web Vitals, vale la pena dare un'occhiata anche agli altri indicatori web. Puoi anche definire metriche personalizzate, ad esempio "Tempo per primo clic sull'annuncio".
Passaggio 3: crea varianti di rendimento in base alla velocità
In questa fase implementerai le modifiche per creare una versione più rapida della pagina da testare rispetto alla versione corrente.
Ecco un paio di aspetti da tenere presente:
- Evita di apportare modifiche all'interfaccia utente o all'esperienza utente. A parte il fatto che una pagina è più veloce dell'altra, le modifiche devono essere invisibili agli utenti.
- Anche la misurazione è un aspetto fondamentale di questa fase. Durante lo sviluppo, è consigliabile utilizzare strumenti di test di laboratorio come Lighthouse per indicare l'effetto delle modifiche sul rendimento. Tieni presente che le modifiche apportate a una metrica possono spesso influenzarne un'altra. Una volta pubblicate le pagine, utilizza RUM per una valutazione più accurata.
La creazione di varianti di rendimento può essere eseguita in diversi modi. Ai fini del test, è consigliabile eseguire questa operazione nel modo più semplice possibile. Di seguito sono riportate alcune opzioni.
Creare una pagina più veloce
- Utilizza uno strumento come Squoosh per ottimizzare manualmente le immagini nella pagina di test
- Utilizza la copertura del codice di DevTools per eliminare manualmente il codice JavaScript o CSS non utilizzato solo per quella pagina
- Carica in modo efficiente gli script di terze parti
- Utilizza uno strumento come Critical per suddividere e incorporare il CSS fondamentale
- 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, determinate librerie di terze parti)
- Implementa il lazy loading a livello di browser, che non è supportato da tutti i browser, ma può comunque migliorare notevolmente le prestazioni dove è supportato
- Rimuovi i tag di analisi non critici o caricali in modo asincrono
Puoi trovare altre ottimizzazioni da prendere in considerazione in Tempi di caricamento rapidi e nella lista di controllo per il rendimento frontend. Puoi anche utilizzare PageSpeed Insights per eseguire Lighthouse, che identifica le opportunità per migliorare il rendimento.
Rallentare la pagina
Questo potrebbe essere il modo più semplice per creare varianti e può essere ottenuto aggiungendo un semplice script, rallentando i tempi di risposta del server, caricando immagini più grandi e così via. Il Financial Times ha scelto questa opzione quando ha testato l'impatto del rendimento sulle metriche aziendali: consulta Un sito più veloce.
Velocizzare il caricamento delle pagine
Nei casi in cui la pagina di test (ad esempio una pagina dei dettagli del prodotto) sia collegata principalmente da un'altra pagina (ad esempio la home page), il prefetching o il prerendering della pagina del prodotto direttamente dalla home page per il gruppo di test velocizzerà il caricamento successivo della pagina. Tieni presente che in questo caso la suddivisione del test A/B (passaggio 4) avviene nella home page. Inoltre, tutto ciò potrebbe rallentare la prima pagina, quindi assicurati di misurarlo e di tenerlo in considerazione quando analizzi i risultati del test (passaggio 5).
Passaggio 4: crea un test A/B
Una volta che hai due versioni della stessa pagina, di cui una è più veloce dell'altra, il passaggio successivo è suddividere il traffico per misurarne l'impatto. In generale, esistono molti metodi e strumenti per eseguire test A/B, ma tieni presente che non tutti sono adatti per misurare l'impatto sulla velocità del rendimento.
Se utilizzi uno strumento per i test A/B come Optimizely o Optimize, ti consigliamo vivamente di configurare un test lato server anziché uno lato client, poiché i test A/B lato client spesso funzionano nascondendo i contenuti della pagina fino al caricamento dell'esperimento, il che significa che il test A/B stesso potrebbe falsare le metriche che volevi misurare. Se puoi eseguire solo test lato client, ti consigliamo di configurare 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 stessa non viene rallentata dal test lato client.
Esempio di modifiche del rendimento dei test A/B in una determinata pagina dei dettagli del prodotto (PDP) tramite i test lato server:
La richiesta viene inviata al backend, che distribuisce gli utenti nelle due diverse versioni della pagina. Sebbene in genere si tratti di una buona configurazione, spesso è necessaria la presenza di risorse IT per configurare la suddivisione lato server.
Ecco un esempio di configurazione dei test lato client, che utilizza la pagina precedente (la home page nel diagramma di seguito) 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 scheda di prodotto in questione. È facile da configurare e da gestire tramite strumenti di test A/B comuni come Optimizely o Optimize e non influisce sul test di 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 poi confronta la differenza nelle metriche nel tempo. Ciò significa che non stai effettuando un test A/B corretto, ma i risultati possono comunque essere molto utili.
Se la pagina di test viene utilizzata come pagina di destinazione per le campagne pubblicitarie, può essere utile utilizzare gli strumenti di test A/B integrati della tua rete pubblicitaria, come il test di suddivisione degli annunci di Facebook o le bozze e gli esperimenti di Google Ads. Se questa opzione non è disponibile, 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 periodo di tempo sufficiente e aver raccolto dati sufficienti per avere fiducia nei risultati, è il momento di mettere tutto insieme ed eseguire un'analisi. La procedura dipende in gran parte dalla modalità di esecuzione del test, quindi vediamo le opzioni a tua disposizione.
Se il test è stato eseguito sulle pagine di destinazione degli annunci utilizzando gli strumenti sopra indicati, l'analisi dovrebbe essere semplice come leggere un risultato. Se utilizzi le bozze e gli esperimenti di Google, dai un'occhiata al confronto utilizzando la ScoreCard.
Piattaforme come Optimizely o Optimize offrono anche modi facili per interpretare i risultati e determinare l'impatto della velocità sulle tue pagine.
Se utilizzi Google Analytics o uno strumento simile, dovrai elaborare autonomamente il report. Fortunatamente, Google Analytics semplifica notevolmente la creazione di report personalizzati, quindi è da qui che devi iniziare. Se hai inviato i dati sulla velocità a Google Analytics utilizzando una dimensione personalizzata, consulta la guida ai report per scoprire come configurarli 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 contenere questo report?
- Innanzitutto, devi includere le metriche aziendali che ti interessano maggiormente: conversioni, visualizzazioni di pagina, annunci visualizzati, tasso di conversione, metriche di e-commerce, tasso di clic e così via.
- Inoltre, altre metriche standard delle pagine che sono utili anche per migliorare la velocità del sito sono il tasso di abbandono, la durata media della sessione e la percentuale di uscita.
Potrebbe anche essere necessario filtrare per dispositivi mobili e assicurarsi di escludere i bot e altro traffico non proveniente da utenti. Un'analisi più avanzata filtrerebbe anche in base a regione, reti, dispositivi, fonte di traffico e profili e tipi di utenti, ad esempio nuovi utenti rispetto a visitatori abituali. Ogni gruppo di utenti può essere più o meno sensibile a velocità inferiori e anche identificarli è 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 è facile eseguire analisi e anche creare dashboard condivisibili con i numerosi stakeholder coinvolti nella gestione di un sito web moderno per un 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 dimensione o velocità della pagina e potevano causare insoddisfazione degli utenti.
Passaggio 6: trarre conclusioni e decidere i passaggi successivi
Una volta ottenuti i 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 del rendimento e il miglioramento delle metriche aziendali, riepiloga i risultati e genera report per l'intera azienda. Ora che puoi parlare di prestazioni in termini "tecnici", hai maggiori probabilità di attirare l'attenzione di diversi stakeholder e di mettere le prestazioni in termini di velocità del sito al centro dell'attenzione di tutti. Il passaggio successivo consiste nell'impostare i budget di rendimento in base ai risultati e pianificare il lavoro per rispettarli. Poiché conosci il valore di questo lavoro, puoi dare la priorità di conseguenza.
Se non riesci a identificare una correlazione, consulta le limitazioni riportate di seguito e valuta se eseguire test simili altrove sul sito (ad esempio nell'intera canalizzazione di acquisto o in un tipo diverso di pagina).
Avvertenze
Potrebbero esserci diversi motivi per cui non viene trovata una correlazione significativa tra le metriche sulla velocità del sito e quelle aziendali:
- La pagina scelta non ha un'influenza sufficiente sulle metriche aziendali che stai esaminando. Ad esempio, una pagina di prodotto più veloce potrebbe non avere un grande impatto sui tassi di conversione se la pagina di pagamento è molto spiacevole o lenta. Valuta la possibilità di esaminare metriche più pertinenti, come i tassi di abbandono, i tassi di aggiunta al carrello o qualsiasi altra metrica più direttamente collegata alla pagina che stai testando.
- La differenza di velocità tra le due versioni non è sufficientemente significativa. Questo valore deve essere valutato in base alle metriche RUM che stai misurando.
- Esiste un problema con il meccanismo di test A/B. Il traffico potrebbe non essere distribuito correttamente o i dati di analisi non essere registrati correttamente. Per escludere questa possibilità, valuta la possibilità di eseguire un test A/B in cui testare la stessa versione di una pagina utilizzando lo stesso meccanismo di test e assicurati che non ci siano differenze nei risultati.
- La velocità del sito non influisce sulle metriche della tua attività. Si tratta di un caso raro, ma può verificarsi nei casi in cui il mercato di destinazione è meno sensibile alla velocità (ad es. si accede al sito principalmente da dispositivi potenti su una rete affidabile) o la domanda degli utenti è molto elevata e la scelta è limitata (ad es. un servizio di vendita di biglietti che vende esclusivamente biglietti per spettacoli molto richiesti). Tieni presente che questo non significa che un sito più veloce non migliorerà l'esperienza utente e di conseguenza influenzerà la reputazione del brand.
Conclusione
Sebbene sia allettante lanciare ottimizzazioni della velocità nell'intero sito, solitamente è più vantaggioso a lungo termine comprendere innanzitutto cosa significa per gli utenti e per la tua azienda avere un sito web più veloce. È la differenza tra dire "abbiamo migliorato il tempo di caricamento della prima pagina di 1,5 secondi" e "abbiamo migliorato il tempo di caricamento della prima pagina di 1,5 secondi e questo ha migliorato i nostri tassi di conversione del 5%". In questo modo potrai dare la priorità al lavoro successivo, ottenere il consenso di diversi stakeholder e rendere il miglioramento della velocità del sito un impegno di tutta l'azienda.