Frameworks JavaScript : le coût caché pour vos Core Web Vitals (2026)

Chaque semaine, un prospect me montre un site tout neuf, propre, animé, construit sur le dernier framework à la mode, et me pose la même question : pourquoi Google ne le fait pas remonter ? La réponse est presque toujours la même. Le site est beau, mais il est lourd. Et en 2026, la lourdeur a un prix, mesuré au millième de seconde par l'INP.

Mis à jour le 2 novembre 2026 · 8 min de lecture

Ce que l'INP mesure vraiment (et pourquoi c'est devenu le point faible des frameworks)

Depuis mars 2024, l'INP (Interaction to Next Paint) a remplacé le FID dans les Core Web Vitals. La nuance est énorme. Le FID ne mesurait que le délai de la toute première interaction. L'INP, lui, regarde la latence de la plupart des interactions sur toute la vie de la page : chaque clic, chaque frappe au clavier, du premier au dernier. Un bon score, c'est 200 millisecondes ou moins.

Le problème, c'est que l'INP dépend presque entièrement d'une seule chose : la quantité de JavaScript qui tourne sur le thread principal du navigateur. Et c'est exactement là que les frameworks pèsent. La documentation Aurora de Chrome est claire sur le mécanisme : l'INP corrèle fortement avec le Total Blocking Time mesuré en labo, c'est-à-dire le temps pendant lequel le navigateur est trop occupé à exécuter du code pour répondre au doigt de l'internaute.

Les chiffres que Google ne met pas en avant

Chrome publie, à partir des données terrain CrUX, la part de sites qui passent l'INP par framework. Les écarts sont parlants, surtout sur mobile, là où les processeurs sont plus lents et où se joue la majorité du trafic.

Deux précautions avant d'en tirer des conclusions, et Chrome les pose lui-même. Ces chiffres ne reflètent que l'INP, pas la qualité globale d'un framework. Et ils incluent beaucoup de vieilles versions mal configurées. Un Next.js récent, bien tenu, passe l'INP sans difficulté. Un Next.js monté par-dessus trois librairies d'animation et une poignée de scripts tiers, non. Le framework n'est pas le coupable. L'usage qu'on en fait l'est.

Pourquoi un site peut ranker quand même, un temps

Je préfère être honnête : les Core Web Vitals sont un signal de classement mineur. Un contenu excellent sur un site lent peut très bien ranker. Mais c'est un départage. À contenu équivalent, le site rapide gagne. Et surtout, la vitesse se paie ailleurs que dans le classement : sur le taux de rebond, sur le taux de conversion, sur la part d'internautes qui abandonnent avant même d'avoir vu votre offre. J'ai détaillé cet angle dans mon article sur la vitesse d'un site web.

Les 5 correctifs que j'applique, dans l'ordre

1. Mesurer sur le terrain, pas en labo

Un score Lighthouse à 95 ne dit presque rien de l'INP réel. Lighthouse mesure un chargement, pas des interactions. Je commence toujours par les données CrUX (PageSpeed Insights, onglet terrain) et par la Search Console, qui remonte l'INP réel de vos visiteurs. Si vous n'avez pas de données terrain, c'est que le trafic est trop faible pour que Google en ait : dans ce cas, je simule avec le panneau Performance de Chrome en throttling CPU x4.

2. Réduire le JavaScript envoyé

Le JavaScript le plus rapide est celui qu'on n'envoie pas. J'audite le bundle, je repère les librairies lourdes (un gros carrousel, une librairie de dates complète pour afficher une seule date, une solution d'animation sur toute la page) et je les remplace par du natif ou par rien. C'est la mesure qui a le plus d'impact, loin devant les autres.

3. Alléger l'hydratation

C'est le coeur du sujet avec les frameworks. L'idée : ne pas tout rendre interactif d'un coup. Les approches modernes (hydratation par îlots, composants serveur, rendu partiel) n'hydratent que ce qui en a besoin. Côté React, la doc de Chrome recommande useTransition pour que le rendu non urgent cède la place aux clics et aux frappes. Côté Angular, le chantier des applications zoneless et de l'hydratation par îlots va dans le même sens.

4. Découper les tâches longues

Une tâche JavaScript de plus de 50 ms bloque le thread principal. On la casse en morceaux, on repousse le travail non essentiel en idle ou dans un web worker, et on arrête de tout empaqueter dans une seule frame. Le préchargement synchrone des routes d'une SPA est un piège classique : il concentre un rendu coûteux dans une seule image et fait exploser l'INP.

5. Discipliner les scripts tiers

Les tags marketing, les chats, les pixels, les outils d'A/B testing mal intégrés sont souvent la vraie cause. Ils tournent sur le même thread principal que vos interactions. Je les charge en différé, je supprime les doublons, et je refuse les outils qui n'acceptent pas un chargement asynchrone.

Ce qu'un outil de mesure seul ne vous dira jamais

Un rapport PageSpeed vous donne un score et une liste de correctifs génériques. Il ne vous dit pas lesquels valent l'effort sur VOTRE site, ni comment les appliquer sans casser le design, ni comment arbitrer entre une animation que le client adore et les 300 ms qu'elle coûte. C'est tout le travail d'un audit technique : relier la mesure à des décisions. C'est ce que je fais dans mes missions de SEO technique, et quand le problème vient de la structure même du site, dans l'accompagnement création de site web. Sur un site repris en cours de route, souvent généré trop vite, je commence par l'audit que je détaille ici.

Écrit par

Charles-Henry Soulet

Fondateur de Treelink, consultant SEO, GEO et CRO. J'accompagne des PME et des e-commerçants sur leur visibilité organique et dans les moteurs de réponse IA.

Voir le profil · LinkedIn