Pourquoi le JavaScript coûte-t-il si cher à votre SEO ?

Le JavaScript est-il vraiment un frein au crawl et à l'indexation ?

Oui, mais la nuance compte. Google exécute le JavaScript, c'est un fait établi depuis des années. Mais cette exécution coûte du temps machine et de la bande passante — deux ressources que Googlebot rationne. Le téléchargement d'un bundle JS lourd, son parsing dans le moteur V8, puis l'exécution du code pour générer le DOM final : tout cela prend plusieurs centaines de millisecondes, voire des secondes sur un mobile moyen.

Concrètement, si ton contenu principal n'apparaît qu'après l'exécution d'un framework React ou Vue, Googlebot doit patienter. Et quand il patiente, il consomme du crawl budget. Sur un gros site avec des milliers de pages, ça peut faire la différence entre une indexation complète et un taux de couverture à 70 %.

Qu'entend Martin Splitt par « parsing et rendu progressifs de l'HTML » ?

Il fait référence au Server-Side Rendering (SSR) ou au rendu hybride (SSG, ISR). L'idée : envoyer un HTML déjà parsable, avec du texte visible immédiatement, sans attendre que le JS s'initialise. Le navigateur affiche du contenu en quelques dizaines de millisecondes, puis le JS prend le relais pour l'interactivité.

Pour Googlebot, c'est un gain net. Il peut indexer le contenu textuel sans exécuter une ligne de JS. Si le JS plante ou met trop de temps, le contenu reste accessible. C'est exactement ce que préconise Google depuis 2018-2019 avec son discours sur le « contenu critical above the fold ».

Le coût du JavaScript est-il le même pour tous les sites ?

Non. Un site vitrine avec 20 pages et 150 Ko de JS compressé ne subira jamais les mêmes problèmes qu'un marketplace avec 500 000 URLs et 800 Ko de JS par page. Le ratio contenu/JS est déterminant. Si ton JS sert uniquement à afficher du contenu déjà disponible côté serveur, tu paies un coût élevé pour rien.

À l'inverse, si ton JS gère de l'interactivité complexe (filtres dynamiques, panier, chat), le coût est justifié. Mais le contenu textuel principal, lui, doit être dans le HTML initial. C'est ce découplage que beaucoup de devs ne comprennent pas.

• Le JS coûte cher en temps de traitement, bande passante et crawl budget
• Le rendu progressif HTML permet de livrer du contenu indexable immédiatement
• Le ratio JS/contenu détermine la gravité de l'impact SEO
• Google exécute le JS, mais préfère ne pas en dépendre
• Le SSR ou SSG sont les solutions recommandées pour concilier frameworks modernes et SEO

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

Totalement. On le constate tous les jours sur des audits : les sites full-JS client-side (React sans SSR, Angular CSR) ont systématiquement des problèmes d'indexation ou de lenteur de crawl. Search Console montre des pages « explorée, actuellement non indexée » par centaines, et le Mobile-Friendly Test révèle des timeouts d'exécution JS.

Là où Martin Splitt reste flou, c'est sur le seuil exact. À partir de combien de Ko de JS le coût devient-il critique ? Quelle latence d'exécution déclenche une pénalité sur les Core Web Vitals ou le ranking ? [À vérifier] — Google ne donne jamais de chiffres précis, ce qui laisse chacun tâtonner avec Lighthouse et des tests A/B.

Le discours officiel cache-t-il une réalité plus brutale ?

Probablement. Google répète « nous exécutons le JS », mais en pratique, l'exécution n'est pas garantie en temps réel. Le rendering peut être différé de plusieurs secondes, voire minutes, surtout pour les sites à faible autorité. Et si ton JS dépend d'une API tierce qui timeout, le contenu ne s'affiche jamais pour le bot.

En production, j'ai vu des sites perdre 40 % de trafic après une migration vers un framework JS sans SSR. Le contenu était techniquement accessible, mais Google a mis 3 mois à tout réindexer, et entre-temps le ranking a plongé. Le coût du JS n'est pas qu'une question de performance, c'est aussi un risque de désindexation transitoire.

Tous les types de JavaScript sont-ils égaux face à ce coût ?

Non, et c'est là que ça devient intéressant. Un JS de tracking (Google Analytics, GTM) pèse 50 Ko mais s'exécute de manière asynchrone et n'impacte pas le contenu. Un framework SPA qui génère tout le DOM client-side, lui, bloque l'affichage du contenu principal. Google distingue probablement les deux, même si la doc officielle ne le dit pas explicitement.

Les scripts tiers (publicité, vidéos embarquées, widgets) sont souvent les pires coupables. Ils échappent au contrôle du SEO et peuvent exploser le Time to Interactive. Un audit Lighthouse montre régulièrement 60 % du JS comme « unused » ou « render-blocking ». C'est du poids mort qui grignote ton crawl budget pour rien.

Que faut-il faire concrètement pour réduire le coût du JavaScript ?

Première priorité : délivrer le contenu textuel principal en HTML statique, sans attendre l'exécution JS. Si tu utilises React, Next.js avec SSR ou SSG est le minimum syndical. Si tu es sous Vue, Nuxt.js en mode universel. Angular ? Active le rendu côté serveur avec Angular Universal.

Ensuite, nettoie le JS inutile. Un audit Lighthouse + Coverage tab dans Chrome DevTools te montrera le code qui ne s'exécute jamais. Split ton bundle par route, lazy-load les composants non-critiques, et vire les dépendances obsolètes. Un bundle JS divisé par deux, c'est 50 % de temps de parsing en moins.

Comment vérifier que Google accède bien au contenu rendu ?

Trois outils indispensables : l'outil d'inspection d'URL dans Search Console (onglet « Page rendue » pour voir le DOM final), le Mobile-Friendly Test (qui exécute le JS et affiche les erreurs), et un crawler comme Screaming Frog en mode « JavaScript rendering ». Compare le HTML brut (view-source) avec le DOM rendu — tout écart important est un red flag.

Si tu vois des timeouts ou des erreurs JS dans la console, Googlebot les voit aussi. Les messages « Failed to load resource » sur des CDNs externes ou des API tierces sont particulièrement toxiques. Un seul script bloquant peut rendre tout le contenu invisible pour le bot.

Quelles erreurs éviter absolument ?

Ne jamais bloquer les ressources JS et CSS dans le robots.txt — c'est une erreur de débutant qui empêche Google de rendre la page correctement. Ne pas se reposer uniquement sur le client-side rendering sans fallback HTML. Et surtout, ne pas ignorer les Core Web Vitals : un LCP au-delà de 4 secondes à cause d'un JS lourd va directement impacter le ranking, surtout sur mobile.

Autre piège classique : les SPAs qui changent le contenu sans mettre à jour l'URL ou le meta title dynamiquement. Google indexe alors une seule page avec un contenu générique, et tout le reste disparaît des SERPs. Le JS doit être invisible côté SEO : si on doit l'exécuter pour comprendre la page, c'est déjà trop tard.

• Implémenter du Server-Side Rendering (SSR) ou Static Site Generation (SSG) pour le contenu principal
• Réduire la taille des bundles JS : code-splitting, lazy-loading, tree-shaking
• Tester le rendu avec l'outil d'inspection d'URL et le Mobile-Friendly Test
• Vérifier les Core Web Vitals (LCP, CLS, INP) et corriger les scripts render-blocking
• Ne jamais bloquer les ressources JS/CSS dans le robots.txt
• Auditer régulièrement le Coverage JS pour supprimer le code inutilisé