Faut-il vraiment découper son JavaScript par page pour optimiser le crawl ?

Pourquoi Google insiste sur le chargement conditionnel de JavaScript ?

Chaque script chargé dans une page mobilise des ressources de parsing et d'exécution. Googlebot dispose d'un budget de crawl et d'un budget de rendering limités. Quand un site charge reCAPTCHA, des widgets de chat, des scripts analytics ou des trackers publicitaires sur toutes les pages sans distinction, le crawler doit traiter ce poids mort à chaque visite.

Le code splitting consiste à découper son JavaScript en modules chargés uniquement quand nécessaire. Plutôt qu'un bundle monolithique de 500 Ko sur toutes les pages, on sert 150 Ko sur la home, 80 Ko sur les fiches produits, 200 Ko sur les pages de checkout. Google y gagne en efficacité de crawl, l'utilisateur y gagne en temps de chargement.

Qu'est-ce qui change concrètement pour le rendering ?

Googlebot utilise une version récente de Chromium pour exécuter JavaScript et générer le DOM final. Ce processus coûte cher en ressources. Plus le volume de JS est important, plus le délai avant indexation du contenu dynamique s'allonge. Dans certains cas, des scripts tiers bloquants peuvent même empêcher le rendu complet de la page.

En ne chargeant reCAPTCHA que sur les pages de formulaire de contact ou d'inscription, on évite de ralentir le rendering de milliers de fiches produits ou d'articles. Le bot accède plus vite au contenu critique et l'indexe sans délai.

Dans quels cas le code splitting impacte-t-il réellement les Core Web Vitals ?

Le First Input Delay (FID) et le Interaction to Next Paint (INP) sont directement affectés par le volume de JavaScript en cours d'exécution. Un bundle global qui inclut des dizaines de bibliothèques inutiles sur une page donnée augmente le temps de traitement du thread principal. L'utilisateur clique, mais le navigateur met 300 ms à réagir parce qu'il est occupé à parser du code mort.

Le Largest Contentful Paint (LCP) peut aussi souffrir si des scripts bloquent le chargement des ressources critiques. En segmentant le JS par contexte de page, on libère de la bande passante et on priorise le contenu visible.

• Code splitting réduit le temps de parsing en ne servant que le code nécessaire à chaque contexte de page
• Les Core Web Vitals s'améliorent mécaniquement avec moins de JavaScript inutile à exécuter
• Googlebot indexe plus vite le contenu dynamique quand le rendering est allégé
• Le budget de crawl est mieux utilisé si chaque page coûte moins cher en ressources serveur et client
• Les scripts tiers (reCAPTCHA, analytics, chat) sont les premiers candidats au chargement conditionnel

Cette recommandation est-elle cohérente avec les pratiques terrain observées ?

Oui. Les sites qui ont migré vers des architectures modulaires avec lazy-loading conditionnel rapportent systématiquement des gains sur les métriques de performance. Les outils comme Webpack, Vite ou Rollup permettent aujourd'hui de découper automatiquement le code en chunks optimisés. Les frameworks modernes (Next.js, Nuxt, SvelteKit) intègrent le code splitting par défaut.

Par contre, la déclaration de Martin Splitt reste vague sur le seuil d'impact réel. À partir de combien de Ko inutiles le crawler commence-t-il à pénaliser ? Quelle est la tolérance de Googlebot face à un bundle global de 200 Ko versus un découpage en 5 chunks de 40 Ko ? [A vérifier] : aucune donnée publique ne quantifie précisément le gain d'indexation lié au code splitting.

Quels sont les pièges à éviter dans l'implémentation ?

Le premier piège : fragmenter à l'excès. Si vous découpez en 150 micro-modules, vous multipliez les requêtes HTTP et introduisez de la latence réseau. HTTP/2 et HTTP/3 atténuent le problème, mais charger 50 fichiers de 5 Ko reste moins efficient que charger 3 fichiers de 80 Ko. Il faut trouver l'équilibre entre granularité et overhead réseau.

Deuxième piège : le chargement asynchrone mal géré. Si vous lazy-loadez un script qui modifie le DOM après le premier rendu, Googlebot peut indexer la version incomplète. Assurez-vous que le contenu critique soit présent dans le HTML initial ou chargé de manière synchrone et prioritaire. Le code splitting ne doit jamais retarder l'affichage du contenu indexable.

Dans quels cas cette règle ne s'applique-t-elle pas ou devient-elle contre-productive ?

Si votre site est majoritairement statique avec peu de JavaScript, le code splitting n'apporte rien. Un blog WordPress avec un thème classique et 50 Ko de JS global n'a aucun intérêt à complexifier son architecture. Le jeu n'en vaut pas la chandelle.

Autre cas limite : les Single Page Applications (SPA) où l'essentiel du contenu est généré côté client. Découper le JS n'aide pas si le bot doit de toute façon attendre que l'app s'initialise pour voir quoi que ce soit. Dans ce contexte, le Server-Side Rendering (SSR) ou la génération statique sont des leviers bien plus puissants que le code splitting seul.

Comment auditer les scripts inutiles chargés sur chaque page ?

Ouvrez la Coverage tab dans Chrome DevTools. Rechargez votre page et observez le pourcentage de code JavaScript effectivement exécuté. Si vous voyez 70 % de rouge (code non utilisé), vous avez un problème. Identifiez les scripts tiers qui se chargent partout alors qu'ils ne servent que sur certaines pages.

Utilisez WebPageTest ou Lighthouse pour repérer les scripts bloquants. La section "Reduce unused JavaScript" vous liste les fichiers à découper en priorité. Croisez ces données avec Google Analytics pour voir quelles pages reçoivent le plus de trafic organique : ce sont celles où l'optimisation aura le plus d'impact SEO.

Quelle stratégie de découpage adopter selon le type de site ?

Pour un site e-commerce, séparez le JS des pages produit (galerie d'images, sélecteurs de variantes) du JS des pages catégorie (filtres, tri) et du JS du tunnel de commande (validation de formulaire, paiement). reCAPTCHA ne se charge que sur les formulaires d'inscription et de contact, pas sur les fiches produit.

Pour un site média ou blog, lazy-loadez les widgets de partage social, les commentaires, les publicités programmatiques. Le contenu textuel et les images doivent être disponibles immédiatement, les scripts d'interaction peuvent arriver après. Utilisez des techniques comme Intersection Observer pour charger les modules au scroll.

Quels outils et frameworks facilitent le code splitting en production ?

Les bundlers modernes (Webpack, Vite, Rollup, Parcel) supportent le code splitting natif via dynamic imports. En React, utilisez React.lazy() et Suspense. En Vue, defineAsyncComponent(). Next.js et Nuxt gèrent le découpage automatique par route, ce qui simplifie énormément l'implémentation.

Côté monitoring, Crux et PageSpeed Insights vous montrent l'évolution des Core Web Vitals après déploiement. Search Console signale les pages avec problèmes d'expérience utilisateur. Si vous voyez une amélioration du LCP et de l'INP après code splitting, vous êtes sur la bonne voie.

• Auditer la Coverage des scripts avec Chrome DevTools et Lighthouse
• Identifier les scripts tiers chargés globalement (reCAPTCHA, analytics, chat, publicité)
• Implémenter le code splitting par route ou par composant avec dynamic imports
• Configurer des headers Cache-Control et versionner les bundles avec hash de contenu
• Tester l'indexation des pages critiques avec URL Inspection Tool après déploiement
• Monitorer les Core Web Vitals via Crux et PageSpeed Insights sur 28 jours