Pianificazione per la performance

Voglio che tu ti chieda, quando stai creando qualcosa, quando stai facendo prototipi delle interazioni, sto pensando al mio orologio o a quello dell’utente?

Paul Ford, “10 Timeframes”

Non stiamo facendo un buon lavoro#section1

Sulle moderne reti mobile sono ancora comuni i tempi di page load nell’ordine dei dieci secondi e questo tempo è solo una frazione di quanto in effetti ci vuole per caricare una pagina in paesi con reti più vecchie e limitate? Perché è così lento? Perlopiù è colpa nostra: i nostri siti sono troppo pesanti e spesso vengono assemblati e inviati in maniera da non sfruttare il modo in cui funzionano i browser. Secondo HTTP Archive, in media, un sito web pesa 1.7 megabytes (probabilmente adesso sono un po’ più pesanti, quindi vi conviene ricontrollare). A peggiorare le cose, la maggior parte dei siti esaminati da HTTP Archive non sono nemmeno responsive, ma sono focalizzati su un particolare use case: il classico computer desktop con uno schermo grande.

Sono brutte notizie per i designer responsive (e, ehm, responsabili) che hanno come obiettivo quello di supportare molti tipi di device con una singola codebase, piuttosto che concentrarsi su un unico tipo. A dire il vero, molte delle critiche mosse al responsive design riguardano l’eccessiva dimensione di file dei siti responsive, come il bellissimo Airbrake MX site di Oakley, che originariamente fu lanciato con una dimensione di file pari a 80 megabyte (sebbene poi sia stato ottimizzato per essere più responsabile), o la homepage piena di media di Disney, che manda un sito responsive da 5 megabyte a tutti i device.

Perché alcuni siti responsive sono così grossi? Cercare di supportare tutti i browser e i device con una sola codebase sicuramente ha come conseguenza quella di far aumentare la dimensione dei file se non si prendono misure per impedirlo. La natura veramente responsive del design implica l’invio di codice che è pronto per rispondere a condizioni che possono verificarsi oppure no, e l’invio di codice solo quando e dove è necessario pone degli ostacoli insidiosi stando allo stato degli strumenti attualmente a nostra disposizione.

Non temete!#section2

Si può ottenere un responsive design responsabile anche per i siti più complessi e pieni di contenuto, ma non succede automaticamente. Inviare siti responsive veloci richiede una concentrazione precisa sui nostri sistemi di delivery, perché il modo in cui inviamo e applichiamo i nostri asset ha un impatto enorme sulla performance percepita ed effettiva del page load. In effetti, il modo in cui inviamo il codice è più importante di quanto pesi il nostro codice.

Inviare responsabilmente è difficile, quindi questo capitolo approfondirà molto e in maniera pratica come ottimizzare gli asset responsive per l’invio finale sulla rete. Tuttavia, per prima cosa, faremo un giro nell’anatomia del processo di caricamento e di miglioramento per vedere come il codice client-side viene richiesto, caricato e reso a video e dove tendono a capitare i colli di bottiglia della performance e dell’usabilità.

Pronti? Facciamo un rapido giro del processo del caricamento di una pagina (page load).

Una passeggiata lungo il percorso critico#section3

Comprendere come i browser richiedano e carichino gli asset di una pagina ci aiuta molto nel prendere decisioni responsabili su come inviare il codice e accelera i tempi di caricamento per i nostri utenti. Se dovessimo registrare gli eventi che accadono dal momento in cui una pagina viene richiesta a quello in cui la pagina è utilizzabile, otterremmo quello che nella community della web performance è noto come critical path (o percorso critico). In qualità di web developers è compito nostro accorciare il più possibile questo percorso.

Anatomia semplificata di una richiesta#section4

Per dare il via al nostro “tour de HTTP”, cominciamo con le fondamenta di tutto quello che accade sul web: lo scambio di dati tra un browser e un web server. Tra il momento in cui il nostro utente preme “go” e quello in cui il sito comincia a caricare, una “initial request” comincia a fare ping avanti e indietro tra il browser e un Domain Name Server locale (che traduce l’URL in un indirizzo IP utilizzato per trovare un host), o DNS, verso l’host server (fig. 3.1).

Fig. 3.1: Le fondamenta di una connessione web.

In breve, questa praticamente è la base per i device che accedono al web su Wi-Fi (o mediante un vecchio cavo Ethernet). Un device connesso a una rete mobile fa uno step ulteriore: per prima cosa, il browser invia la richiesta a una cella telefonica locale, che inoltra la richiesta al DNS per dare il via a un loop browser-server. Anche su una velocità di connessione popolare come il 3G, quella connessione impiega secoli in termini di computer. Come risultato, stabilire una connessione mobile verso un server remoto può rimanere indietro rispetto al Wi-Fi di due secondi o più (fig. 3.2).

Fig. 3.2: Mobile? Prima alla cella! …che impiega in media due secondi su 3G.

Due secondi possono sembrare pochi, ma considerate che gli utenti possono individuare, e sono annoiati da, ritardi nella performance di 300 millisecondi. Quel ritardo cruciale di due secondi implica che il mobile web è intrinsecamente più lento della sua controparte Wi-Fi.

Fortunatamente, le moderne connessioni LTE e 4G alleviano sensibilmente questa pena e stanno lentamente guadagnando popolarità nel mondo. Non potendo però fare affidamento sulla velocità della rete, è meglio assumere che non sarà veloce. In entrambe i casi, una volta che la connessione al server è stabilita, le richieste per i file possono fluire senza ritardi nella connessione alla cella.

Richieste, richieste, richieste!#section5

Supponiamo che il nostro browser richieda un file HTML. Man mano che il browser riceve pezzi di testo di quel file HTML dal server, ne fa un parsing procedurale, cercando riferimenti ad asset esterni che devono essere richiesti e converte l’HTML in una struttura ad albero di elementi HTML nota come Document Object Model, o DOM. Una volta che è stata creata la struttura DOM, i metodi JavaScript possono attraversarla e manipolare programmaticamente gli elementi nel documento e il CSS può dare uno stile visuale agli elementi nel modo in cui vogliamo.

Le complessità del parsing HTML (e le sue variazioni tra i browser) potrebbero riempire un libro. Per timore che questo mio libro si trasformi in quello, sarò breve: la cosa importante è comprendere l’ordine fondamentale delle operazioni quando un browser fa il parsing e rende l’HTML.

• Per esempio, CSS funziona meglio quando tutti gli stili rilevanti al layout iniziale della pagina vengono caricati e analizzati prima che un documento HTML venga reso visivamente su uno schermo.
• Di contro, il comportamento di JavaScript è spesso in grado di essere applicato agli elementi della pagina dopo che questi sono stati caricati e resi a video.

Tuttavia, sia JavaScript sia CSS presentano degli ostacoli sul percorso critico, impedendo alla nostra pagina di apparire mentre essi vengono caricati ed eseguiti. Approfondiamo un pochino l’ordine di queste operazioni.

Rendering e blocking#section6

Il documento HTML con il caricamento più rapido è quello che non ha files esterni, ma è anche quello che non troverete di solito. Un documento HTML tipico fa riferimento ad un sacco di asset esterni come CSS, JavaScript, font e immagini.

Spesso, si trovano i CSS e JavaScript nella head del documento HTML rispettivamente come elementi link e script. Di default, i browser aspettano a rendere il contenuto di una pagina fino a che questi asset non hanno finito il caricamento e il parsing, comportamento noto come blocking (fig. 3.3). Di contro, le immagini sono asset non-blocking, dal momento che i browser non aspettano che una immagini si carichi prima di essere visualizzata nella pagina.

Fig. 3.3: Richieste CSS e JavaScript bloccanti durante il page load.

Nonostante il suo nome, il blocking rendering per CSS in effetti contribuisce al caricamento consistente dell’interfaccia. Se caricate una pagina prima che sia disponibile il suo CSS, vedrete una pagina di default senza stili; quando il CSS finisce il caricamento e viene applicato dal browser, il contenuto della pagina si risistema nel nuovo layout con gli stili. Questo processo in due fasi è chiamato flash of unstyled content, o FOUC, e può essere estremamente irritante per gli utenti. Quindi, bloccare il rendering di una pagina fino a che il CSS non è pronto è sicuramente auspicabile purché il CSS si carichi in un breve lasso di tempo, obiettivo che non sempre si raggiunge facilmente.

Il valore del blocking per quel che riguarda JavaScript mina quasi sempre la user experience ed è più una risposta a un metodo JavaScript persistente chiamato document.write, utilizzato per fare inject di HTML direttamente nella pagina in qualunque posizione stia facendo il parsing il browser. Solitamente è considerata una “bad practice” usare document.write ora che ci sono a disposizione metodi più disgiunti in JS, ma document.write è ancora utilizzato, particolarmente dagli script che includo le pubblicità. Il problema maggiore con document.write è che se gira dopo che una pagina ha finito il caricamento, sovrascrive l’intero documento con il contenuto che dà in output. È più un document.wrong, giusto? (Scusatemi). Sfortunatamente, un browser non ha modo di sapere se uno script che sta richiedendo contenga una chiamata a document.write, quindi il browser tende ad andare sul sicuro ed assumere che la contenga. Mentre il blocking previene una potenziale cancellazione dello schermo, forza anche gli utenti ad attendere gli script prima di poter accedere alla pagina, anche se gli script non avrebbero causato problemi. Evitare l’uso di document.write è un passo importante che possiamo fare per gestire questa problematica in JavaScript.

Nel prossimo capitolo, vedremo dei modi per caricare gli script che evitano questo comportamento bloccante di default e che come risultato hanno il miglioramento della performance percepita.