Lotrèk
27 Giugno 2019

#lovogliopiùveloce - Addio JQuery


Giulio  profile image
Human:
Giulio 
Tempo
di lettura
6'

Abbiamo impiegato svariati mesi per rendere il più veloce possibile BarcoReale, vi sveliamo tutti i trucchi che abbiamo usato

Iniziamo il nostro viaggio nello sviluppo di Barcoreale. Sarà suddiviso in più articoli e in ognuno di essi andremo a esaminare il modo in cui il team di sviluppo ha affrontato e risolto alcune problematiche.

Fin dall’inizio dello sviluppo del nuovo sito di BarcoReale, nel team di sviluppo avevamo ben chiari gli obiettivi generali del progetto, soprattutto quello che ci eravamo prefissati.

Il sito doveva essere veloce.

Siamo convinti che un sito che ha lo scopo di vendere un prodotto ci riesca meglio se è veloce.

Questo era stato il nostro obiettivo e, con i risultati alla mano, possiamo dire di esserci riusciti.

Prima Tappa: Goodbye JQuery!

Nei primi giorni di sviluppo abbiamo configurato tutto quello di cui avevamo bisogno, comprese le varie tecnologie che saremo andati a utilizzare.

Internamente, abbiamo scelto Bootstrap come framework css di riferimento, questa scelta però porta con se l’adozione di JQuery.

Non c’è nulla di male a usare JQuery, con Bootstrap è un ottima accoppiata, ma non vale per ogni progetto.

Nel nostro caso questa accoppiata non poteva e soprattutto non doveva essere usata.

Perché abbiamo scelto di rimuovere JQuery

Troppo pesante:

Pesa veramente tanto nel bundle finale del Javascript e noi dovevamo rendere questi file il più piccoli possibili: il peso dei file che il browser deve scaricare è proprio uno dei fattori più importanti per la velocità del caricamento del sito. 

Un utile strumento per verificare quanto una dipendenza incida sulla grandezza del file Javascript finale è Bundlephobia. 

JQuery pesa ben 30kB (Gzippato e Minificato).

Quindi, utilizzandolo, saremmo partiti già da 30kB senza aver scritto neanche una riga del nostro codice: non è accettabile.

Il nostro file javascript (in quel momento l’unico file Javascript) pesava 438 KiB (Minificato) e 143 KiB (Minificato + Gzippato)

Il sito però era solo al 5%.

Inutilizzato:

Parliamoci chiaro: molte volte usiamo le stesse 4 funzioni di JQuery per la manipolazione del Dom, però per usarle dobbiamo importare tutto JQuery.

Potremmo scrivere personalmente quelle poche funzioni che andiamo a utilizzare, come nel nostro caso vedi codice, che pesa solamente 1.3 KB (non minificato).

Non abbastanza scalabile:

Nel nostro caso il sito avrebbe dovuto implementare svariate funzioni, di diversa complessità.

Era fondamentale, quini, che il nostro codice fosse scalabile e sopratutto mantenibile.

Avevamo bisogno di creare componenti che avessero una loro logica e fossero riutilizzabili in più parti del sito.

JQuery permette di fare modifiche al DOM, gestire lo stile degli elementi e molto altro, ma con il crescere della complessità dell’applicazione rischia di diventare una spada di Damocle.

JQuery, quindi, non poteva essere la soluzione giusta per noi.

Bootstrap Native >> Bootstrap

JQuery e Bootstrap, si vogliono bene, forse troppo.

Boostrap nella sua versione classica ha bisogno di JQuery ( e altre dipendenze ) per far funzionare tutti quei componenti interattivi, un esempio di essi sono: Modali e la navbar per la versione mobile.

Senza JQuery questi componenti non funzionano minimanente e quindi avremmo avuto dei sicuri problemi nei mesi successivi.

Per fortuna esiste Bootstrap Native, una libreria scritta totalmente in javascript vanilla

che implementa tutti i plugin JQuery di cui Bootstrap ha bisogno.

Questo permette maggiori performance e di risparmiare ancora qualcosa sulla grandezza del file javascript finale.

Utilizziamo solo quello di cui abbiamo bisogno

Bootstrap native è la libreria di cui avevamo bisogno, ma anche in questo caso ci offre più di quello di cui abbiamo realmente bisogno.

Ci siamo chiesti quindi ,quali sarebbero stati i componenti che avremmo utilizzato sicuramente di Boostrap.

Solamente 1, la navbar per il menù mobile. Questo componente ha bisogno solo del plugin Collapse per poter funzionare, quindi dovevamo trovare il modo di importare solo il codice relativo a questo plugin.

Per fare ciò abbiamo usato un loader webpack per Bootstrap native, lo trovate qua bootstrap.native-loader.

Ecco un esempio di configurazione

module.exports = {
 module: {
    rules: [
      {
        test: /bootstrap\.native/,
        use: {
          loader: "bootstrap.native-loader",
          options: {
            only: ["Collapse"]
          }
        }
      },
    ]
  }
}

