Personal tools
Sviluppo Front-End: ottimizzare le prestazioni

Migliorare l'esecuzione delle risorse di front-end

Feb 18, 2013

Sviluppo Front-End: ottimizzare le prestazioni

Alcuni trucchi e consigli per migliorare la velocità dei siti web

Per quanto riguarda lo sviluppo front-end, c'è sempre più attenzione alle performances, dato che favorendo la velocità dell'esperienza utente c'è un ritorno diretto in termini di soddisfazione da parte di chi fruisce il progetto web.

E' uscito da poco un articolo molto curato sull'argomento che ha attratto la mia attenzione:

Front-end performance for web designers and front-end developers di Harry Roberts.

Nell'articolo vengono illustrati e sintetizzati molti degli argomenti relativi all'ottimizzazione dello sviluppo front-end.

Si parte dalle regole basilari: gli stili css devono essere chiamati all'inizio della pagina mentre i file javascript in fondo ad essa. Questo è un punto essenziale, dato che i browser eseguono il render della pagina progressivamente e prima hanno a disposizione il css, prima ne possono iniziare il render sulla pagina, evitando di bloccarla graficamente.

Al contrario le chiamate javascript, bloccando i browser nel processo di download parallelo delle varie risorse, devono essere posizionate in fondo alla pagina. La loro natura bloccante deriva anche dal fatto che ogni singola risorsa js deve essere caricata nell'esatta sequenza.

In generale è bene fare il minor numero di chiamate possibili a risorse, cioè scaricare il minor numero di elementi effettuando così poche HTTP Request. Ogni chiamata tecnicamente può incorrere in un "DNS lookup", in un redirect o in un errore 404 di risorsa non trovata; per questo ridurle contribuisce sensibilmente ad ottimizzare l'esecuzione.

Idealmente si dovrebbe massimizzare il parallelismo nell'ottenere risorse da domini diversi. Dato che un browser può al massimo trattare due risorse alla volta da uno stesso dominio, possiamo moltiplicare questo numero per il numero di domini dal quale possiamo servire le risorse.

Molti siti conosciuti fanno uso di domini "statici" solo per questo motivo, ottenere le risorse da più domini. In abbinamento alla tecnologia CDN (Content Delivery Network), ciò consente di diminuire ulteriormente la latenza di tempo ottenendo così le risorse anche da più luoghi dislocati fisicamente nel mondo.

Le richieste HTTP e il tempo per la risoluzione dei nomi DNS possono quindi rappresentare uno dei principali colli di bottiglia nelle prestazioni di front-end dato il limite nello scaricamento di risorse in parallelo imposto dai browsers. D'altro canto, la tecnica dell'utilizzo di sottodomini per aumentare le possibilità parallele introduce ad ogni nuovo dominio il tempo di latenza della risoluzione del nuovo nome DNS, quindi va valutato accuratamente caso per caso se sia possibile farsi carico di questo ulteriore tempo nel progetto web di cui ci si sta occupando.

Nel caso in cui servano nuovi nomi di dominio, è utile utilizzare la tecnica del DNS prefetching attraverso la quale semplicemente si comunica in anticipo al browser il nuovo dns dal quale, poco dopo, sarà necessaria una risorsa; facendo così si riescono a evitare i tempi di attesa per la risoluzione del nuovo dominio.

<head>
<link rel="dns-prefetch" href="//widget.foo.com" />
</head>

In realtà questo introduce il concetto di prefetching generale delle risorse; oltre ai DNS, anche le altre risorse come i web fonts o le immagini chiamate dai fogli di stile possono essere chiamate in anticipo in modo da iniziarne il download leggermente prima del loro effettivo utilizzo.

Per fare questo esistono due vie: 
- una sporca e sicura, che prevede di celare in un <div> nascosto le immagini per averle a disposizione nell'html della pagina molto in anticipo
- una più pulita ai puristi del codice, che è sostanzialmente sempre il link prefetching già visto per i DNS.

<link rel="prefetch" href="sprite.png" />
<link rel="prefetch" href="webfont.woff" />

Invece, per quanto riguarda l'ottimizzazione delle chiamate css è fondamentale sapere che non devono mai essere fatte da un un altro dns, data la loro natura bloccante sulla resa grafica della pagina; così facendo infatti si incorrerebbe nel DNS lookup, ovvero nel tempo ulteriore necessario alla risoluzione del nuovo dominio.

Oltre a servire il css il prima possibile nella pagina, bisogna concatenarli, ridurli al minimo rimuovendo commenti e spazi e comprimerli per diminuire il lavoro da parte del browser e dei vari sistemi di caching. I software di editing css contemporanei hanno tutti funzioni per controllare anche questi aspetti; in aggiunta, se si usano linguaggi di preprocessing dei css come sass si hanno a disposizione potenti strumenti per curare nei dettagli tali operazioni.

Senza entrare troppo nel dettaglio della compressione possibile usando gzip su server attraverso Apache, passiamo all'ottimizzazione delle immagini.

Si parte dalla ben nota tecnica di spriting delle immagini, ovvero del raggruppare in un'unica immagine tutte quelle che possono servire nel file css, in modo da ridurre al minimo il numero di http Request a questo tipo di risorsa. Anche se non tutte le immagini possono essere messe in uno sprite - ad esempio quelle da usare come sfondo, che vanno ripetute e che spesso vengono messe negli sprite con molti pixel vuoti attorno in modo da poter ottenere la ripetizione necessaria. Ma i pixel vuoti, non necessari, sono un problema nella velocità di esecuzione. L'articolo suggerisce di usare il classico "elemento di spriting", solitamente <i>, che ha il solo scopo di rimanere vuoto e portare l'immagine di sprite come sfondo. Ecco l'esempio di utilizzo più comune:

<li>
<a href="/profile/">
<i class="icon icon--person"></i> Profile
</a>

</li>
 

L'articolo di Harry Roberts tocca anche il caso delle immagini Retina solitamente usate per i dispositivi mobile, in modo da garantire ad essi che hanno capacità di memoria inferiori, esperienze estetiche superiori, ma in generale l'autore ritiene che vadano scelte oculatamente. Tutto sommato esistono anche valide alternative alle immagini bitmap, come svg o font di icone.

Infine, l'ultimo argomento dell'articolo: le immagini JPG progressive.

Riguarda più che altro la velocità percepita nell'esecuzione, infatti a differenza dei JPG che si caricano per blocchi successivi, i jpg progressivi sono caricati interamente fin dall'inizio ma pixelati e solo progressivamente aumentano di dettaglio, un po' come accadeva per le vecchie gif. Ciò contribuisce molto alla percezione di rapidità visiva che avrà l'utente.

L'articolo portato alla vostra attenzione è ricco di approfondimenti come questo sui jpg progressivi: il mio invito è di tornare a ricercare ogni singolo approfondimento direttamente alla fonte.

Image by courtesy of: Silvia Cesari

Filed under: , , , , ,
comments powered by Disqus