La scorsa settimana ho pubblicato la prima parte di questa mini serie in due puntate, in cui riassumo alcuni accorgimenti per migliorare le prestazioni legate al caricamento delle risorse esterne che compongono una pagina web, nello specifico i fogli di stile ed il codice Javascript. Usando alcuni attributi, è possibile far sapere al browser quali risorse sia opportuno caricare prima, e quali dopo. Che riassume, di fatto, il senso della sfida che ci troviamo di fronte: non potendo aumentare la velocità di scaricamento, dobbiamo concentrarci sul mettere i vagoncini di questo treno immaginario nel giusto ordine, usando la tecnologia a nostra disposizione, come ad esempio gli attributi defer o async.
Per tutte le altre risorse che non ci servono subito, possiamo usare l’attributo preload. Sfortunatamente, si tratta di un attributo non ancora supportato al 100% da tutti i browser, specialmente quelli per i dispositivi mobili. Per ovviare a questo problema, usiamo il trucco del foglio di stile “per la stampa” evidenziato di seguito, per fare in modo che il browser scarichi questi file esterni mettendoli in una coda ben precisa:
<link rel="stylesheet"
href="styles.css" media="print" type="text/css"
onload="this.media='screen';this.onload=null;" />Il che spesso significa che vengono scaricati per ultimi nell’ordine delle risorse e dopo che il DOM è già stato renderizzato. Questo trucco del tipo di supporto è molto diffuso e funziona su un’ampia gamma di browser, dato che lo fanno con i fogli di stile media=print da oltre 20 anni in maniera naturale, quindi questo è solo un trucchetto per forzare i fogli normali a utilizzare quel modello. Dopo averli scaricati, tutte le altre pagine li utilizzeranno, inclusa la tua home page e i suoi script.
Assicurati che il tuo server utilizzi HTTP/2, che implementa il multiplexing, un termine tecnico secondo cui i file scaricati dai browser possono essere ricevuti su più di una connessione. Questo non serve se hai poche risorse, ma fa una grande differenza se la tua pagina usa qualche decina di fogli diversi, ed altrettanti file Javascript ed immagini. Se l’enorme quantità di file è il tuo problema, ti suggerirei di porre la tua attenzione altrove, non sull’ottimizzazione che stiamo discutendo in questa serie.
Volendo strizzare fino all’ultima goccia di banda, puoi usare gli attributi di pre-caricamento, pre-visualizzazione e pre-connesione, anche se nella maggior parte dei casi non ti daranno enormi guadagni di velocità, visto che molti server e browser negoziano tutte queste connessioni abbastanza velocemente, o sono già memorizzate nella cache dai provider. Ma se il tuo sito si rivolge a mercati in cui la connessione non è veloce (vecchie reti cellulari, mancanza di rete in fibra ottica), allora vale la pena provare ad usare questi accorgimenti:
<link rel="dns-prefetch" href="//iltuosito.it" />
<link rel="preconnect" href="//iltuosito.it" />
<link rel="prefetch" href="una-foto.jpg" />Aggiungi la chiamata di prerendering delle risorse a cui speri che gli utenti possano accedere dopo aver visualizzato la pagina corrente. Tieni in mente che se da un lato questi file verranno memorizzati nella cache, dall’altro l’implementazione della chiamata è a discrezione del browser. Inoltre, il prerendering non solo scarica le pagine e le risorse, ma crea il DOM, esegue Javascript e prepara tutto l’occorrente per mostrare il risultato finale quando l’utente clicca sul collegamento. Ciò significa usare risorse di calcolo per una pagina che l’utente potrebbe non visitare mai:
<link rel="prerender" href="somewebpage.html" />Assegna a tutte le tue immagini, iframe, video e altri elementi multimediali un attributo di larghezza e altezza in modo che il browser possa riservare lo spazio nella pagina mentre scarica quegli elementi. Ciò impedisce principalmente uno spostamento nel layout, su cui Google PageSpeed Insights e soci sono molto critici, quando ti viene dato un voto sulla tua pagina. Aggiungi a tutte le immagini un attributo loading="lazy", il che significa che non vengono caricate finché l’utente non scorre la pagina web verso il basso.
Concludo osservando che la maggior parte di questi trucchi raramente mostra guadagni strabilianti nella performance di siti inerentemente lenti. Da alcuni anni, i fogli di stille hanno cominciato ad avere quest’accezione negativa quando si tratta di velocità di rendering del browser, e sono visti come il vero nemico da combattere, specialmente se si sta a sentire quello che, appunto, PageSpeed Insights ed altri ci continuano a ripetere. Il vero problema, lo ripeto, sono le librerie Javascript piene di ciarpame che modificano il DOM pesantemente, fanno tonnellate di richiesta al server per prelevare una manciata di dati, e tante altre diavolerie inutili. Concentrati sull’ottimizzare la tua applicazione da quel punto di vista, sono certo che alla fine ne raccoglierai i frutti migliori.