Faut-il vraiment abandonner le unbundling complet de vos fichiers JavaScript ?

Pourquoi Google met-il en garde contre le unbundling total ?

La tendance actuelle pousse certains développeurs à découper leurs bundles JavaScript en centaines de petits fichiers, pensant optimiser le cache et réduire la taille des ressources transmises. Le raisonnement semble logique : si un fichier change, seul celui-là sera retéléchargé.

Sauf que les navigateurs imposent une limite stricte de connexions HTTP simultanées par hôte — généralement 6 à 8 selon les versions. Multiplier les fichiers crée un goulot d'étranglement : chaque requête doit attendre qu'une connexion se libère, augmentant le temps de chargement global de manière exponentielle.

Quelle différence entre unbundling complet et code-splitting par route ?

Le code-splitting par route consiste à découper le JavaScript en fonction des parcours utilisateur : un bundle pour la homepage, un autre pour les pages produit, etc. Cette approche limite le nombre de fichiers chargés à chaque navigation tout en maintenant une granularité raisonnable.

L'unbundling complet, lui, va jusqu'à séparer chaque module ou composant dans son propre fichier. Sur un site moderne, ça peut représenter plusieurs centaines de requêtes HTTP pour une seule page — même avec HTTP/2, la latence s'accumule.

Quel impact concret sur le crawl et l'indexation Google ?

Googlebot n'a pas une patience infinie. Un chargement qui traîne à cause de centaines de requêtes peut ralentir le rendering et retarder l'indexation du contenu généré en JavaScript. Pire : si le temps d'exécution dépasse les timeouts internes, Googlebot risque d'indexer une version incomplète.

Martin Splitt insiste sur ce point depuis des années : la performance JavaScript impacte directement le SEO. Un bundle optimisé se charge plus vite, s'exécute plus vite, et permet à Google de comprendre le contenu sans friction.

• Limite de connexions HTTP : 6-8 connexions simultanées par domaine selon les navigateurs
• Code-splitting recommandé : Découper par route ou fonctionnalité majeure, pas par module individuel
• Impact SEO : Un chargement trop lent ralentit le rendering et peut compromettre l'indexation du contenu JS
• HTTP/2 ne résout pas tout : Même avec multiplexing, la latence réseau s'accumule sur des centaines de requêtes
• Cache vs. performance : Un unbundling excessif optimise le cache au détriment du temps de chargement initial

Cette recommandation est-elle cohérente avec les observations terrain ?

Oui, et c'est même un des rares points où Google et la réalité technique s'alignent parfaitement. Sur des audits de sites utilisant du unbundling agressif (frameworks modernes mal configurés), on observe régulièrement des waterfalls de 200+ requêtes pour charger une seule page. Le FCP explose, le LCP aussi, et les Core Web Vitals plongent.

Les équipes qui ont basculé vers un code-splitting par route ont vu leurs métriques de performance bondir de 30 à 50% en moyenne. Le gain est mesurable, reproductible, et directement corrélé aux positions dans les SERP sur les requêtes concurrentielles.

Quelles nuances faut-il apporter selon le contexte technique ?

Avec HTTP/2 et HTTP/3, le multiplexing permet théoriquement de paralléliser les requêtes sans bloquer les connexions. Mais la latence réseau reste incompressible : chaque fichier supplémentaire ajoute un round-trip, et sur mobile ou connexions lentes, ça se paie cash.

Les CDN modernes proposent du bundling automatique à la volée (type Cloudflare Zaraz ou des solutions edge computing) qui peuvent atténuer le problème. Mais c'est une couche de complexité supplémentaire — et pas toujours compatible avec tous les frameworks. [A vérifier] selon votre stack technique.

Dans quels cas peut-on envisager plus de granularité ?

Si vous avez un site applicatif avec des sections très distinctes utilisées par des segments d'utilisateurs différents (ex: admin vs. front public), découper plus finement peut se justifier. L'essentiel est de ne jamais dépasser 15-20 fichiers JavaScript par page — au-delà, vous entrez en zone rouge.

Les Progressive Web Apps (PWA) avec service workers agressifs peuvent aussi tolérer plus de découpage, puisque le cache local évite les requêtes réseau après la première visite. Mais là encore, le premier chargement reste critique pour le SEO.

Que faut-il vérifier sur votre configuration actuelle ?

Commencez par analyser le nombre de requêtes JavaScript chargées au-dessus de la ligne de flottaison. Ouvrez DevTools, onglet Network, filtrez sur JS, et comptez. Si vous dépassez 10-12 fichiers sur la homepage, vous avez probablement un problème de unbundling excessif.

Ensuite, regardez le waterfall : les fichiers se chargent-ils en parallèle ou en cascade ? Si vous voyez des séries de 6-8 requêtes qui attendent, c'est la limite de connexions qui joue. Mesurez le temps entre le début du chargement et le Last Chunk Received du dernier fichier JS critique.

Comment corriger un unbundling trop agressif ?

Si vous utilisez Webpack, Vite, ou Rollup, revoyez vos règles de splitChunks ou manualChunks. L'objectif est de regrouper les dépendances tierces stables (vendor bundle) et de découper uniquement par grandes routes applicatives.

Pour un site e-commerce typique : un bundle pour les pages listing, un pour les fiches produit, un pour le tunnel de conversion. Pas un fichier par composant React ou Vue. Testez avec Lighthouse ou WebPageTest avant/après pour mesurer l'impact réel.

Quelles erreurs éviter dans la mise en œuvre ?

Ne tombez pas dans l'excès inverse : un bundle monolithique de 2 Mo n'est pas la solution non plus. L'équilibre se situe entre 5 et 15 fichiers JavaScript pour une page standard, avec une taille totale compressée sous 200-300 Ko si possible.

Autre piège : négliger le preloading des bundles critiques. Si vous splittez par route, assurez-vous que le navigateur connaît à l'avance les ressources prioritaires via <link rel="preload"> ou resource hints. Sinon, vous ajoutez de la latence inutile.

• Auditer le nombre de requêtes JS par page (objectif : < 15 fichiers)
• Analyser le waterfall réseau pour détecter les goulots de connexions simultanées
• Configurer le bundler pour regrouper les dépendances stables (vendor bundle)
• Découper uniquement par route ou fonctionnalité majeure, jamais par composant individuel
• Implémenter le preloading des bundles critiques pour réduire la latence
• Tester avant/après avec Lighthouse et mesurer FCP, LCP, TBT