{"id":7001120,"date":"2019-06-24T09:58:00","date_gmt":"2019-06-24T09:58:00","guid":{"rendered":"https:\/\/alistapart.com\/it\/?post_type=article&p=7001120"},"modified":"2020-06-03T10:29:52","modified_gmt":"2020-06-03T10:29:52","slug":"javascript-responsabile-parte-ii","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/javascript-responsabile-parte-ii\/","title":{"rendered":"JavaScript Responsabile, Parte II"},"content":{"rendered":"\n

Supponiamo che insieme a tutto il dev team abbiate fatto pressione con entusiasmo per un remake totale dell’architettura del sito web aziendale, che comincia a mostrare i suoi anni. Le vostre preghiere sono state ascoltate dal management – su su fino alla C-suite – che ha dato il via libera. Tutti euforici, voi e il team avete cominciato subito a lavorare con i team di design, copy e IA e nel giro di poco tempo, avete sfornato il nuovo codice.<\/p>\n\n\n\n

\u00c8 cominciato tutto con un innocente npm install<\/code> qui e un npm install<\/code> l\u00e0. Prima che ve ne rendeste conto, per\u00f2, stavate installando delle dependencies in produzione come uno studente della triennale che fa keg stand<\/a> senza curarsi di cosa succeder\u00e0 il giorno dopo.<\/p>\n\n\n\n

Poi avete lanciato.<\/p>\n\n\n\n

In questo caso per\u00f2, a differenza delle conseguenze delle peggiori bevute, l’agonia non inizia la mattina dopo. Oh<\/em> no. Succede mesi dopo, sotto l’agghiacciante forma di debole nausea e mal di testa da parte dei product owner e del middle management che si chiedono come mai le conversion e le revenue si sono entrambe abbassate dal momento del lancio. Poi si tocca la frenesia quando il CTO di ritorno da un week-end nei boschi si chiede come mai il sito si caricasse cos\u00ec lentamente sul suo telefono – ammesso che si caricasse.<\/p>\n\n\n\n

Prima erano tutti contenti. Adesso nessuno<\/em> \u00e8 contento. Benvenuti al vostro primo hangover da JavaScript.<\/p>\n\n\n\n

Non \u00e8 colpa vostra<\/h2>\n\n\n\n

Quando vi ritrovate con un terribile hangover, vi meritereste un bel \u201cVe l’avevo detto\u201d, anche se potrebbe scaturirne una litigata\u2026 Ammesso che riusciate a litigare nel miserabile stato in cui vi trovate.<\/p>\n\n\n\n

Quando abbiamo a che fare con un hangover da JavaScript, c’\u00e8 un sacco di colpa da distribuire. Ma puntare il dito \u00e8 una perdita di tempo. Il panorama del web attuale richiede iterazioni pi\u00f9 rapide di quelle dei nostri competitor. Questo tipo di pressione significa che probabilmente dovremo trarre vantaggio da qualunque mezzo a nostra disposizione per essere il pi\u00f9 produttivi possibile. Ci\u00f2<\/em> significa che \u00e8 pi\u00f9 probabile creare app con pi\u00f9 overhead e magari usare pattern che possono ledere la performance e l’accessibilit\u00e0, ma che non sar\u00e0 necessariamente un insuccesso.<\/p>\n\n\n\n

Lo sviluppo web non \u00e8 facile. \u00c8 un lungo lavoro duro che raramente facciamo bene al primo tentativo. La parte migliore del lavorare sul web, per\u00f2, \u00e8 che non dobbiamo<\/em> essere perfetti fin dall’inizio. Possiamo fare dei miglioramenti dopo il lancio e questo \u00e8 proprio l’argomento di questa seconda parte di questa serie<\/a>. La perfezione \u00e8 molto lontana. Per ora, liberiamoci dell’hangover di JavaScript migliorando la scriptuation<\/em> a breve termine del vostro sito.<\/p>\n\n\n\n

Radunate i soliti sospetti<\/h2>\n\n\n\n

Potrebbe sembrare un futile esercizio, ma vale la pena scorrere l’elenco delle ottimizzazioni di base. Non \u00e8 insolito che i grandi team di sviluppo, particolarmente per quelli che lavorano su molti repository o che non usano boilerplate ottimizzati, le ignorino.<\/p>\n\n\n\n

Scuotete quegli alberi<\/h3>\n\n\n\n

Per prima cosa, assicuratevi che la vostra toolchain sia configurata per fare tree shaking<\/em><\/a>. Se il tree shaking \u00e8 un concetto nuovo per voi, l’anno scorso ho scritto una guida sull’argomento<\/a>. In poche parole, il tree shaking \u00e8 un processo nel quale gli export non utilizzati nella vostra codebase non vengono impacchettati nel vostro bundle in produzione.<\/p>\n\n\n\n

Il tree shaking \u00e8 disponibile \u201cout of the box\u201d con i moderni bundlers come webpack<\/a>, Rollup<\/a> o Parcel<\/a>. Grunt<\/a> o gulp<\/a>, che non sono bundlers<\/em> ma piuttosto task runner<\/em>, non lo faranno per voi. Un task runner non crea un dependency graph<\/a> come invece fa un bundler. Al contrario, fanno dei task discreti sui files che date loro in pasto con un qualsiasi numero di plugin. I task runner possono<\/em> essere estesi con plugin che usino dei bundler per processare JavaScript. Se estendere cos\u00ec i task runner \u00e8 per voi un problema, probabilmente dovrete fare un audit manuale e rimuovere il codice inutilizzato.<\/p>\n\n\n\n

Perch\u00e9 il tree shaking sia efficace, devono essere vere le seguenti condizioni:<\/p>\n\n\n\n

  1. La logica della vostra app e i package che installate nel vostro progetto devono essere creati come moduli ES6<\/a>. Fare tree shaking di moduli CommonJS<\/a> non \u00e8 praticamente possibile.<\/li>
  2. Il vostro bundler non<\/em> deve trasformare i moduli ES6 in un altro formato di modulo durante il build time. Se succede in una toolchain che usa Babel, @babel\/preset-env configuration<\/a> deve specificare modules: false<\/code><\/a> per impedire che il codice ES6 venga convertito a CommonJS.<\/li><\/ol>\n\n\n\n

    Nella remota possibilit\u00e0 in cui il tree shaking non avvenga durante il build, potrebbe essere utile farlo funzionare. Ovviamente, la sua efficacia varia caso per caso. Dipende anche dal fatto che i moduli che importate introducano degli effetti collaterali<\/a>, che potrebbero influenzare la capacit\u00e0 del bundler di fare shaking degli export inutilizzati.<\/p>\n\n\n\n

    Suddividete quel codice<\/h3>\n\n\n\n

    Ci sono delle buone possibilit\u00e0 che stiate usando una qualche forma di code splitting<\/a>, ma vale la pena rivalutare come lo state facendo. Indipendentemente da come<\/em> state suddividendo il codice, ci sono due domande che vale sempre la pena porsi:<\/p>\n\n\n\n

    1. State de-duplicando il codice comune<\/a> tra gli entry point<\/a>?<\/li>
    2. State facendo lazy loading di tutte le funzionalit\u00e0 che potete ragionevolmente con dynamic import()<\/code><\/a>?<\/li><\/ol>\n\n\n\n

      Queste cose sono importanti perch\u00e9 ridurre il codice ridondante \u00e8 fondamentale per la performance. Anche la funzionalit\u00e0 lazy loading migliora la performance abbassando l’impronta iniziale di JavaScript su una data pagina. Sul fronte della ridondanza, usare un tool di analisi come Bundle Buddy<\/a> pu\u00f2 aiutarvi a scoprire se avete un problema.<\/p>\n\n\n\n

      \"The
      Bundle Buddy esamina le statistiche di compilazione del vostro webpack e determina quanto codice sia condiviso tra i vostri bundle.<\/figcaption><\/figure>\n\n\n\n

      Quando c’\u00e8 in ballo il lazy loading, pu\u00f2 essere un po’ difficile sapere da dove cominciare a cercare delle opportunit\u00e0. Quando le cerco in un progetto esistente, cercher\u00f2 i punti di interazione dell’utente in tutta la codebase, come gli eventi click e keyboard e candidati simili. Ogni codice che richiede un’interazione con l’utente per girare \u00e8 un potenziale buon candidato per l’import()<\/code> dinamico.<\/p>\n\n\n\n

      Ovviamente, caricare gli script on demand porta con s\u00e9 la possibilit\u00e0 che l’interattivit\u00e0 possa essere sensibilmente ritardata, dal momento che lo script necessario per l’interazione deve essere prima caricato. Se l’uso dei dati non \u00e8 un problema, prendete in considerazione l’uso del resource hintrel=prefetch<\/code><\/a> per caricare tali script con una priorit\u00e0 minore, cos\u00ec non si contenderanno la banda con le risorse critiche. Il supporto per rel=prefetch<\/code><\/a> \u00e8 buono, ma non far\u00e0 danni se non \u00e8 supportato, dal momento che quei browser che non lo supportano ignoreranno il markup che non comprendono.<\/p>\n\n\n\n

      Esternalizzate il codice di terze parti hosted<\/h3>\n\n\n\n

      Idealmente, dovreste fare self-hosting di quante pi\u00f9 dipendenze del vostro sito possibile. Se per qualche ragione dovete<\/em> caricare le dipendenze da una terza parte, segnatele come esterne<\/a> nella configurazione del vostro bundler. Se non riuscite a farlo, potrebbe significare che i visitatori del vostro sito scaricheranno sia il codice ospitato localmente sia<\/em> lo stesso codice da terze parti.<\/p>\n\n\n\n

      Osserviamo un’ipotetica situazione in cui questo potrebbe danneggiarvi. Supponiamo che il vostro sito carichi Lodash da un CDN pubblico. Per\u00f2 avete anche installato Lodash nel vostro progetto per lo sviluppo locale. Tuttavia, se non riuscite a marcare Lodash come esterno, il vostro codice di produzione finir\u00e0 col caricarne una copia di terze parti oltre<\/em> alla copia bundled, ospitata localmente.<\/p>\n\n\n\n

      Potrebbe sembrare<\/em> cosa nota se sapete come muovervi tra i bundler, ma ho visto che viene sottovalutata. Vale la pena controllare due volte.<\/p>\n\n\n\n

      Se non siete convinti della necessit\u00e0 di ospitare sul vostro hosting le dipendenze di terze parti, allora prendete in considerazione l’opzione di aggiungere per loro dns-prefetch<\/code><\/a>, preconnect<\/code><\/a> o addirittura preload<\/code><\/a>. In questo modo abbasserete il Time to Interactive<\/a> del vostro sito e, se JavaScript \u00e8 cruciale per la resa del contenuto, lo Speed Index<\/a> del vostro sito.<\/p>\n\n\n\n

      Alternative pi\u00f9 piccole per minori overhead<\/h2>\n\n\n\n

      Userland JavaScript<\/a> \u00e8 come un negozio di caramelle esageratamente grande e noi sviluppatori siamo stupefatti dall’incredibile quantit\u00e0 di offerte open source. I framework e le librerie ci permettono di estendere le nostre applicazioni per fare tutta una serie di cose che altrimenti richiederebbero tonnellate di tempo e lavoro.<\/a><\/p>\n\n\n\n

      Sebbene io personalmente preferisca minimizzare aggressivamente i framework e le librerie client-side dei miei progetti, il loro valore \u00e8 inestimabile. Tuttavia, noi abbiamo<\/em> la responsabilit\u00e0 di essere un po’ aggressivi quando si tratta di decidere cosa installare. Quando abbiamo gi\u00e0 realizzato e spedito qualcosa che dipende da un sacco di codice per funzionare, abbiamo accettato il fatto che solo i maintainer di quel codice lo possono gestire in pratica. Giusto?<\/p>\n\n\n\n

      Forse, o forse no. Dipende dalle dipendenze che abbiamo usato. Per esempio, React \u00e8 estremamente popolare ma Preact<\/a> \u00e8 un’alternativa ultra-piccola<\/a> che condivide ampiamente la stessa API e mantiene la compatibilit\u00e0 con molti degli add-on di React. Luxon<\/a> e date-fns<\/a> sono alternative molto pi\u00f9 compatte di moment.js<\/a>, che non \u00e8 esattamente piccolo<\/a>.<\/p>\n\n\n\n

      Librerie come Lodash<\/a> offrono molti metodi utili. tuttavia, alcuni di essi sono facilmente sostituibili con ES6 nativo. Il metodo compact<\/code> di Lodash<\/a>, per esempio, \u00e8 sostituibile con il metodo array filter<\/code><\/a>. Molti altri sono sostituibili<\/a> senza troppa fatica e senza il bisogno di richiamare una grande libreria di utility.<\/p>\n\n\n\n

      Quali che siano i vostri tool preferiti, l’idea \u00e8 la stessa: fate delle ricerche per vedere se ci sono alternative pi\u00f9 piccole o se le feature del linguaggio nativo possono andare bene. Potreste rimanere stupiti da quanto poco ci voglia per ridurre seriamente l’overhead della vostra app.<\/p>\n\n\n\n

      Fate invio differenziato degli script<\/h2>\n\n\n\n

      C’\u00e8 una buona possibilit\u00e0 che stiate usando Babel nella vostra toolchain per trasformare il vostro sorgente ES6 in codice che possa girare sui browser pi\u00f9 vecchi. Questo implica che siete costretti a inviare giganti bundle anche ai browser a cui non servono, finch\u00e9 non ci saranno pi\u00f9 i browser pi\u00f9 vecchi? Ovviamente no<\/a>! L’invio in maniera differenziata ci aiuta ad aggirare questo problema generando due diverse build del vostro sorgente ES6:<\/p>\n\n\n\n