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
Webpack
Tree-shaking toujours en béta
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
