Déployer encore moins de code en production
Tree-shaking
Vincent Ogloblinsky
![](https://s3.amazonaws.com/media-p.slid.es/uploads/573039/images/3581264/logo-sii-big-bordered.png)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/573039/images/3581796/GitHub-Mark-32px-white.png)
@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
![](https://s3.amazonaws.com/media-p.slid.es/uploads/573039/images/3688730/rollup.png)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/573039/images/3688732/webpack.png)
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)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/573039/images/3688750/cost.jpg)
Webpack
![](https://s3.amazonaws.com/media-p.slid.es/uploads/573039/images/3688732/webpack.png)
Webpack
Tree-shaking toujours en béta
![](https://s3.amazonaws.com/media-p.slid.es/uploads/573039/images/3688767/webpack-2-github-roadmap.png)
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
![](https://s3.amazonaws.com/media-p.slid.es/uploads/573039/images/3688730/rollup.png)
rollup.js
Tree-shaking : argument marketing n°1
![](https://s3.amazonaws.com/media-p.slid.es/uploads/573039/images/3688787/rollup.js.org.png)
rollup.js - How it works ?
il nettoie tout "directement"
that's it !
> npm run demo --simple
↓
![](https://s3.amazonaws.com/media-p.slid.es/uploads/573039/images/3688793/1.png)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/573039/images/3688796/2.png)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/573039/images/3688803/3.png)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/573039/images/3688804/4.png)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/573039/images/3688805/5.png)
> npm run demo --es6-library
↓
![](https://s3.amazonaws.com/media-p.slid.es/uploads/573039/images/3688810/1.png)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/573039/images/3688812/2.png)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/573039/images/3688813/3.png)
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
- 4,696