Quando si parla di sviluppare siti turistici e e-commerce, la sfida per i programmatori si fa più dura.

Prima di tutto, ovviamente, perché non si tratta solo di riuscire a dare il giusto risalto ai plus di ciò che stai proponendo agli utenti, ma anche di riuscire a vendere e un sito, per portarti a concludere un acquisto di qualsiasi tipo, deve offrire ottime performance e risultare user friendly in ogni aspetto. 

Come se non bastasse, i siti legati al turismo e gli e-commerce devono confrontarsi con piattaforme molto conosciute che dominano il settore come colossi: per farsi notare online è quindi fondamentale che riescano a risultare accattivanti e a offrire una buona esperienza di navigazione.

Questo contesto ci è stato chiaro fin da subito quando ci siamo approcciati allo sviluppo del sito di Barco Reale, un camping a 4 stelle nel cuore della Toscana che voleva raccontare agli utenti la particolarità dei suoi servizi e permettere loro di prenotare online i soggiorni nella struttura.

Come abbiamo affrontato questa sfida? È stato un lungo percorso fino ad arrivare all'obiettivo prefissato: vogliamo raccontartelo per tappe!

Iniziamo quindi il nostro viaggio nello sviluppo di Barco Reale: 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, il team di sviluppo aveva 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 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 sé l’adozione di JQuery.

Non c’è nulla di male a usare JQuery, con Bootstrap formano 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 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 era 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 -, per ridurre il peso a soli 1.3 KB (non minificato).

 

Non abbastanza scalabile:

 

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

Era fondamentale, quindi, 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 (oltre ad altre dipendenze) per far funzionare tutti i componenti interattivi, come ad esempio i Modali e la navbar per la versione mobile.

Senza JQuery questi componenti non funzionano e quindi avremmo avuto sicuramente 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 migliori 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 offriva più di quello che realmente ci serviva.

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 farlo 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 aiutasse 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. Puoi 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. Già solo con questa scelta abbiamo guadagnato qualcosa in termini di velocità.

Oggi siamo arrivati a 15 componenti custom, e - piccolo spoiler sulle prossime tappe del nostro viaggio di sviluppo - 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 precedente, 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 Barco Reale!

 

 

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.
Sopratutto ringrazio Mirko, che ho stressato ogni giorno e che ha davvero fatto la differenza.