Le tree shaking JavaScript est-il vraiment indispensable pour le SEO ?

Qu'est-ce que le tree shaking et pourquoi Google en parle-t-il maintenant ?

Le tree shaking est une technique d'optimisation qui analyse votre code JavaScript pour identifier et supprimer automatiquement les fonctions, classes et dépendances non utilisées. Concrètement, si vous importez une librairie de 200 Ko mais n'utilisez que 10 % de ses fonctionnalités, le tree shaking va éliminer les 90 % restants avant de générer le bundle final.

Google insiste sur cette pratique parce que le JavaScript bloat reste un problème massif sur le web. Les sites modernes embarquent des dizaines de librairies, souvent partiellement exploitées, ce qui dégrade les Core Web Vitals — en particulier le LCP et le TID. Martin Splitt ne fait pas dans la nuance : c'est une recommandation forte, pas une suggestion facultative.

Comment le tree shaking impacte-t-il concrètement le crawl et l'indexation ?

La réduction des bundles JavaScript a un impact direct sur la vitesse de rendu des pages, ce qui influence la capacité de Googlebot à crawler efficacement votre site. Un bundle lourd retarde l'exécution JS, donc le rendu du contenu dynamique, ce qui peut limiter ce que Google indexe réellement.

Au-delà du crawl, c'est surtout sur l'expérience utilisateur que le tree shaking joue. Des bundles légers accélèrent le Time to Interactive, améliorent les métriques de performance — et Google a clairement indiqué que les Core Web Vitals sont un facteur de ranking. Moins de code = moins de parsing, moins de compilation, moins de latence réseau.

Tous les bundlers supportent-ils le tree shaking de la même manière ?

Non, et c'est là que ça se complique. Webpack, Rollup, Vite, esbuild : tous proposent du tree shaking, mais avec des niveaux d'efficacité variables. Webpack nécessite une configuration ES modules strict (mode production activé, sideEffects définis dans package.json), tandis que Rollup est nativement plus agressif sur l'élimination de code mort.

Certains modules npm mal packagés ou utilisant CommonJS au lieu d'ES modules résistent au tree shaking. Si vos dépendances ne sont pas écrites avec des exports ES6, vous ne verrez aucun bénéfice — et webpack ne vous alertera pas automatiquement. Il faut auditer chaque librairie majeure de votre stack.

• Le tree shaking élimine le code JavaScript non utilisé pour réduire la taille des bundles
• Google recommande cette pratique fortement pour améliorer les performances et les Core Web Vitals
• Les bundlers modernes (webpack, Rollup, Vite) supportent le tree shaking, mais leur efficacité varie selon la configuration et les modules utilisés
• Les dépendances en CommonJS ou mal packagées résistent au tree shaking — un audit des librairies est indispensable
• L'impact SEO se mesure via le LCP, le TID, et la capacité de Googlebot à rendre rapidement le contenu dynamique

Cette recommandation est-elle cohérente avec ce qu'on observe sur le terrain ?

Absolument. Les sites qui ont optimisé leurs bundles JS via tree shaking voient des gains mesurables sur les Core Web Vitals, particulièrement le LCP et le TID. Les audits Lighthouse remontent systématiquement l'alerte « Reduce unused JavaScript » sur les sites qui n'ont pas mis en place cette pratique — et Google Search Console commence à croiser ces métriques avec les performances de ranking.

Ce qui est intéressant, c'est que Martin Splitt ne se contente pas de recommander la pratique : il cite explicitement webpack et autres bundlers, ce qui montre que Google est conscient des contraintes techniques réelles des équipes dev. Ce n'est pas une injonction abstraite — c'est une directive outillée. Reste que beaucoup de sites utilisent des frameworks (React, Vue, Angular) avec des configurations de build par défaut qui ne vont pas assez loin.

Quelles nuances faut-il apporter à cette déclaration ?

Le tree shaking n'est pas une baguette magique. Il ne supprime que le code statiquement analysable comme inutilisé. Si votre codebase utilise des imports dynamiques mal structurés, des évaluations eval(), ou des dépendances avec side effects non déclarés, le bundler ne pourra rien faire — ou pire, cassera des fonctionnalités.

