E-commerce: la percezione della velocità del sito web fa la differenza

Sappiamo tutti che la velocità del sito Web può fare un'enorme differenza per il tasso di conversione e la viscosità di un sito Web di e-commerce.

Un caso di studio di SOASTA ha affermato che il miglioramento della velocità di caricamento delle pagine mobili ha aumentato il tasso di conversione di oltre il 25%. Nella sua costante spinta a mettere l'utente al primo posto, Jeff Bezos, fondatore e CEO di Amazon, è notoriamente ossessionato dalla velocità di caricamento della pagina e spinge costantemente i suoi dipendenti a ridurre la velocità della pagina del sito Web di Amazon.

L'aumento del dominio dei dispositivi mobili ha amplificato la necessità di una maggiore velocità di caricamento della pagina poiché gli utenti navigano spesso nei siti Web con connessioni più lente.

Ci sono molti strumenti là fuori per aiutarti a migliorare la velocità delle pagine web come Yslow o Google Pagespeed Insights, e ci sono varie best practice come la minimizzazione e la fusione di css e js, l'uso di sprite CSS e la riduzione al minimo delle richieste di rete che uno sviluppatore front-end dovrebbe seguire per garantire che la velocità della pagina sia massimizzata.

Il problema che abbiamo è che una volta che segui le migliori pratiche standard e realizzi le grandi vincite, inizierai presto a vedere rendimenti decrescenti sugli sforzi per migliorare la velocità complessiva della pagina.

Puoi dedicare molto tempo a miglioramenti incrementali sempre più piccoli e questo sarà un processo costoso e dispendioso in termini di tempo. Gli sviluppatori front-end con le competenze e l'esperienza necessarie per lavorare a questo livello sono sorprendentemente scarsi e costosi.

Ci sono alcune cose che non puoi controllare come la latenza di rete o la velocità della connessione mobile, quindi c'è un limite a ciò che può essere ottenuto con la velocità della pagina grezza. Su una connessione 3G ovunque tra 600 ms e 1 s viene consumato da spese generali di rete obbligatorie, per le quali non puoi fare nulla. Sulla base di un tempo di caricamento della pagina desiderato di 2 secondi, questo ci dà solo 1 secondo con cui giocare. Questo non è molto.

Non si può negare che la velocità della pagina grezza è molto importante e tutti gli sviluppatori dovrebbero seguire almeno le migliori pratiche standard.

Questo articolo, tuttavia, non discuterà come far caricare la tua pagina più velocemente. Ci sono molti articoli là fuori a riguardo ed è tutto un po' tecnico.

Questo articolo si concentrerà sulla percezione della velocità della pagina.
Cosa è più importante: quanto velocemente si carica la pagina o quanto velocemente l'utente percepisce che si carica?

Sicuramente la percezione è ciò che conta di più per l'utente.

Velocità del sito web: prime impressioni

Concentriamoci sulla home page del tuo sito web. È probabile che contenga una navigazione in alto, una barra di ricerca, un banner eroe, forse collegamenti a categorie chiave, un carosello e alcuni contenuti. Le home page tendono ad essere piuttosto pesanti e caricare rapidamente tutti questi contenuti su una connessione mobile sarà una grande sfida.

La chiave qui è dare la priorità al caricamento dei contenuti critici prima di altri contenuti: offri all'utente qualcosa di importante da vedere il più rapidamente possibile.

Mentre elaborano queste informazioni critiche, puoi quindi iniziare a caricare il livello di contenuto successivo.

Su un dispositivo mobile, gran parte del contenuto inizierà sotto il ripiegamento e pertanto dovrebbe essere caricato dopo il contenuto sopra il ripiegamento. È pratica comune unire e minimizzare JavaScript. Questa è normalmente considerata una procedura consigliata, ma può impedirti di dare la priorità al caricamento di JavaScript critico prima del codice meno critico. Invece potresti considerare di dividere il tuo JavaScript minimizzato e unito e caricarlo progressivamente secondo necessità. Non è necessario caricare il JavaScript richiesto per eseguire una ricerca prima ancora di caricare la casella di ricerca. Gli utenti non digiteranno caratteri nel campo di ricerca per almeno un paio di secondi durante il caricamento della pagina.

Diamo un'occhiata a un sito che lo fa molto bene. Amazon ha suddiviso la consegna di risorse e contenuti per garantire che all'utente vengano forniti contenuti critici il prima possibile e quindi caricare progressivamente le risorse in ordine di priorità.

Questo test è stato eseguito su un simulatore iPhone 6 con una buona connessione 3G e cache disabilitata. Dopo che la pagina è stata inizialmente caricata, ho avviato un aggiornamento completo.

In poco più di 600 ms ho qualcosa che inizia a caricare con il mio nome nell'intestazione. Noterai inoltre che sono state effettuate solo 6 chiamate di rete e caricate 5 risorse (3 file css e 2 immagini).

Solo 50 ms dopo ora vedo i componenti chiave dell'intestazione e il banner dell'eroe principale. Ho già la percezione della velocità poiché i contenuti chiave mi vengono consegnati molto rapidamente e c'è qualcosa che i miei occhi e il mio cervello possono elaborare mentre vengono caricati contenuti aggiuntivi.

Dopo solo 1 secondo viene caricata la navigazione principale. Noterai che in questa fase non è visibile alcuna barra di scorrimento. Ciò significa che al momento non ci sono contenuti below the fold. Non è stato sprecato tempo prezioso nel caricare questo contenuto che l'utente non può vedere. Noterai inoltre che finora sono state presentate solo 13 richieste.