Perchè abbiamo scelto vuejs 

Scartato JQuery, ci serviva un framework che ci potesse aiutare a scrivere in maniera semplice e veloce gran parte dei componenti di cui avevamo bisogno.

La scelta è caduta subito su Vue.

Per chi non lo conoscesse, Vue è un framework per creare interfacce utente.

Potete leggerne di più sul loro sito ufficiale, uno dei migliori per documentazione vuejs.

Vue ci ha permesso di separare la struttura dell’elemento (struttura HTML) dalla logica che lo gestisce, rendendo il tutto più scalabile e mantenibile.

In aggiunta Vuejs è molto più leggero di JQuery, pesa 20.9K, e già solo con questo abbiamo guadagnato qualcosa.

Oggi siamo arrivati a 15 componenti custom, e, piccolo spoiler, il file javascript relativo all’homepage pesa 102KB, completo di tutta la logica necessaria.

module.exports = {
 module: {
    rules: [
      {
        test: /bootstrap\.native/,
        use: {
          loader: "bootstrap.native-loader",
          options: {
            only: ["Collapse"]
          }
        }
      },
    ]
  }
}

Organizzazione del codice Js

Abbiamo quindi pensato a come organizzare il codice per ottenere questo obiettivo: ogni pagina doveva scaricare solo il codice relativo ad essa.

Vediamo un piccolo esempio.

L’homepage condivide alcuni componenti con la pagina Checkout, che è la più pesante del sito, ma non condivide neanche una riga di codice riguardante la prenotazione di un alloggio o il calcolo di un prezzo.

Per avere un file relativo a ogni pagina, ci siamo serviti di webpack e degli entry point: inizialmente, avevamo sfruttato i chunks di webpack, ma avevamo riscontrato diversi problemi con le librerie utilizzate in più parti del sito.

Veniva infatti generato un file per ogni pezzo di codice condiviso da più pagine, quindi per n pagine avremmo avuto n script relativi alla pagina e molti altri in base alla condivisione del codice.

Questo poteva portare all’inclusione inconsapevole di codice già presente in un chunk incluso precedentemente, ed era proprio una delle cose che volevamo evitare.

Ecco un esempio della configurazione webpack:

module.exports = {
  mode: "development",
  devtool: "source-map",
  output: {
    filename: "[name].bundle.js",
    path: path.resolve("./build", "js")
  },
  entry: {
    home: path.resolve("./public/bootstrap/js/src/pages/home/index.js"),
    generic: path.resolve("./public/bootstrap/js/src/pages/generic/index.js"),
    sistemations: path.resolve(
      "./public/bootstrap/js/src/pages/sistemations/index.js"
    ),
    checkout: path.resolve("./public/bootstrap/js/src/pages/checkout/index.js"),
    thankyou: path.resolve("./public/bootstrap/js/src/pages/thankyou/index.js"),
    blog: path.resolve("./public/bootstrap/js/src/pages/blog/index.js")
  },
  resolve: {
    alias: {
      vue: "vue/dist/vue.min",
      components: path.resolve("./public/bootstrap/js/src/components/")
    }
  },
  module: {…},
}

Organizzazione del codice Css

L’ultimo punto da affrontare in questa tappa è stato l’organizzazione del codice css.

Noi utilizziamo un estensione del linguaggio Css, chiamata Sass.

Anche Bootstrap lo utilizza, rendendo quindi tutta la nostra codebase coerente.

Per processare i nostri file Sass, abbiamo utilizzato anche in questo caso Webpack, ma in un file diverso da quello relativo al javascript.

Webpack però nasce con l’’idea di creare un bundle javascript unico comprendente sia il Js che il Css.

Per risolvere questo problema abbiamo utilizzato il plugin MiniCssExtractPlugin: con esso si può estrarre il css dal bundle e scriverlo su un file css nativo.

Per la prima tappa è tutto, ce ne saranno altre molto più tecniche e corpose a seguire.

Stay tuned, Stay BarcoReale!

Vorrei ringraziare già alla prima tappa chi mi ha accompagnato in questo viaggio:

Ringrazio Salvatore e Gabriele che ci hanno dato una grandissima mano in una delle tappe più importanti del viaggio, nella quale abbiamo implementato il supporto al formato WEBP.

Ringrazio Marco, a cui abbiamo chiesto mille deploy, ma sopratutto ringrazio Mirko, che ho stressato ogni giorno e che ha davvero fatto la differenza.



Condividi

Mi sono avvicinato al mondo dell'informatica da piccolo, complice la mia timidezza e i pochi amici, mi son trovato talmente bene che ho deciso di continuare, quello doveva essere il mio futuro e ho cercato di migliorare dando sempre il 100%.

Articoli Correlati

 Invio email in corso, yeah!
Richiesta inviata
C'è stato un problema riprova più tardi