Nella prima parte di questo articolo abbiamo visto alcuni concetti introduttivi relativi alla velocità dei siti web e come migliorare questo aspetto intervenendo sulle immagini presenti nelle pagine.
Oggi faremo un passo ulteriore e parleremo di CDN e di come evitare i contenuti bloccanti durante il caricamento delle pagine.

Se vi siete persi la prima parte potete trovarla qui.

La potenza di un CDN per il tuo sito

Tutti i siti web sono costituiti da un elevato numero di file: oltre al file HTML con il codice ed i testi della pagina pensiamo a tutte le immagini, i file CSS e JavaScript, i font… tutti elementi che devono essere scaricati uno ad uno dal server per poter arrivare a mostrare a video la pagina completa. Poiché il server fornirà al browser uno o comunque pochi elementi contemporaneamente, in caso di pagine ricche di elementi i tempi di caricamento inevitabilmente si allungheranno semplicemente nell’attesa di riceverli tutti.

Proprio per ovviare a questo problema sono nati i Content Delivery Network cioè delle reti di server distribuiti nel mondo su cui ospitare le proprie risorse, scaricando il proprio server dal doverle fornire; poiché la risorsa verrà richiesta dal browser al CDN contemporaneamente ne potranno essere lette altre dal server principale, ottimizzando così i tempi di caricamento.

I vantaggi in realtà non si fermano qui:

  • I server che compongono la rete CDN sono normalmente molto potenti e veloci, sicuramente più del nostro spazio web che magari condivide il server con altri 1000 siti web;
  • L’URL che il CDN ci fornisce per accedere alla nostra risorsa è indipendente dal server della rete che fisicamente la ospita e spesso la risorsa sarà copiata su più server della rete; in questo modo il CDN potrà prelevare di volta in volta la risorsa dal server fisicamente più vicino a noi, sia che ci troviamo in Italia sia che siamo a New York… in questo modo verrà ridotto il tempo di attesa;
  • Per lo stesso motivo il CDN potrà fornirci anche più risorse in parallelo, sfruttando il fatto che ciascuna potrà essere letta da un diverso server.

Dal punto di vista dell’implementazione nel proprio sito web l’impatto è molto basso: è sufficiente modificare l’URL di tutte le risorse interessate, sostituendolo con quello fornito dal CDN, il cui formato varierà in base al servizio scelto.

Tutti i siti più importanti fanno oggi uso di CDN, alcuni hanno addirittura delle reti proprietarie, come ad esempio Facebook con la sua rete fbcdn.net. In questi ultimi anni sono inoltre nate numerose ditte, come ad esempio StackPath che forniscono il servizio di rete CDN a costi abbastanza contenuti (si parte da poche decine di dollari al mese), si tratta quindi ormai di un servizio alla portata di tutti!

CDN e ottimizzazione delle immagini: la combinazione perfetta

Cloudinary è un servizio davvero interessante che unisce una rete CDN espressamente dedicata alla fornitura di immagini a servizi di ridimensionamento automatizzato per l’utilizzo responsive, sino ad arrivare a servizi di manipolazione ed editing delle immagini. Come recita il claim nella homepage del servizio: “An end-to-end solution for all your image-related needs”.

Di base il sito web di Cloudinary fornisce un’area amministrativa da cui caricare le immagini nello storage basato su cloud offerto dal servizio. Una volta caricata un’immagine è possibile accedere alla sua pagina di editing, dove agendo su caselle di controllo e cursori si imposta come questa dovrà essere visualizzata nel proprio sito: formato, dimensione, proporzioni, ritaglio… sino a colori, trasparenza, opacità, face detection per la centratura dell’immagine, bordi, ombre, zoom e tanto altro. Il servizio genererà dinamicamente l’URL che dovremo utilizzare nel nostro sito per accedere alla risorsa modificata come desideriamo.

Si hai letto bene: tutte le modifiche da effettuare all’immagine vengono richieste al servizio come parti dell’URL della risorsa stessa e vengono applicate “on the fly”, in questo modo è possibile caricare su Cloudinary la nostra immagine a risoluzione piena e sfruttare poi il servizio per generare tutte le nostre immagini responsive da utilizzare negli esempi visti precedentemente agendo sia sulla dimensione che sulla proporzione.

