Tree shaking vs minification : optimiser votre bundle

Comprenez les différences entre tree shaking et minification JavaScript — deux techniques complémentaires pour réduire la taille de vos bundles et accélérer votre site.

13.05.2026

9 min de lecture

Partager cet article:

JavaScript

Tree shaking

Minification

Webpack

Vite

Performance

Optimisation

Bundle

Tutoriel

Deux techniques souvent confondues

En optimisant un front moderne, vous entendez sans cesse « minifier » et « tree-shaker » vos bundles. Ce ne sont pas deux noms pour la même chose : la minification compresse le code déjà inclus dans le fichier final (espaces, noms courts), alors que le tree shaking retire du graphe les modules qui ne sont jamais utilisés. Les deux réduisent les octets transférés, mais à des étapes différentes du pipeline. Pour une passe rapide sur un fichier isolé (sans bundler), un minificateur JavaScript en ligne suffit souvent ; pour une application complète, vous combinez généralement analyse statique des imports, bundler en mode production et minificateur (Terser, esbuild, SWC…). Ce guide pose les définitions, un tableau comparatif et une configuration réaliste avec Vite ou Webpack — en renvoyant vers notre guide de minification JavaScript pour les réglages fins.

Savoir quel levier réduit le nombre de modules et quel levier réduit la taille du texte déjà inclus

Éviter de croire que « minifier » supprime lodash entier alors que vous importez une seule fonction

Configurer bundler + minificateur pour cumuler tree shaking et minification

Repérer quand la CSS doit être purgée à la façon d’un « tree shaking » (Tailwind, PurgeCSS)

Mesurer avec un analyseur de bundle au lieu de deviner les gains

Minification et tree shaking : deux effets différents

Minification : compresser ce qui reste dans le fichier

La minification travaille sur un fichier dont le contenu est déjà décidé : elle enlève tout ce qui est superflu pour le moteur JS (espaces, commentaires, renommage local agressif selon l’outil). Elle ne peut pas deviner si une fonction exportée servira plus tard si elle est bien présente dans le bundle. Pour les bases et comparatifs d’outils, voyez notre guide complet sur la minification JavaScript. Pour inspecter ou retrouver la lisibilité après coup, gardez sous la main un déminificateur JavaScript ou la fonction Beautify.

Avant

function calculateTotal(price, quantity) {
  const taxRate = 0.2;
  return price * quantity * (1 + taxRate);
}
export { calculateTotal };

Après

function calculateTotal(n,t){return n*t*1.2}export{calculateTotal};

Tree shaking : retirer les branches mortes du graphe

Le tree shaking s’appuie sur les modules ES (`import` / `export`) et sur une analyse statique : tout ce qui n’est pas référencé depuis une entrée peut être écarté avant même que la minification intervienne. Les bibliothèques doivent exposer des builds compatibles (`sideEffects` dans `package.json`, pas de mutations globales cachées). La démonstration la plus parlante reste le passage d’un import « baril » à un import ciblé.

Préférez un import nommé depuis lodash-es ou un chemin précis plutôt qu’un import par défaut de lodash lorsque votre chaîne supporte le shaking

Exposez correctement les champs module et exports dans package.json des libs pour une résolution statique

Ajoutez sideEffects: false (ou une liste précise) dans package.json lorsque vos fichiers sont purement fonctionnels

Évitez les imports dynamiques trop larges qui forcent à garder des chunks entiers sans analyse fine

Combinez avec code splitting — le shaking s’applique par chunk, pas « magiquement » sur tout le site

Avant

// utils/math.ts — tout le barrel exporté est potentiellement traîné
export function square(x){return x*x}
export function cube(x){return x*x*x}
export function unusedLegacy(){/* ancienne API */}

// main.ts
import { square } from './utils/math'

Après

// Après analyse du bundler : seules les définitions
// réellement utilisées peuvent rester dans le chunk,
// puis la minification réduit encore la syntaxe.
// cube() et unusedLegacy() peuvent être éliminés
// si aucun autre fichier ne les ré-importe.

CSS : purge et « shaking » pragmatique

