Un bundle JavaScript de 2,7 Mo peut-il vraiment passer sans problème chez Google ?

Pourquoi Google fixe-t-il un seuil à 10 Mo pour le JavaScript ?

Google traite les pages en deux temps : crawl initial puis rendu JavaScript. Ce second passage mobilise des ressources conséquentes — CPU, mémoire, bande passante. Un bundle de 2,7 Mo reste dans l'enveloppe que Googlebot peut traiter sans ralentissement notable.

Le seuil de 10 Mo correspond à la limite où le coût de traitement devient suffisamment élevé pour impacter le crawl budget. Au-delà, le risque d'échec de rendu ou de timeout augmente significativement. Google ne bloque pas forcément la page, mais la probabilité que tout le contenu soit correctement indexé diminue.

Cette tolérance signifie-t-elle qu'on peut se relâcher sur l'optimisation ?

Non. Indexation acceptable ne signifie pas performance acceptable. Un bundle de 2,7 Mo met plusieurs secondes à charger sur mobile 3G, dégrade les Core Web Vitals, et plombe l'expérience utilisateur. Google indexera peut-être votre contenu, mais vos utilisateurs partiront avant de le voir.

Le tree-shaking (élimination du code mort) et le code-splitting (découpage en chunks) restent essentiels. Pas pour Googlebot — pour vos visiteurs. La différence entre 2,7 Mo et 400 Ko bien splitté, c'est un taux de rebond qui explose ou non.

Comment Google mesure-t-il réellement ces 2,7 Mo ?

On parle ici du bundle total téléchargé, compressé ou non selon le contexte. Google regarde la somme des fichiers JS que le navigateur doit récupérer pour rendre la page complètement. Les frameworks modernes (React, Vue, Angular) génèrent facilement des bundles de cette taille sans optimisation.

La déclaration ne précise pas si c'est en gzip, brotli ou décompressé. [À vérifier] — cette ambiguïté compte. Un fichier de 2,7 Mo décompressé peut peser 600 Ko en brotli. La différence est colossale pour le temps de transfert, moins pour le parsing côté moteur.

• 2,7 Mo ne bloque pas l'indexation mais n'est pas une cible à viser.
• 10 Mo constitue la zone rouge où les problèmes deviennent concrets.
• L'optimisation sert d'abord l'utilisateur, pas le crawler.
• Tree-shaking et code-splitting réduisent drastiquement la charge initiale.
• La compression (brotli > gzip) peut diviser le poids par 4-5 sans toucher au code.

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

Oui et non. Sur des sites e-commerce avec React lourd et mal optimisé, on observe que Google indexe bien les contenus même avec des bundles de 2-3 Mo. Le contenu apparaît dans la Search Console, les pages remontent dans les SERPs. Pas de blocage brutal.

En revanche, la vitesse d'indexation et la fraîcheur du contenu sont clairement impactées. Les sites avec des bundles légers (< 500 Ko) voient leurs nouvelles pages indexées en quelques heures. Avec 2,7 Mo, ça peut prendre plusieurs jours. Le crawl budget n'est pas infini, et Google priorise ce qui se digère vite.

Quelles nuances faut-il apporter à ce seuil de 10 Mo ?

Le chiffre de 10 Mo n'est pas une garantie contractuelle. C'est une indication générale basée sur l'infrastructure Google actuelle. Sur un site avec un crawl budget déjà serré (millions de pages, faible autorité), même 5 Mo peuvent poser problème.

Autre point : le temps de parsing et d'exécution compte autant que le poids brut. Un bundle de 1 Mo mal écrit, avec des boucles infinies ou du code bloquant, peut faire crasher le renderer. À l'inverse, 3 Mo bien structurés avec du lazy-loading passent sans accroc. [À vérifier] — Google ne dit rien sur la qualité du code, uniquement sur le volume.

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

Les Single Page Applications (SPA) pures posent un défi spécifique. Si tout le contenu dépend du JS pour s'afficher, un bundle lourd retarde l'indexation de toutes les pages. Le SSR (Server-Side Rendering) ou le SSG (Static Site Generation) contournent le problème en livrant du HTML pré-rendu.

Les sites avec JavaScript critique non différé subissent aussi un impact disproportionné. Si vos 2,7 Mo bloquent le rendu initial (scripts synchrones dans le <head>), Google attend que tout soit téléchargé avant de voir quoi que ce soit. Résultat : timeout ou rendu partiel.

Que faut-il faire concrètement si votre bundle dépasse 1 Mo ?

Première étape : auditer avec Webpack Bundle Analyzer ou équivalent (Rollup Visualizer, Parcel Bundle Buddy). Identifiez les librairies qui pèsent lourd sans raison valable. Moment.js (230 Ko) peut être remplacé par date-fns (10 Ko). Lodash entier (70 Ko) vs imports ciblés (5 Ko par fonction).

Ensuite, activez le code-splitting. Chargez uniquement le JS nécessaire à la page courante. Les routes dynamiques, les modales, les widgets non critiques doivent être en lazy-load. React.lazy() et dynamic imports vous donnent ce levier sans refonte majeure.

Quelles erreurs éviter pour rester sous les radars de Google ?

Ne concentrez pas tout le JS dans un unique bundle monolithique. Même 2,7 Mo en un seul fichier, c'est pire que 3 Mo répartis en 6 chunks de 500 Ko chacun. Google et les navigateurs gèrent mieux les petits fichiers parallélisés.

Évitez aussi les scripts synchrones bloquants. Si votre bundle principal est en <script src="app.js"> sans defer ni async, vous bloquez le parsing HTML. Googlebot moderne gère mieux le defer, mais autant ne pas compliquer.

Comment vérifier que votre site reste dans la zone verte ?

Utilisez Google Search Console → Inspection d'URL et demandez un rendu en direct. Comparez le HTML brut au HTML rendu. Si des sections entières manquent, c'est que le JS pose problème. Les logs côté serveur montrent aussi si Googlebot redemande plusieurs fois les mêmes ressources JS (signe de timeout).

Testez avec WebPageTest sur mobile 3G simulé. Si votre Time to Interactive dépasse 10 secondes, peu importe que Google indexe : vos utilisateurs ne verront jamais le contenu. Le PageSpeed Insights officiel donne aussi une estimation du poids JS et des opportunités d'optimisation.

• Auditez votre bundle avec Webpack Bundle Analyzer ou équivalent.
• Activez le code-splitting et le lazy-loading sur les routes non critiques.
• Passez en defer ou async pour tous les scripts non bloquants.
• Testez le rendu avec Google Search Console → Inspection d'URL.
• Mesurez le Time to Interactive réel sur mobile 3G avec WebPageTest.
• Remplacez les librairies lourdes par des alternatives légères quand c'est possible.