La velocità di caricamento iniziale del tuo sito web o della tua app è la prima impressione che ricevono i tuoi utenti. In questa guida, elencheremo tecniche collaudate per eliminare secondi preziosi dal caricamento iniziale della pagina.
Sommario:
Tempo di caricamento iniziale
Il tempo che impiega da quando il tuo utente o cliente inserisce il nome di dominio del tuo sito web a quando vede il contenuto sono i pochi secondi più importanti che hai per fare una buona prima impressione.
Amazon ha scoperto che ogni 100 millisecondi di latenza costa loro l’1% delle vendite.
Eppure, molti sviluppatori web lo considerano un ripensamento. Vengono aggiunte sempre più librerie per sempre più funzionalità e gradualmente nel tempo iniziano a vedere meno conversioni. Peggio ancora, queste perdite di conversione sono difficili da rilevare perché abbandonano una pagina a caricamento lento prima che abbia il tempo di inviare qualsiasi metrica.
Alcune di queste sono tecniche che possono essere implementate sul front-end e altre sul back-end. Indipendentemente da ciò, le app Web devono essere caricate rapidamente.
Aggiungi le giuste misure
La prima cosa che devi fare è aggiungere le misure. Ci sono molte fasi del processo di caricamento e non saprai dove si trova il collo di bottiglia senza misurare i segmenti giusti.
Di seguito sono riportate le tappe più importanti del processo di caricamento:
Misure | Diagramma creato su Terrastruzzo
Ciò significa che dovresti tenere traccia delle metriche per ogni segmento di questo diagramma.
Vediamo come potresti farlo.
Richiesta del browser alla risposta servita:
Misura questo sul tuo server. Vuoi ottenere il momento in cui la tua API riceve la richiesta quando serve una risposta. A seconda che vengano effettuate chiamate esterne, ad esempio ai database, questo può essere molto breve o un collo di bottiglia significativo.
Risposta servita alla risposta ricevuta:
Questoèpiùdifficile da misurare, ma un modo per farloèaggiungere un timestamp quando la tua risposta lascia il tuo server e misurarlo con l’ora corrente dalla parte dell’utente nel primo momento possibile (un tag di script nell’intestazione dell’HTML pagina).
Risposta ricevuta alla prima vernice contenta:
La prima vernice contenta si riferisce a quando il primo elemento viene visualizzato sul DOM. Può essere qualcosa di semplice come un testo, uno sfondo o uno spinner di caricamento. Questo può essere misurato eseguendo Lighthouse negli strumenti di sviluppo di Chrome.
Dalla prima pittura contenta alla più grande pittura contenta:
Il disegno di contenuto più grande si riferisce a quando l’elemento più grande viene visualizzato nel viewport del browser dell’utente. Questo in genere segnala la fine della porzione di “rendering” del caricamento della pagina e l’utente vede una schermata popolata. Questo viene misurato anche eseguendo Lighthouse.
La più grande pittura di contenuto al momento dell’interattività:
Infine, il tempo per l’interattività si riferisce a quando l’utente può eseguire azioni come scorrere, fare clic e digitare. Può essere particolarmente frustrante se questa durata è lunga perché vedranno uno schermo renderizzato davanti a loro ma non potranno fare nulla quando si aspettano di poterlo fare! Questa è un’altra metrica che Lighthouse ci aiuta a misurare.
Riduci il codice
Ora che hai le misurazioni, puoi iniziare a fare le ottimizzazioni. Le ottimizzazioni hanno dei compromessi e le misurazioni ti diranno quali ne valgono la pena.
La pagina più veloce da caricare è una pagina vuota, ma è possibile aggiungere molto codice a un’app prima che qualcuno possa notare la differenza nella velocità di caricamento tra essa e una pagina vuota. Quello che spesso accade è che gli incrementi sono così piccoli che non si percepisce la differenza da build a build fino a quando un giorno, inizia a sembrare lento. Ti rendi conto che la tua app è gonfia ed è a questo punto che la riduzione del codice farà la differenza.
Ottieni due miglioramenti nella velocità quando riduci il codice:
- La tua app viene trasferita sulla rete più velocemente.
- Il browser dell’utente termina l’analisi del codice più rapidamente.
La prima accelerazione è piccola; poiché le richieste vengono compresse via cavo, se si taglia 1 MB di codice sorgente, si potrebbero ottenere solo 10 KB di risparmio sulla larghezza di banda. Tuttavia, l’accelerazione dall’analisi inferiore è significativa. I tuoi utenti stanno probabilmente eseguendo la tua app su un’intera gamma di browser e computer, molti dei quali non hanno la potenza di calcolo che potrebbe analizzare il codice così rapidamente come farebbe da solo.
Oppure potrebbero essere eseguiti su dispositivi mobili, con una potenza di calcolo ancora inferiore. La differenza può essere nell’ordine dei secondi.
Quindi meno codice hai, più velocemente il browser può terminare l’analisi e iniziare a eseguire la tua app. Anche se vuoi mostrare una schermata di caricamento controllata da Javascript, è preceduta dall’analisi di quel codice.
Ma non vuoi tagliare le funzionalità o eliminare effettivamente il codice. Fortunatamente, ci sono un paio di pratiche standard per ridurre il codice senza doverlo fare.
- Esegui il tuo codice attraverso minifiers. I minificatori eseguono ottimizzazioni come accorciare i nomi lunghi in nomi brevi (signUpDarkModeButton diventa ss), rimuovere i caratteri degli spazi bianchi e altri per rendere il codice il più compatto possibile senza perdere nulla.
- Importa parziali. Le biblioteche sono spesso piene di cose che non ti servono ma vengono confezionate insieme sotto un pacchetto ombrello. Forse vuoi solo una funzione specifica di una libreria di utilità, quindi invece di importare l’intera libreria, puoi importare solo il codice che ti serve.
- Codice morto tremante. A volte lasci il codice per scopi di debug o non hai ripulito a fondo una funzionalità deprecata e, sebbene sia nel tuo codice sorgente, non viene mai eseguita. Esistono strumenti nella toolchain JavaScript, come Webpack, in grado di rilevare codice morto o dipendenze inutilizzate e rimuoverli automaticamente dalla build di produzione.
Dividi il codice in blocchi
Dopo aver ridotto quanto più codice possibile dalla tua app complessiva, puoi pensare a comprimere ulteriormente questa idea e ridurre il codice necessario per il caricamento iniziale.
Supponiamo che il 20% del tuo codice stia alimentando alcune funzionalità della tua app a cui gli utenti possono accedere solo dopo pochi clic. Sarebbe tempo sprecato per il browser analizzare quel codice prima di mostrare una schermata di caricamento. Suddividere il codice in blocchi può ridurre significativamente il tempo per l’interattività.
Invece di avere un grafico delle dipendenze intrecciato delle importazioni per tutti i tuoi file Javascript, identifica le aree che possono essere facilmente tagliate. Ad esempio, forse un componente carica alcune librerie pesanti. Puoi isolare quel componente nel suo file e quindi importarlo solo quando l’utente è pronto per interagire con quel componente.
Esistono diverse librerie là fuori per posticipare il caricamento, a seconda del framework che stai utilizzando. Non è necessario esagerare con questo e suddividere ogni componente perché l’utente ha un caricamento iniziale rapido e deve attendere ogni interazione successiva. Trova i pezzi più grandi che puoi segmentare e suddividi lì il tuo codice sorgente.
Rendering lato server
Dato che i browser devono eseguire tutta quell’analisi e compilazione intensiva e avere utenti su Chromebook e dispositivi mobili, una tecnica comune per ridurre i tempi di caricamento è fare in modo che i tuoi server prendano parte di quel carico. Ciò significa che invece di fornire una pagina vuota e quindi utilizzare Javascript per compilare tutto il contenuto, come fanno oggigiorno la maggior parte delle app a pagina singola, puoi eseguire un motore Javascript sul tuo server (di solito Node.js) e compilare quanti più dati e contenuti possibile.
I tuoi server saranno molto più veloci e prevedibili dei browser degli utenti. Inevitabilmente, dovranno comunque analizzare del codice Javascript affinché l’app sia interattiva. Tuttavia, il rendering lato server può riempire gran parte del contenuto iniziale in modo che quando l’utente ottiene la pagina, mostra già una schermata di caricamento o una barra di avanzamento come minimo.
E se i dati sono necessari per la visualizzazione iniziale, il cliente non ha bisogno di fare una richiesta separata per ottenerli; sarà già idratato nell’app per essere utilizzato dal cliente.
Comprimi le risorse
Le risorse danno vita a una pagina e una pagina non sembra completamente caricata fino a quando tali risorse non terminano il rendering. Questo potrebbe essere il tuo sfondo, le icone dell’interfaccia utente, un’immagine del profilo utente, persino lo spinner di caricamento. Spesso, anche le risorse possono cambiare il layout, quindi se un utente inizia a provare a interagire con qualcosa, la pagina potrebbe continuare a saltare mentre le risorse vengono caricate. A volte, queste risorse sono la più grande vernice di contenuto.
Ma le risorse sono anche una delle parti più pesanti di un’app. Un’immagine può arrivare a diversi megabyte e il caricamento di molte icone può facilmente superare il limite massimo di richieste di rete simultanee del browser, causando un’incredibile coda di caricamento.
Non vuoi quasi mai scaricare un’immagine da Internet e poi farvi riferimento nella tua app. Le immagini dovrebbero essere ridimensionate alle loro dimensioni più piccole possibili a cui verranno mostrate. Se hai un profilo utente visualizzato in un minuscolo elemento di 50 pixel per 50 pixel, senza ridimensionamento, la tua app impiegherà del tempo per scaricare l’immagine completa che appare nitida come sfondo del desktop e quindi ridimensionarla fino alle dimensioni ridotte.
In secondo luogo, le immagini possono essere compresse a seconda del loro formato. Oggi il webm è il formato preferito, ma il campo della compressione sul web è in costante miglioramento e molti nuovi formati sono all’orizzonte. A causa della natura mutevole dei formati, alcuni browser potrebbero non supportare quelli più recenti! Fortunatamente, la tecnologia del browser può consentire al browser dell’utente di caricare qualunque formato supporti.
Quindi, comprimi nel formato più recente e migliore, ma mantieni anche una versione meno moderna e utilizza elementi di immagini e video che supportano i formati di fallback.
Conclusione
Queste sono cinque delle tecniche più efficaci per offrire ai tuoi utenti un primo caricamento incredibilmente veloce sulla tua app. Questi miglioreranno i tassi di conversione, la felicità degli utenti e persino le classifiche di ricerca, poiché la SEO premia i tempi di caricamento rapidi. In Terrastruzzoutilizziamo queste e altre tecniche in modo che gli utenti possano creare e visualizzare i diagrammi visualizzati in questo articolo il più rapidamente possibile.