La minificazione del codice

Abbiamo già parlato di come ci siamo impegnati a rendere veloce e performante il sito di Barco Reale liberandoci dalle JQuery e controllando la pesantezza del javascript. Ora aggiungiamo un altro importante tassello per il raggiungimento di questo obiettivo: la minificazione.
Per minificazione del codice si intende un processo di rimozione di dati non necessari o più volte ripetuti che non ne inficia il corretto funzionamento.

Esempi di dati rimossi durante questo processo sono gli spazi, i punti e virgola, le tabulazioni fino ad arrivare a cambiare il nome di funzioni e variabili per renderli più concisi.

Il risultato di questa operazione è un file dalle dimensioni più piccole e un file dalle dimensioni più piccole è un file che permette al nostro sito web di caricare in minor tempo.

La compressione del codice

Per compressione, in questo caso, si intende un processo che effettua l'identificazione di stringhe ripetitive e le sostituisce con un puntatore alla loro prima occorrenza. Questa operazione può ridurre drasticamente il peso dei file che saranno inviati o ricevuti.

Minificazione e Compressione

Una tecnica non esclude l’altra, anzi!
Minificazione e compressione devono essere utilizzate congiuntamente per ottenere il miglior risultato, ovvero poter fornire il codice di cui il nostro sito necessita per funzionare correttamente impiegando meno risorse possibili.

Queste operazioni, fortunatamente, non sono da effettuare manualmente: possono essere infatti automatizzate ed effettuate anche per singoli casi.

Nello sviluppo del progetto Barco Reale abbiamo cercato di utilizzare le ultime tecnologie disponibili per effettuare la minificazione del codice javascript, procediamo ora con una semplice spiegazione su come si può effettuare questo processo in un progetto che utilizza webpack.

Come si fa?

Il primo punto, quello più immediato, è impostare l’esecuzione di webpack in modalità ‘production’.
È possibile eseguire questa operazione in molteplici modi, il più comune è aggiungere la stringa ‘NODE_ENV=production’ nella sezione ‘script’ all’interno del file package.json, il risultato sarà simile al seguente:

 

 "scripts": {
      "js:prod": "NODE_ENV=production webpack --config webpack/webpack_js_bundle_new.js  -- display-error-details -p ",
      "css": "webpack --config webpack/webpack_css_bundle.js", 
},

 

Attraverso questa aggiunta viene assegnato un valore alla variabile NODE_ENV che sarà successivamente letta da webpack durante l’esecuzione del processo di build.

Il secondo punto riguarda l’utilizzo di Terser come plugin webpack per effettuare diverse ottimizzazioni sul nostro codice javascript, fra cui la minificazione.

Ecco un piccolo esempio di utilizzo:

esso viene importato all’inizio del file
const TerserPlugin = require('terser-webpack-plugin');

Successivamente deve essere incluso nella voce optimization:

 

module.exports = {  
   optimization: {
      minimize: true,
      minimizer: [new TerserPlugin()],
    },
   };

 

Per una maggiore configurazione del plugin la sua pagina dedicata è molto completa.

Quando lo script verrà eseguito, Terser effettuerà la minificazione e altre operazioni di ottimizzazione sul nostro codice.

Passando alla compressione, il sito web HTTPArchive ha rilasciato le consuete statistiche annuali: attraverso le loro ricerche viene evidenziato come l’85% dei file JavaScript richiesti siano stati compressi.
La compressione più comune è quella ottenuta attraverso GZIP, a seguire Brotli. È importante specificare che Brotli ha una compatibilità minore rispetto a GZIP, ma ogni anno la sua diffusione aumenta.

Nello specifico file JavaScript compressi utilizzando Brotli risultano fino al 14% più piccoli, per file CSS si arriva fino al 17% mentre per file HTML fino al 21% rispetto alla loro controparte compressa attraverso GZIP.

Durante lo sviluppo poter contare sulla compressione attraverso GZIP anche sui server di test ci ha permesso di eseguire controlli periodici per verificare il peso dei file JavaScript di cui avevamo bisogno. Quando superavano una certa soglia sono state effettuare operazioni mirate, anche puramente di riscrittura del codice o deprecazione di librerie terze.

Il risultato? il sito veloce che volevamo.