Déployer encore moins de code en production

Tree-shaking

Vincent Ogloblinsky

@vogloblinsky

Architecte logiciel

"Technologies frontend"

Plan

1. " Tree-shaking " versus " Dead code elimination "

2. Les outils disponibles

3. Démonstration simple des 2 outils

4. Démonstration enrichie avec lodash

5. Conclusion

Contexte

Sur le web, chaque second compte.

exemple du ecommerce :

100 000€ CA / J

délai de 1s ~= 2,5 M€ perte sur l'année

source: How Loading Time Affects Your Bottom Line

 

50% des gens s'attendent à un temps de chargement de ~2s

le chargement moyen en 3G d'une page est de 19s...

Pour réduire ce "délai"

  • faire un rendu côté serveur (server side rendering)
  • lazy loading
  • diminuer le poids de vos assets

Processus classique de build

TREE

SHAKING

DEAD

CODE

ELIMINATION

Un peu de théorie

« Dead code elimination »

versus

« Tree-shaking »

Dead code elimination

on part d’un ensemble de lignes de code,

et on enlève ce qu’on peut

→ on "remonte" le code

Dead code elimination

function test() {
    var a = 24,
        b = 12,
        c;
    c = a + b;
    return c;
    b = 20;
    return;
}

Code non atteignable

Tree shaking

on prend seulement ce qu’on a besoin, le code vivant

→ il "descend" le code

graphe de dépendance nécessaire

→ "modules" ES6

  • analyse les modules ES6 "non-utilisés"
  • analyse les exports ES6 "non-utilisés"

et alors, ça revient pas au même ?

non, l’inclusion de "code vivant" est logiquement meilleure

mais il faut penser "modules" de bout en bout

Limites

  • ne fonctionne qu'avec des modules ES6 -> structure statique
  • ça peut coincer -> analyse de code statique sur un langage "dynamique" ...
    • si changement d'état global par une lib X, le tree-shaking se désactive

Les outils disponibles

Leur coût (overhead)

Browserify sadness: the more I modularize my code, the bigger it gets.

Nolan Lawson - Tweet

Over 400ms is being spent simply walking the Browserify tree.

Sam Saccone - Tumblr loading perf

The cost of small modules (Nolan Lawson)

Webpack

créé par Tobias Koppers

existe depuis mars 2012

la référence pour les "applications" web

Webpack

Tree-shaking toujours en béta

https://webpack.js.org/guides/tree-shaking/

Webpack - How it works ?

  • le code est annoté comme "à enlever"

 

/* unused harmony export bar */
var bar = {};
bar.b = 2;
  • l'option --optimize-minimize minifie le tout et fait le nettoyage

rollup.js

créé par Rich Harris, développeur du Guardian (Londres)

existe depuis mai 2015

la référence pour les "librairies" web

rollup.js

Tree-shaking : argument marketing n°1

rollup.js - How it works ?

il nettoie tout "directement"

 

that's it !

> npm run demo --simple

 

> npm run demo --es6-library

 

Bilan avec une librairie full ES6

avec rollup.js

sans tree-shaking avec tree-shaking
495 kb 54 kb
sans tree-shaking (min) avec tree-shaking (min)
61 kb 13 kb

Conclusion

  • webpack : mature, moins sur le poids (ça va s'améliorer)
  • rollup.js : au rendez-vous sur la taille de sortie et le temps d'exécution
  • suivant les outils, les stratégies ne sont pas les mêmes (les résultats aussi...)
  • ce n'est qu'une étape (parmi tant d'autres...)
  • ajouter ensuite la minification (rien de nouveau)

Ressources 1/3 | rollup.js

Ressources 2/3 | Webpack

Ressources 3/3 | Générales

Merci pour votre écoute

Tree shaking - Déployer moins de code en production

By Vincent Ogloblinsky

Tree shaking - Déployer moins de code en production

  • 198
Loading comments...

More from Vincent Ogloblinsky