In poco meno di 2 secondi, ora ho una nuova sezione di contenuti importanti.

In meno di 3 secondi, ora percepisco che la pagina è stata completamente caricata mentre la pagina in realtà ha impiegato poco meno di 5 secondi per caricarsi nella sua interezza. Ciò suggerisce che percepisco il sito completamente caricato quando in realtà è caricato solo al 60%.

I tempi effettivi di consegna dei contenuti variano da persona a persona, ma questo illustra molto chiaramente come Amazon stia dando la priorità al caricamento dei contenuti mobili per garantire che i contenuti critici vengano caricati il ​​più rapidamente possibile e che gli utenti percepiscano il sito che inizia a caricarsi molto rapidamente.

Ora diamo un'occhiata a un sito Web che non lo fa così bene. Questo test è stato eseguito utilizzando esattamente gli stessi strumenti e la stessa velocità di rete del precedente test Amazon. Sebbene il sito di Charles Tyrwhitt dia la priorità ad alcuni contenuti, c'è molto di più che si potrebbe fare per avvicinarsi all'ottimizzazione di Amazon.

Non vedo alcun contenuto per quasi 7,5 secondi. Immediatamente ho la percezione che questo sito sia lento sul mio dispositivo mobile. Sebbene il sito dia la priorità al contenuto dell'intestazione e a un banner eroe, puoi vedere che a questo punto sono state fatte oltre 90 richieste e, come posso vedere la barra di scorrimento, è chiaro che il contenuto deve essere stato caricato sotto il ripiegamento.

Dopo 8,5 secondi posso vedere che un carosello inizia a caricarsi. Il numero di richieste non è cambiato, il che suggerisce che la maggior parte delle richieste relative al contenuto viene effettuata all'inizio del caricamento della pagina.

Solo dopo quasi 22 secondi percepisco che il sito è ora completamente caricato. La pagina ha effettivamente impiegato un totale di 28,4 secondi per caricarsi completamente. Ciò suggerisce che percepisco che la pagina è stata completamente caricata quando in realtà era caricata al 77%.

È facile vedere la chiara differenza tra le 2 esperienze. Sebbene la home page mobile di Amazon si carichi significativamente più velocemente della home page di Charles Tyrwhitt, è stato fatto uno sforzo per garantire che gli utenti percepiscano che è ancora più veloce. L'utente inizia a vedere qualcosa che si carica entro il 12,5% del tempo di caricamento totale della pagina, mentre gli utenti del sito Web di Charles Tyrwhitt vedono solo qualcosa che accade entro il 26% del tempo di caricamento totale della pagina. La home page di Amazon ha effettuato 6 richieste di rete prima che l'utente veda i progressi, mentre la home page di Charles Tyrwhitt ha effettuato 90 richieste.

Questo non vuole essere eccessivamente critico nei confronti di Charles Tyrwhitt in quanto non sono affatto unici nel modo in cui hanno costruito il loro sito web. La migliore pratica accettata è stata seguita in un certo numero di aree, ma sembra che si potrebbe fare molto di più per migliorare la percezione della velocità così come la velocità effettiva.

Migliora la velocità del sito web dando priorità ai CSS

È abbastanza comune per gli sviluppatori front-end inserire la maggior parte dei CSS di un sito Web in una manciata di file e utilizzare sempre CSS esterni, anziché inline. Il problema che ciò causa è che è necessario caricare un file CSS di grandi dimensioni prima che qualsiasi contenuto possa essere mostrato a un utente.

Una soluzione a questo è dividere i file CSS e caricarli in sequenza con il contenuto critico. Se osserviamo l'esempio di Amazon, caricano un file CSS di appena 6,5k di dimensione come una delle loro 6 richieste iniziali. Questo file contiene il CSS necessario per definire lo stile del contenuto critico nella loro home page. In effetti, la dimensione totale di tutti i file CSS richiesti prima che l'utente veda il contenuto sulla home page mobile di Amazon è inferiore a 40k mentre è superiore a 500k sulla home page di Charles Tyrwhitt.

Questa pratica consente di fornire contenuti critici all'utente molto rapidamente e aiuta a rafforzare la percezione della velocità.

Fai lo stesso con JavaScript

Oltre a dare la priorità ai CSS, dovresti considerare come farlo anche con JavaScript. Quasi tutti i siti Web di e-commerce faranno molto affidamento su JavaScript per funzionare. Questo va bene fintanto che JavaScript non sta bloccando il caricamento di contenuti critici. Se prendo di nuovo l'esempio del sito Web di Charles Tyrwhitt e disabilito JavaScript sul mio browser, ora vedo il caricamento del contenuto entro 4,5 secondi. Questo è un enorme cambiamento nella mia percezione della velocità di quel sito Web e il JavaScript caricato prima del contenuto critico non ha avuto alcun impatto su quel contenuto e quindi non c'è motivo per cui il JavaScript non possa essere caricato dopo quel contenuto.

C'è molto che gli sviluppatori web possono imparare dal modo in cui siti web come Amazon si concentrano sulla percezione della velocità del loro sito web e sulla velocità effettiva. Sebbene il loro sito Web sia chiaramente molto veloce, gli utenti lo percepiscono come ancora più veloce a causa del modo in cui danno la priorità a mostrare all'utente i contenuti critici prima di ogni altra cosa.

Molto è stato fatto dell'impatto che la velocità può avere sul tasso di conversione e i rivenditori dovrebbero considerare di investire nell'ottimizzazione delle prestazioni percepite del sito Web insieme alla velocità effettiva del sito Web.