L’arte di ottimizzare i siti web — Parte 2 - Medium Level
Questo articolo fa parte di una serie, puoi trovare il primo qui: https://medium.com/@ilasw/larte-di-ottimizzare-i-siti-web-parte-1-328378f8a9be
Nello scorso articolo abbiamo visto come possa essere importate ottimizzare un sito web, l’effort che attualmente i team spendono in questa pratica e quali sono le tecniche principali per ottenere dei risultati interessanti, oggi vedremo delle tecniche avanzate per aumentare la velocità effettiva e percepita dai nostri visitatori.
2.1 HTTPS && HTTP/2
HTTP/2, detto anche HTTP/2.0, è la nuova versione del protocollo HTTP che rende le applicazioni web più veloci, snelle e robuste, consentendo di fare a meno di alcune tecniche di ottimizzazione adottate fino ad ora.
Anche se non sembra il passaggio a questo protocollo di trasferimento aiuterà i nostri siti ad essere più ottimizzati grazie alle sue tante features:
- Da quando Let’s Encrypt ha reso possibile creare in modo autonomo i nostri certificati è possibile averlo quasi sempre Gratis o a bassissimo costo.
- Viene stabilita una sola connessione per server e quella connessione rimane aperta fino a quando il sito è aperto su browser, quindi si hanno, meno richieste per server e quindi un tempo di connessione inferiore.
- HTTP/2 usa HPACK, un formato di compressione per trasmettere in modo efficiente i campi Headers HTTP.
- Offre nuove funzionalità come la possibilità di impostare una scala di priorità nelle richieste a cui viene associata un peso e una dipendenza associata
- Questo protocollo è davvero troppo facile da impostare per non usarlo, ha mille funzioni native per ogni tecnologia per attivarlo in poche righe, ad esempio su Nginx si può attivare così:
2.2 Waterfall: L’Ordine di download delle risorse
Con il temine waterfall si intende l’ordine con cui il browser scarica, analizza e renderizza le risorse della pagina. Le pratiche per l’ottimizzazione del waterfall sono spesso ignorate e non si da particolare importanza a questo aspetto quando in realtà se la struttura della pagina è ben definita.
Sviluppare mischiando blocchi di HTML, CSS, JS crea numerosi blocchi nel rendering della pagina ogni volta che: si passa da una tipologia all'altra; si richiede una risorsa esterna; viene interpretato il codice JavaScript.
Con la conseguenza di aumento di latenza tra il momento in cui il contenuto inizia ad essere visibile a quando risulta essere effettivamente (DOMContentLoaded).
Molti Developer suggeriscono di mettere il CSS fondamentale per la pagina nel HEAD della pagina HTML: personalmente non amo questa soluzione, in quanto mischia il CSS con HTML, la ragione di questa pratica sta nel non dover caricare risorse esterne per iniziare a visualizzare la griglia e elementi fondamentali per la nostra grafica.
Caricare il CSS importante per prima, poi HTML ed infine JS: In generale la regola sempre verde è quella di incorporare tutti i nostri fogli di stile (meglio se pochi) nel <head> della pagina, per poi inserire dentro il <body> tutto il nostro HTML, e poco prima della chiusura di questo incorporare i JavaScript, ordinati per importanza. La ragione di questa pratica è quella di mostrare il contenuto con la nostra grafica mentre si attende che tutto il nostro HTML sia stato renderizzato (senza interruzioni) prima di avviare i nostri JS che sicuramente interagiranno con gli elementi della pagina.
Utilizzare async/defer per i tag script JavaScript non necessario da subito in quanto questo genere di codice è parser-blocking cioè quando il browser inizia a renderizzare HTML ed incontra uno script, sospende tutte le operazioni di lettura e rendering per poter eseguire il JavaScript. Per ridurre i blocchi possono essere utilizzati questi due attributi. In particolare:
- async: Lo script è caricato in modo asincrono e quando è pronto il parsing di HTML viene messo in pausa per eseguire lo script, quindi si riprende con il task precedente.
- defer: Lo script è caricato in modo asincrono e viene eseguito solo dopo che il parsing di HTML è completamente finito. Il vantaggio rispetto a mettere un JavaScript sul finire del <body> è che, sebbene l’esecuzione avvenga in entrambi i casi dopo il parsing di HTML nel caso di defer lo script è stato scaricato in parallelo all’analisi del codice HTML risultando più veloce.
2.3 Velocità percepita
La velocità percepita è la misura di quanto veloce le persone pensano sia il tuo sito, che in molti casi è più importante della reale velocità.
Facendo studi sull'esperienza di navigazione si è notato come si faccia molto più caso alle emozioni che il sito ci fa provare durante il caricamento rispetto a quello che realmente succede: un sito che carica 2 in secondi può risultare molto più lento di un competitor che impiega il doppio del tempo se questo adotta alcune pratiche per distrarre l’utente e fargli credere che qualcosa stia accadendo.
Le persone fanno molto più caso a cosa provano durante la navigazione rispetto a quello che sta realmente accadendo
Infatti il white screen è un’esperienza frustrante per l’utente, soprattutto da mobile, e lo porta a credere che il sito non sta rispondendo o che non funzioni.
Per migliorare l’esperienza dell’utente uno degli stratagemmi più usuali è quello di sfruttare l’effetto specchio-in-ascensore: infatti gli specchi di solito vengono appesi vicino agli ascensori, in modo da dare alle persone qualcosa da fare mentre aspettano che le porte si aprano, è risaputo infatti che fare o osservare qualcosa durante un’attesa distorce la nostra percezione del tempo facendo pensare che ne sia passato di meno. Ecco alcune buone pratiche:
Usare gli Skeleton Screens è una buona pratica quando si realizza una applicazione web in cui si fruiscono contenuti tramite APIs quella di mostrare nel tempo di caricamento dei blocchi che mostrano un anteprima della struttura che si otterrà una volta conclusa la chiamata al server. Questa pratica ha due vantaggi:
- Evitare il white screen e far vedere all'utente che il nostro sito sta funzionando e sta attualmente lavorando per servire la sua richiesta.
- Mostrare quale struttura avrà il sito per evitare sorprese e conseguente abbandono della pagina perché l’utente non trova quello che si aspettava
Quando si progettano gli skeleton screens, si consiglia in genere di associare un animazione al blocco per aumentare la percezione di dinamicità. In genere questa animazione si muove da sinistra verso destra, movimento che viene percepito più breve di quanto non sia il fade-in-out (opacità) dell’oggetto in loop.
Un altro modo per lavorare sulla velocità percepita è rendere il sito dinamico ed in costruzione in fase di loading come avviene su Instagram. Infatti caricare e rendere fruibile il contenuto nel tempo da un feedback positivo all’utente che può iniziare a navigare e porre l’attenzione sul contenuto che di volta in volta viene reso disponibile. In quest’ottica è necessario fare uso del lazy loading e assegnare una priorità al contenuto da scaricare come fa ad esempio medium che rende disponibile per primo il contenuto above the fold.
Conclusione
Con questo articolo abbiamo visto come portare l’ottimizzazione al livello successivo, lavorare sul server per sfruttare il nuovo protocollo HTTP2, abbiamo appreso come funziona il parsing ed il rendering del browser e come tratta i diversi tipi di contenuto. Come sia importante lavorare sulle emozioni che i nostri utenti provano durante la navigazione.
Nel possimo articolo vedremo come impostare i service worker per sfruttare il pre-caching e le funzionalità per navigare offline. Inoltre parleremo di Performance budget e del costo dell’uso del JavaScript.
Stay tuned!
Questo articolo fa parte di una serie:
- L’arte di ottimizzare i siti web — Parte 1 — Entry Level: https://medium.com/@ilasw/larte-di-ottimizzare-i-siti-web-parte-1-328378f8a9be
- L’arte di ottimizzare i siti web — Parte 2 -Medium Level: https://medium.com/@ilasw/larte-di-ottimizzare-i-siti-web-parte-2-medium-level-f48fb45fb202