Il n’existe pas de tree shaking ES modules pour votre feuille CSS comme pour le JS, mais les pipelines PostCSS / Tailwind / PurgeCSS jouent un rôle équivalent : ils retirent les règles non utilisées avant la phase où vous appliquez un minificateur CSS en ligne ou PostCSS cssnano sur la sortie finale.

Scannez vos templates JSX/HTML pour ne livrer que les utilitaires Tailwind réellement présents

Coupez les anciennes feuilles « glob » une fois migrées vers des imports locaux par composant

Validez visuellement après purge — une classe dynamique concaténée peut disparaître par erreur

Après purge, passez la feuille au minifier pour gagner encore quelques pourcents sur les octets

Mesurer ce qui change vraiment dans le bundle

Analyser avant / après

Les deux techniques se voient dans des colonnes différentes du rapport : le tree shaking diminue le nombre et la surface des modules (par exemple lodash qui disparaît presque entièrement), la minification réduit la colonne « taille gzip » pour un même graphe. Utilisez un treemap pour éviter les régressions après mise à jour de dépendances.

Schéma conceptuel comparant bundle volumineux vs bundle réduit après optimisations

rollup-plugin-visualizer, webpack-bundle-analyzer ou l’outil intégré de Vite (`vite-bundle-visualizer`)

Source Map Explorer pour relier octets au fichier source

Chrome DevTools Coverage pour repérer le JS/CSS chargé mais jamais exécuté

Comparaison gzip/brotli après build pour valider le gain réseau réel

Ne pas oublier la prod

Activez systématiquement `NODE_ENV=production` (ou équivalent) : sans ce signal, certains bundlers désactivent optimisations et dead-code elimination.

Vérifiez que votre CI reconstruit bien la même commande que votre environnement staging

Stockez les rapports de taille max de bundle comme budget de perf

Comparez avant/après mise à jour npm majeure — une dépendance peut casser le shaking

Tableau mental : minification vs tree shaking

Synthèse comparée

Utilisez ce récapitulatif quand vous estimez un ticket d’optimisation : la première question est « ce code doit-il exister dans le graphe ? », la seconde est « comment réduire sa représentation textuelle ? ».

Minification

objet:Réécrire le code déjà inclus pour lever tout ce qui est superflu syntaxiquement

moment:Après bundling ou sur un fichier isolé

gain typique:Souvent 10–40 % sur la même entrée selon style et commentaires

limites:Ne supprime pas un module entier importé mais inutilisé

Tree shaking

objet:Retirer exports / modules non atteints depuis les points d’entrée

moment:Pendant la résolution du graphe ES modules

gain typique:Peut diviser par deux (ou plus) un import de bibliothèque mal choisi

limites:Impossible si code dynamique ou CommonJS opaque sans transpilation

Questions rapides à vous poser

Ces contrôles évitent les optimisations hors sol.

Ai-je encore des imports « tout le package » là où un chemin précis existe ?

Mes libs déclarent-elles correctement le champ sideEffects pour que le bundler ose élaguer ?

La minification tourne-t-elle après le shaking pour comprimer ce qui reste ?

Ai-je besoin d’un outil en ligne pour un snippet hors bundle ou d’un rebuild complet pour l’app ?

Pour la CSS, ai-je purgé avant de mesurer la minification seule ?

Minifier rapidement un fichier hors bundler

FastMinify pour une passe ponctuelle

Quand vous n’avez pas encore branché Webpack/Vite — ou que vous optimisez un script livré tel quel — collez votre JS dans notre outil : vous obtenez une sortie compactée immédiatement, avec option inverse pour relire le code.

Coller ou charger votre fichier

Utilisez le minificateur JavaScript en ligne : tout reste dans le navigateur.

Comparer avec Beautify

Alternez avec Beautify pour un format lisible équivalent à un petit « undo » avant de réinjecter dans votre pipeline.

Ne pas confondre avec le shaking

L’outil minifie un fichier à la fois ; pour éliminer des modules dans tout un projet, il faut bundler en production.

Relier aux workflows modernes

