Nelle prime due parti di questo articolo abbiamo esaminato le varie problematiche legate alla velocità dei siti web, l’importanza che questo parametro riveste e come migliorarlo agendo sulle immagini ed il codice del sito e sfruttando alcuni tool di terze parti. Oggi, nell’ultima puntata, vedremo come è possibile migliorare ulteriormente le performance sfruttando il caching delle pagine del sito e daremo uno sguardo ad HTTP/2, la nuova versione del protocollo di comunicazione su cui si basa il Web.
Se vi siete persi le prime puntate trovate qui la prima parte e qui la seconda.
Font personalizzati: gli ultimi saranno i primi
Il piccolo trucco visto nella scorsa puntata per ritardare l’inclusione di fogli di stile si rivela utilissimo se il nostro sito utilizza dei font particolari le cui risorse vengono lette direttamente dal server. In questo caso infatti avremo all’inizio del nostro file CSS del codice simile al seguente:
@font-face { font-family: 'NomeDelFont'; src: url('../fonts/miofont.eot'); src: url('../fonts/miofont.eot?#iefix') format('embedded-opentype'), url('../fonts/miofont.woff2') format('woff2'), url('../fonts/miofont.woff') format('woff'), url('../fonts/miofont.ttf') format('truetype'); font-weight: normal; font-style: normal; }Nell’esempio abbiamo un font denominato “NomeDelFont” di cui mettiamo a disposizione del browser svariati formati, tutti elencati nella regola. Il browser esaminerà la lista dei formati disponibili, sceglierà quello più opportuno tra quelli che supporta e ne richiederà l’invio al server. Poiché questa regola sarà posizionata all’inizio del foglio di stile principale del sito ed i file dei font possono essere anche molto pesanti, certamente incontreremo un blocco non trascurabile nel rendering della pagina.
Un’ottima soluzione potrebbe essere spostare le regole di inclusione dei font dal foglio di stile principale ad uno dedicato, contenente solo queste regole ed incluso con l’hack visto precedentemente:
<link rel='stylesheet' href='fonts.css' type='text/css' media="none" onload="if(media!='all')media='all'" />Accertiamoci poi che in tutti i fogli di stile le regole che utilizzano il font personalizzato abbiano come “salvagente” un font standard, ad esempio:
font-family: 'NomeDelFont', sans-serif;In questo modo il caricamento dei file dei font sarà eseguito solamente come ultima cosa, dopo tutti gli altri download più importanti con la certezza che il contenuto della pagina, seppur con un font standard, sarà comunque visibile sin dal primo momento.
Sfruttiamo le cache
Tanto tempo fa tutte le pagine web erano costituite da semplici file HTML ed i compiti eseguiti dal server a seguito della richiesta di una pagina erano limitati all’invio al browser del relativo file HTML senza alcuna elaborazione, analogamente alle altre risorse come immagini e fogli di stile.
Oggi le cose sono cambiate, tutte le pagine che costituiscono i nostri siti web sono dinamiche e scritte con linguaggi di programmazione che richiedono un’elaborazione lato server al momento della richiesta. Questo significa che il contenuto delle pagine non è più scritto staticamente nel loro codice sorgente ma ogni volta che il browser richiede una pagina il server ne esamina ed esegue il codice, costruendo “al volo” una visualizzazione del contenuto da inviare all’utente. In questo modo le pagine dei nostri siti possono essere totalmente dinamiche, mostrando ad esempio delle offerte speciali diverse in base al periodo dell’anno o dei contenuti differenziati in base al nome con cui abbiamo eseguito il login nel sito ma il server si trova costretto ad eseguire una elaborazione ad ogni richiesta di pagina.
Per velocizzare questa operazione è possibile ricorrere a delle cache software delle pagine, cioè alla creazione sul server di copie statiche delle pagine da inviare al browser al posto delle pagine originali ed aggiornate rielaborando il codice originale non ad ogni richiesta ma ad una scadenza prefissata, ad esempio 12 ore. Allo stesso modo è possibile creare delle copie compresse ed ottimizzate anche dei file JavaScript e dei fogli di stile CSS, riducendo il peso dei file e di conseguenza i tempi di download.
Se il nostro sito web è basato sul motore WordPress una soluzione estremamente semplice per implementare una cache di questo tipo è costituita da WPRocket. Si tratta di un plugin per WordPress che già fin dalla prima attivazione e senza eseguire configurazioni particolari abilita il caching delle pagine e la compressione con GZIP di tutte le risorse inviate al browser; dalla schermata di configurazione è poi possibile abilitare anche la minificazione e compressione di JavaScript e CSS ed il caricamento “LazyLoad” delle immagini e dei video. Quest’ultima funzionalità consiste nell’evitare di caricare fin da subito tutte le immagini presenti nella pagina ma ritardarne il caricamento sino a quando una particolare immagine deve essere veramente mostrata a video, solitamente perché l’utente sta scorrendo la pagina; con questa tecnica si diminuisce il tempo di prima visualizzazione della pagina, soprattutto su connessioni lente. Il plugin gestisce inoltre la connessione con alcuni dei CDN più famosi e la loro configurazione. Si tratta di un plugin a pagamento ma il basso costo annuale (39$ al momento della stesura di questo articolo) credo venga ampiamente ripagato dalle funzionalità offerte!
Un diretto concorrente di WPRocket è W3 Total Cache, un plugin per WordPress estremamente avanzato e diffuso, con oltre 1 milione di installazioni attive nel mondo. Si tratta di un plugin molto potente e ricco di opzioni e dunque inevitabilmente complesso da configurare in maniera ottimale ma prendendosi un po’ di tempo per leggere le numerose guide alla configurazione reperibili su web è possibile raggiungere risultati molto interessanti! Rispetto ad altri plugin dedicati al caching offre due servizi esclusivi:
– Integrazione con tutti i principali CDN con gestione completa delle risorse presenti sia nella galleria dei media che direttamente nel template in maniera assolutamente all’utente.
– Gestione delle cache lato server. Se avete la possibilità di gestire la configurazione del vostro server, direttamente o chiedendo al vostro sistemista, potreste infatti valutare di attivare delle cache server side; le possibilità sono tante, si va dalla generazione di copie statiche delle pagine sino al salvataggio in cache dei risultati delle query effettuate più spesso sul database e normalmente permettono di raggiungere performance superiori rispetto alle semplici cache software. Una volta attivate le cache server side, W3 Total Cache mette a disposizione un pannello di controllo per la loro gestione direttamente dall’interno del nostro sito.
Infine ma non per importanza, il plugin è scaricabile ed utilizzabile gratuitamente.Se non si vogliono installare plugin dedicati al caching oppure stiamo lavorando su un sito costruito ad hoc possiamo comunque eseguire un paio di piccole ottimizzazioni.
La prima riguarda la cache lato browser: di base infatti, ogni volta che deve visualizzare una pagina, il browser riscarica tutti gli elementi che la compongono, non potendo sapere se queste risorse sono ripetute in più pagine del sito o se rimangono invariate nel tempo; i browser più moderni integrano nativamente dei sistemi di caching che vanno però istruiti da parte nostra in modo che il browser sappia per quanto tempo può ad esempio conservare in memoria le immagini o i file JavaScript prima di richiederli nuovamente al server, senza paura di visualizzare contenuti obsoleti. Se il nostro sito è gestito da un server Apache possiamo inserire queste regole nel file di configurazione .htaccess:
<IfModule mod_expires.c> ExpiresActive On ExpiresDefault "access plus 15 minutes" ExpiresByType text/html "access plus 15 minutes" ExpiresByType text/css "access plus 1 month" ExpiresByType text/javascript "access plus 1 month" ExpiresByType image/gif "access plus 1 month" ExpiresByType image/jpg "access plus 1 month" ExpiresByType image/jpeg "access plus 1 month" ExpiresByType image/png "access plus 1 month" ExpiresByType image/x-icon "access plus 1 month" ExpiresByType application/x-shockwave-flash "access plus 1 month" </IfModule>Le prime due regole indicano di attivare il caching ed impostano la scadenza delle risorse per cui non verrà indicato un valore specifico a 15 minuti; tutte le regole successive impostano invece delle scadenze dedicate a varie tipologie di risorse, come file CSS, Javascript e immagini.
Sarebbe inoltre buona norma abilitare sempre nel file di configurazione .htaccess la compressione dei file inviati dal server al browser per ridurne il peso e quindi il tempo di download:
<IfModule mod_filter.c> AddOutputFilterByType DEFLATE application/atom+xml AddOutputFilterByType DEFLATE application/javascript AddOutputFilterByType DEFLATE application/json AddOutputFilterByType DEFLATE application/rss+xml AddOutputFilterByType DEFLATE application/vnd.ms-fontobject AddOutputFilterByType DEFLATE application/x-font-ttf AddOutputFilterByType DEFLATE application/xhtml+xml AddOutputFilterByType DEFLATE application/xml AddOutputFilterByType DEFLATE font/opentype AddOutputFilterByType DEFLATE image/svg+xml AddOutputFilterByType DEFLATE image/x-icon AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE text/html AddOutputFilterByType DEFLATE text/plain AddOutputFilterByType DEFLATE text/x-component AddOutputFilterByType DEFLATE text/xml </IfModule>Uno sguardo al futuro: HTTP/2
HTTP, acronimo di Hypertext Transfer Protocol, è il protocollo di rete attualmente utilizzato sul web per lo scambio di dati tra il browser ed il server. La prima versione del protocollo risale alla fine degli anni ’80 e costituiva, assieme al linguaggio HTML e le regole per la risoluzione degli URL delle pagine, il primo nucleo del World Wide Web (WWW) sviluppato da Tim Berners-Lee al CERN di Ginevra. Nel 1991 il protocollo viene rilasciato nella sua prima versione pubblica, la 1.0 che diviene standard ufficiale nel 1999 con denominazione RFC2616. Da quel momento questo protocollo, utilizzato da tutti i web server del mondo, non ha subito alcuna modifica sostanziale sino ad oggi con la nascita di HTTP/2, fondamentalmente una rielaborazione con alcune modifiche del protocollo proprietario SPDY sviluppato da Google.
Perché dopo tanti anni si è voluto sviluppare un nuovo protocollo? Perché HTTP/1 è abbastanza lento e non è in grado di gestire efficacemente le tantissime risorse che costituiscono le moderne pagine web. Sicuramente 16 anni fa nessuno poteva immaginare che dalle prime pagine web di solo testo si sarebbe arrivati a pagine così ricche di immagini, video e contenuti dinamici ed interattivi.
Per questo HTTP/2, pur mantenendo la piena compatibilità lato client con la versione precedente del protocollo e non richiedendo dunque alcuna modifica al modo di lavorare delle applicazioni web esistenti, introduce delle novità che porteranno ad un notevole aumento di velocità dei siti web:
- Compressione di tutti i dati inviati dal server al client, comprese le intestazioni dei pacchetti dati;
- Possibilità di richiedere e ricevere in parallelo più risorse sulla stessa connessione al server e non solamente una risorsa alla volta come avviene attualmente;
- Introduzione di una nuova tecnologia push che permette al server di inviare al client più dati di quelli che sta richiedendo, ad esempio delle risorse che il server sa essere necessarie per la visualizzazione del sito ma che il client non ha ancora richiesto;
- Gestione delle richieste da parte del server non solamente in base al classico ordine di richiesta ma attraverso una lista di priorità.
Le stime parlano di incrementi nella velocità di caricamento delle pagine variabili dal 10% al 50% rispetto ad HTTP/1, direi un ottimo risultato! A questo indirizzo: https://http2.akamai.com/demo si trova un’interessante demo in cui vengono confrontati i tempi di download di una serie di immagini sui due protocolli.
HTTP/2 è uno standard approvato dal maggio 2015 ed è già supportato da tutti i principali browser presenti sui nostri PC e smartphone, mentre attualmente sono pochi i siti web che sfruttano il nuovo protocollo a causa del supporto non ancora maturo da parte dei server web… uno su tutti, il modulo HTTP/2 (mod_http2) per Apache, probabilmente il server web più utilizzato al mondo, è ancora in versione sperimentale. Una seconda causa della lenta diffusione è dovuta al fatto che il protocollo richiede nativamente una connessione sicura HTTPS, quindi la necessità di abilitarla per il nostro sito ed installare un certificato di sicurezza. Credo comunque sia importante seguire gli sviluppi di questo protocollo ed iniziare a parlarne con il nostro sistemista… si tratta del prossimo futuro del web e magari potreste migrare il vostro sito già tra breve tempo!
Questo articolo è diviso in tre parti:
