JavaScript est-il vraiment le pire ennemi des Core Web Vitals ?

Pourquoi JavaScript coûte-t-il plus cher que les images ou vidéos ?

La réponse tient à la chaîne de traitement que le navigateur doit exécuter. Une image, même lourde, est simplement décodée et affichée. JavaScript, lui, doit être téléchargé, parsé en bytecode, compilé en code machine, puis exécuté ligne par ligne.

Chacune de ces étapes consomme du temps CPU et bloque le thread principal du navigateur. Pendant ce blocage, aucune interaction utilisateur n'est traitée, aucun rendu visuel n'est mis à jour. C'est précisément ce qui détruit les Core Web Vitals.

Comment JavaScript impacte-t-il concrètement LCP, FID et CLS ?

Pour le LCP (Largest Contentful Paint), JavaScript retarde l'affichage du contenu principal si celui-ci dépend d'un rendu côté client. Un bundle de 500 Ko peut facilement ajouter 2 à 3 secondes avant que le hero ne soit visible.

Le FID (First Input Delay) mesure la réactivité. Si un script lourd s'exécute au moment où l'utilisateur clique, l'interaction est mise en file d'attente. Résultat : un délai perçu comme un freeze, pénalisant directement le score.

Le CLS (Cumulative Layout Shift) explose quand JavaScript injecte du contenu dynamiquement sans réserver l'espace nécessaire. Les frameworks modernes sont particulièrement coupables ici : hydratation React, lazy loading mal configuré, ads insérées après le chargement.

Martin Splitt exagère-t-il le problème ou reflète-t-il une réalité terrain ?

La déclaration est factuelle mais volontairement dramatisée. JavaScript est effectivement l'asset le plus coûteux en termes de traitement CPU. Mais comparer JS et vidéo en termes absolus est trompeur : une vidéo de 50 Mo pèse plus lourd en bande passante qu'un bundle de 300 Ko.

Ce que Splitt veut dire, c'est que le coût par octet de JavaScript est disproportionné. Un Ko de JS peut bloquer le thread pendant 10 ms sur mobile bas de gamme, là où un Ko d'image se décode en 1 ms. Cette nuance est capitale pour comprendre où concentrer les efforts d'optimisation.

• JavaScript bloque le thread principal pendant son parsing et son exécution, contrairement aux autres assets
• LCP est directement affecté si le contenu critique dépend de JS côté client
• FID se dégrade proportionnellement au temps d'exécution des scripts lourds
• CLS augmente quand JavaScript injecte du contenu sans réserver l'espace DOM nécessaire
• Le coût par octet de JavaScript est 10 à 20 fois supérieur à celui des images sur mobile

Cette déclaration reflète-t-elle ce qu'on observe sur le terrain ?

Absolument. Les audits PageSpeed sur des sites React, Vue ou Angular montrent systématiquement des scores inférieurs à 50 sur mobile sans optimisation spécifique. Le pattern est toujours le même : Total Blocking Time au-dessus de 1 seconde, LCP qui dépasse 4 secondes, FID catastrophique.

Les sites WordPress avec Elementor ou Divi, qui injectent 700 Ko de JS pour afficher un simple slider, explosent littéralement les Core Web Vitals. Les e-commerces Shopify ou PrestaShop souffrent du même problème : chaque plugin ajoute son propre bundle sans coordination globale.

Quelles nuances faut-il apporter à cette affirmation ?

Première nuance : tout JavaScript n'est pas égal. Un script de 50 Ko exécuté en 20 ms n'aura pas le même impact qu'un script de 50 Ko exécuté en 300 ms. La complexité algorithmique compte autant que la taille du fichier.

Deuxième nuance : le timing d'exécution est déterminant. JavaScript chargé en defer ou async, après le First Paint, impacte moins LCP et FID qu'un script synchrone bloquant dans le . Martin Splitt ne précise pas ce point, mais c'est crucial pour prioriser les optimisations. [A vérifier] : Google ne fournit aucune donnée quantitative sur le seuil acceptable de JavaScript par page.

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

Sur des applications web interactives (Google Docs, Figma, Gmail), JavaScript est incontournable et constitue la valeur ajoutée principale. Ici, le compromis est acceptable si l'expérience utilisateur justifie la charge.

Les sites qui utilisent du Server-Side Rendering (Next.js, Nuxt) ou du Static Site Generation contournent en partie le problème : le HTML initial est déjà rendu, JavaScript n'intervient que pour l'hydratation interactive. Le LCP reste correct, seul le FID peut souffrir pendant l'hydratation.

Que faut-il faire concrètement pour réduire l'impact JavaScript ?

Premier levier : auditer le JavaScript critique avec Coverage Tool dans Chrome DevTools. Identifiez le code réellement exécuté au chargement versus le code mort ou différable. Sur la majorité des sites, 60 à 80 % du JS initial est inutile au First Paint.

Deuxième levier : code splitting et lazy loading agressif. Chargez uniquement le bundle nécessaire à la page actuelle, différez tout le reste. Webpack, Rollup et Vite offrent des configs natives pour cela. Sur un e-commerce, le JS du tunnel de commande n'a rien à faire sur la homepage.

Troisième levier : migration vers du SSR ou SSG quand c'est possible. Next.js, Nuxt, SvelteKit permettent de rendre le HTML côté serveur et d'hydrater progressivement. Le gain sur LCP est immédiat, souvent 1 à 2 secondes sur mobile 3G.

Quelles erreurs éviter absolument ?

Ne chargez jamais de bibliothèque JavaScript lourde (Lodash, Moment.js) pour utiliser une seule fonction. Préférez des imports ciblés ou des alternatives légères (date-fns, day.js). Un bundle qui passe de 400 Ko à 150 Ko peut diviser le TBT par deux.

Évitez les render-blocking scripts dans le sans attribut defer ou async. Chaque script synchrone bloque le parsing HTML et retarde le First Paint. jQuery chargé en haut de page reste une plaie courante sur les sites legacy.

Comment vérifier que mon site respecte les recommandations Google ?

Utilisez PageSpeed Insights et Lighthouse pour mesurer TBT (Total Blocking Time), qui corrèle directement avec FID. Un TBT inférieur à 200 ms est acceptable, au-dessus de 600 ms vous êtes en zone rouge.

Activez le throttling CPU 4x dans Chrome DevTools pour simuler un mobile bas de gamme. Si votre site devient inutilisable, c'est que JavaScript est le goulot d'étranglement principal. WebPageTest avec un profil Moto G4 sur 3G lent donne une vision réaliste de l'expérience utilisateur.

• Auditer le JS critique avec Coverage Tool et supprimer le code mort
• Mettre en place du code splitting et lazy loading sur tous les bundles non critiques
• Migrer vers SSR/SSG pour les pages à fort trafic (homepage, catégories, fiches produits)
• Remplacer les bibliothèques lourdes par des alternatives légères ou du code vanilla
• Différer ou async tous les scripts tiers (analytics, tag managers, A/B testing)
• Mesurer TBT et FID en conditions réelles avec PageSpeed Insights et CrUX