Quand votre codebase grossit, alignez-vous sur les pratiques décrites dans notre comparatif minificateurs en ligne vs outils de build : l’outil en ligne garde une place pour les exceptions et les prototypes.

Prototype ou landing statique : minificateur en ligne

Application SPA ou SSR : bundler + shaking + minification

Audit ponctuel : déminifier avec FastMinify puis corriger à la source

Combiner tree shaking et minification dans le build

Vite (Rollup sous le capot)

`vite build` active Rollup en production avec tree shaking et minification esbuild par défaut — vérifiez que vos imports sont compatibles ES modules.

Configuration

// vite.config.ts (extrait)
import { defineConfig } from 'vite'

export default defineConfig({
  build: {
    target: 'es2019',
    minify: 'esbuild',
    rollupOptions: {
      treeshake: {
        moduleSideEffects: (id) => !id.includes('.css'),
        propertyReadSideEffects: false,
      },
    },
  },
})

Utilisation

# Build prod avec métriques
NODE_ENV=production npm run build

# Inspectez dist/assets/*.js — les chunks reflètent
# ce que Rollup a conservé après shaking puis minification.

Webpack 5

`mode: 'production'` active `usedExports` et la compilation avec minifier ; assurez-vous que `package.json` des libs déclare correctement les effets de bord.

Configuration

// webpack.config.js (extrait)
module.exports = {
  mode: 'production',
  optimization: {
    usedExports: true,
    sideEffects: true, // respecte package.json "sideEffects"
    minimize: true,
    minimizer: [
      /* TerserPlugin ou SWCMinifyPlugin */
    ],
  },
};

Utilisation

// Pour une entrée évidente :
// webpack analyse depuis votre entrypoint,
// marque exports inutilisés, puis le minifier compacte.
import { initApp } from './app'
initApp()

CSS en production

Enchaînez purge Tailwind ou PurgeCSS, puis minification — comme vu dans notre guide sur la minification CSS. Le shaking « logique » est côté purge ; la minification peaufine la sortie.

Exemple de base

/* Après purge des classes non utilisées */
.btn{padding:.5rem 1rem;border-radius:.375rem}

Minification de fichier

/* postcss avec cssnano en fin de chaîne */
.btn{padding:.5rem 1rem;border-radius:.375rem}
/* → devient une ligne ultra compacte */

Conclusion

Tree shaking et minification sont complémentaires : le premier dessine un graphe léger, le second écrit ce graphe avec le minimum d’octets. Ignorez l’un ou l’autre et vous laissez soit du code mort embarqué, soit une représentation encore verbeuse d’un graphe déjà propre. Pour les snippets hors projet, un minificateur en ligne suffit ; pour tout le reste, automatisez dans votre bundler tout en gardant FastMinify sous la main pour les cas limites.

Réduisez la taille de votre JavaScript en quelques secondes

Combinez imports ES précis, déclaration sideEffects honnête et build production systématique

Mesurez avec un analyseur de bundle après chaque refacto de dépendances

Pour la CSS, purge puis minification avec les guides FastMinify dédiés

Gardez le comparatif minificateurs en ligne vs build sous les yeux pour les arbitrages d’équipe

Besoin de relire du JS compact ? Utilisez Beautify ou un déminificateur avant debug

Partager cet article

Partager cet article:

Articles connexes

Coût API LLM : batch API, prompt caching et projection mensuelle

Réduisez la facture OpenAI/Anthropic/Gemini : estimez input/output, activez batch et caching dans vos calculs — tarifs vérifiés, 100 % local.

21.08.202610 min de lecture

Fenêtre de contexte LLM : dimensionner vos prompts pour GPT, Claude et Gemini

RAG, agents multi-tours, system prompts : calculez le % de fenêtre utilisée et la marge restante avant d'envoyer à l'API.

19.08.20268 min de lecture

Quand TOON bat JSON pour les prompts LLM (et quand il ne le bat pas)

Guide honnête : données tabulaires uniformes, workflow convertir → compter → tarifer → contexte ; pas un manifeste de remplacement JSON/YAML.

16.08.20268 min de lecture