Riprendendo l’esempio di una immagine da mostrare in formato orizzontale su tablet e verticale su smartphone, fornendo anche una versione ad alta risoluzione per display retina:

<picture>
   <source media="(min-width: 768px)"
           srcset="http://res.cloudinary.com/.../c_scale,w_1024/.../immagine.jpg 1x, 
                   http://res.cloudinary.com/.../c_scale,w_2048/.../immagine.jpg 2x">
   <img src="http://res.cloudinary.com/.../c_fill,h_576,w_512/.../immagine.jpg" 
        srcset="http://res.cloudinary.com/.../c_fill,h_576,w_512/.../immagine.jpg 1x, 
                http://res.cloudinary.com/.../c_fill,h_1152,w_1024/.../immagine.jpg 2x" 
        alt="descrizione immagine" />
</picture>

Il servizio offre vari piani di abbonamento con prezzi differenziati in base al numero di trasformazioni  effettuabili al mese ed al numero totale di immagini caricabili. Al momento della scrittura di questo articolo è disponibile anche un piano gratuito perfetto per piccoli siti, con possibilità di caricare fino a 75000 immagini ed effettuare 7500 trasformazioni al mese.

Evitiamo i contenuti bloccanti

Le regole di buona scrittura del codice HTML vogliono che tutte le risorse che non visualizzano direttamente contenuto a schermo, come ad esempio i fogli di stile ed i file JavaScript, siano incluse nella sezione <head> della pagina. In questo modo il nostro codice sarà sintatticamente corretto ma certamente non sarà ottimizzato dal punto di vista della velocità, perché tutte le risorse incluse nell’head verranno caricate prima di iniziare il render a video della pagina, bloccando di fatto la visualizzazione sino al completamento del loro caricamento.

Per quanto riguarda i file JavaScript è importante farsi una domanda: quali script sono realmente bloccanti per permettere la corretta visualizzazione della pagina e quali invece potrebbero essere eseguiti dopo che la pagina è stata mostrata a video?
Ad esempio, uno script che introduce un effetto di movimento quando si muove il cursore su di un banner può essere tranquillamente eseguito successivamente alla visualizzazione… al massimo per qualche istante questo effetto non sarà presente! Allo stesso modo, anche lo script che mostra nella pagina la nostra bellissima ma pesantissima Google Map potrà essere eseguito in un secondo momento, durante il caricamento della pagina vedremo semplicemente un riquadro colorato al posto della mappa.

Gli script davvero bloccanti andranno mantenuti all’interno dell’head mentre tutti gli altri potranno essere spostati in fondo alla pagina, immediatamente prima della chiusura del tag <body>.

Con i fogli di stile CSS il discorso è invece un po’ più complesso: anche in questo caso, infatti, dovremo suddividere i file tra quelli effettivamente necessari per avere una visualizzazione iniziale accettabile della pagina e quelli che potranno essere caricati in un secondo momento ma non potremo semplicemente spostare i file secondari in fondo alla sezione <body> in quanto sarebbe un errore caricare file CSS esternamente all’head.

Dovremo quindi ricorrere ad un piccolo hack basato su JavaScript per ritardare il caricamento di queste risorse pur mantenendole all’interno del tag <head>. Attualmente la nostra risorsa CSS sarà inclusa nella pagina in questo modo:

<link rel='stylesheet' href='style.css' type='text/css' media='all' />

Trasformiamo la riga in:

<link rel='stylesheet' href='style.css' type='text/css' media="none" onload="if(media!='all')media='all'" />

ed ecco compiuta la magia! Il browser vedrà l’inclusione del file style.css ma avendo indicato un media non esistente ignorerà il caricamento del file… una volta completato il caricamento dell’intera pagina JavaScript scatenerà l’evento onload sul tag, il quale trasformerà l’attributo media in ‘all’; il browser riconoscerà quindi il file CSS come necessario per l’attuale visualizzazione e provvederà a scaricarlo ed applicarlo.

 

Questo articolo è diviso in tre parti:

Clicca qui per leggere la prima parte

Clicca qui per leggere la terza parte