Autre point critique : Google ne précise pas de seuil quantitatif. À partir de quelle taille de bundle non optimisé y a-t-il un impact ranking ? 100 Ko ? 500 Ko ? [À vérifier] — aucune donnée officielle ne donne de benchmark clair. On sait juste que « moins c'est mieux », ce qui reste frustrant pour prioriser les chantiers techniques. Mon expérience terrain suggère qu'en dessous de 150 Ko de JS total (compressé gzip), l'impact reste marginal ; au-delà de 400 Ko, c'est critique.

Dans quels cas cette règle pourrait-elle être moins prioritaire ?

Si votre site est majoritairement server-side rendered (SSR) avec très peu de JS client, le tree shaking aura un impact limité — votre priorité sera ailleurs (TTFB, hydration, cache). De même, les sites statiques générés (Jamstack pur) embarquent souvent des bundles déjà minimes par construction.

Attention aussi aux sites à forte interactivité (dashboards, SPAs complexes) : réduire le bundle initial est crucial, mais fragmenter trop agressivement via code splitting peut générer des latences réseau supplémentaires sur des connexions lentes. Il faut équilibrer tree shaking, lazy loading, et prefetching — ce n'est pas un paramètre isolé. [À vérifier] l'impact réel sur le ranking comparé à d'autres optimisations (CDN, cache, image optimization) : Google ne hiérarchise jamais explicitement ces leviers.

Que faut-il faire concrètement pour activer le tree shaking ?

D'abord, assurez-vous que votre bundler est en mode production (webpack --mode production, Vite build, etc.). C'est le prérequis absolu : le tree shaking n'opère généralement pas en mode développement pour préserver la vitesse de rebuild. Ensuite, vérifiez que vos modules utilisent des exports ES6 (export / import) et non CommonJS (module.exports / require).

Dans votre package.json, déclarez explicitement le champ "sideEffects" : soit false si aucun fichier n'a d'effet de bord, soit un array listant les fichiers concernés (typiquement les CSS imports). Sans cette déclaration, webpack reste conservateur et garde du code qu'il pourrait éliminer. Auditez ensuite vos dépendances avec webpack-bundle-analyzer ou source-map-explorer pour identifier les librairies qui alourdissent inutilement vos bundles.

Quelles erreurs éviter lors de la mise en place ?

Ne vous contentez pas d'activer le mode production et de considérer le job fait. Beaucoup de développeurs oublient que certaines librairies populaires (Lodash, Moment.js) nécessitent des imports sélectifs pour bénéficier du tree shaking. Importer « import _ from 'lodash' » embarque toute la librairie ; « import debounce from 'lodash/debounce' » ou utiliser lodash-es permet l'élimination du reste.

Autre piège fréquent : les polyfills et shims ajoutés globalement. Si vous injectez core-js ou regenerator-runtime sans ciblage précis des navigateurs (via Babel + browserslist), vous embarquez des dizaines de Ko inutiles pour les navigateurs modernes. Utilisez @babel/preset-env avec "useBuiltIns": "usage" pour ne charger que les polyfills nécessaires selon votre cible.

Comment vérifier que l'optimisation est effective ?

Lancez un build de production et analysez la taille des bundles avec webpack-bundle-analyzer ou l'équivalent de votre bundler. Comparez avant/après tree shaking : vous devriez voir une réduction nette des modules inutilisés. Testez ensuite sur Lighthouse (onglet Performance de Chrome DevTools) et vérifiez que l'alerte « Reduce unused JavaScript » a disparu ou s'est significativement réduite.

Côté monitoring SEO, trackez vos Core Web Vitals dans Google Search Console section Signaux Web essentiels. Un bon tree shaking doit améliorer votre LCP et TID sur mobile — là où le JS pèse le plus lourd. Si après optimisation vous ne voyez aucun mouvement sur ces métriques, c'est soit que vos bundles étaient déjà légers, soit qu'un autre goulot (images, TTFB, render-blocking CSS) masque les gains.

• Activer le mode production sur votre bundler (webpack, Rollup, Vite)
• Utiliser des exports ES6 (import/export) plutôt que CommonJS
• Déclarer le champ "sideEffects" dans package.json
• Auditer les dépendances avec webpack-bundle-analyzer
• Privilégier les imports sélectifs (lodash-es, date-fns) au lieu d'imports globaux
• Configurer Babel avec @babel/preset-env et "useBuiltIns": "usage" pour limiter les polyfills
• Vérifier l'impact réel via Lighthouse et Google Search Console (Core Web Vitals)