TBT vs INP : comprendre la différence et prioriser les optimisations JavaScript

Beaucoup d’équipes front-end optimisent le TBT comme s’il s’agissait de l’INP, et inversement, sans comprendre que ces deux métriques mesurent des phénomènes différents sur des périmètres distincts. Résultat : des investissements lourds sur l’une des métriques sans amélioration mesurable sur l’autre, et un sentiment général d’inefficacité des optimisations JavaScript. Pourtant, la distinction entre Total Blocking Time et Interaction to Next Paint est structurante pour prioriser correctement les chantiers techniques. Cet article détaille les différences, les liens, et surtout une méthodologie claire pour arbitrer les priorités d’optimisation en 2026. Images, polices et scripts tiers : les 3 goulots qui tuent le LCP en 2026

À retenir en 30 secondes : le TBT mesure le temps total pendant lequel le thread principal est bloqué entre FCP et TTI, uniquement pendant le chargement initial. L’INP mesure la latence réelle d’interaction utilisateur, mesurée sur la pire interaction d’une session. Un bon TBT ne garantit pas un bon INP (interactions post-chargement peuvent être lourdes), et un INP correct peut coexister avec un TBT dégradé (si l’utilisateur n’interagit pas pendant le blocage initial). Les optimisations se recouvrent partiellement mais pas totalement.

Qu’est-ce que le TBT (Total Blocking Time) exactement ?

Le Total Blocking Time mesure la somme des durées pendant lesquelles le thread principal du navigateur est bloqué par une tâche longue (plus de 50ms) entre le First Contentful Paint (FCP) et le Time to Interactive (TTI). Il reflète le niveau de « gel » perçu pendant la phase de chargement initial. Un TBT élevé signale que la page affiche du contenu mais ne peut pas répondre immédiatement aux interactions utilisateur. Le seuil « bon » se situe sous 200ms, le seuil « à améliorer » entre 200 et 600ms, et au-dessus la métrique est jugée mauvaise. Le TBT est une métrique de laboratoire (Lighthouse) qui approxime en condition de test le ressenti réel.

Qu’est-ce que l’INP (Interaction to Next Paint) ?

L’Interaction to Next Paint, Core Web Vital officiel depuis mars 2024, mesure la latence d’une interaction utilisateur réelle : clic, tap, pression clavier. L’INP d’une page est la valeur du pire 98e percentile des interactions mesurées sur une session utilisateur, ce qui en fait une métrique très stricte. Le seuil « bon » est sous 200ms, « à améliorer » entre 200 et 500ms, mauvais au-dessus. Contrairement au TBT, l’INP est mesuré en données réelles (RUM via CrUX) et couvre toute la durée de session, pas seulement le chargement. L’INP capte donc des interactions post-chargement qui peuvent échapper totalement au TBT. Pour une plongée technique sur les patterns d’optimisation, voir notre guide d’optimisation INP pour sites React et Vue, et notre analyse de l’INP et son impact sur le classement Google.

Les 4 différences structurantes à ne jamais oublier

Différence 1 — Périmètre temporel. TBT couvre uniquement la phase FCP → TTI. INP couvre toute la session utilisateur. Un formulaire lourd qui se déclenche au scroll à mi-page impactera l’INP mais pas le TBT.

Différence 2 — Nature de la mesure. TBT = métrique de laboratoire reproductible. INP = métrique terrain mesurée sur utilisateurs réels. Un TBT propre en Lighthouse peut cohabiter avec un INP dégradé en production (hardware moyen, connexions variables, interactions complexes).

Différence 3 — Déclencheur. TBT mesure le blocage indépendamment des interactions. INP mesure uniquement les interactions réelles. Une page sans interaction utilisateur n’a pas d’INP (NaN en RUM).

Différence 4 — Agrégation. TBT est une somme (durée totale). INP est le 98e percentile du pire (max observé). L’INP est beaucoup plus sensible aux pics isolés qu’une moyenne.

Comment prioriser entre TBT et INP ?

L’INP est un Core Web Vital officiel qui influence directement le classement. Le TBT ne l’est pas, c’est une métrique de laboratoire approximant la réalité. Priorité claire : INP d’abord. Cela dit, les optimisations qui améliorent le TBT bénéficient souvent à l’INP pendant la phase de hydration (SPAs React/Vue notamment), donc les deux chantiers se recouvrent partiellement. En pratique : commencer par analyser les 10 pires interactions INP en CrUX, les relier aux patterns JS responsables (gros bundles, re-renders, listeners synchrones lourds), puis traiter le TBT comme métrique secondaire pour affiner le temps de boot initial. Pour une approche complète des optimisations CWV, voir notre guide Core Web Vitals LCP, INP et CLS pour le SEO.

Les leviers d’optimisation qui améliorent les deux

Plusieurs patterns bénéficient simultanément au TBT et à l’INP. Le code splitting réduit le bundle initial donc le TBT, et peut éviter des interactions bloquantes qui dégradent l’INP. La fragmentation des tâches longues via scheduler.yield() libère le thread principal pendant le boot (gain TBT) et pendant les interactions post-chargement (gain INP). L’utilisation de startTransition en React 18+ évite les updates urgents inutiles, améliorant les interactions utilisateur. Le virtual scrolling sur les grandes listes évite les blocages initiaux et post-interactions. Pour une méthodologie plus large d’analyse technique, voir notre guide d’analyse des logs serveur SEO qui complète la perspective performance.

Pour la documentation officielle sur les métriques Core Web Vitals, la page de référence web.dev reste la source la plus fiable.

Mon point de vue d’expert

En audit CWV, je rencontre régulièrement des équipes qui ont passé des mois à optimiser le TBT via Lighthouse sans voir leur INP CrUX bouger. L’erreur méthodologique est de considérer le TBT comme un proxy fiable de l’INP, alors que ces métriques se recouvrent à peine 60 à 70% dans les cas typiques. Mon conseil pour les agences SEO technique : instrumentez d’abord l’INP en RUM sur le site, identifiez les 10 pires interactions réelles, et travaillez spécifiquement sur ces 10 cas. Vous obtiendrez des gains INP mesurables bien plus rapidement qu’en optimisant globalement le TBT à l’aveugle. Et gardez en tête : l’INP est ce qui compte pour Google. Le TBT est utile mais secondaire.

FAQ — TBT vs INP

Le TBT est-il un Core Web Vital ?

Non. Le TBT est une métrique Lighthouse utile pour approximer en laboratoire l’INP, mais ce n’est pas un Core Web Vital officiel et il n’influence pas directement le classement Google. Les Core Web Vitals officiels en 2026 sont LCP, INP et CLS.

Peut-on avoir un bon INP et un mauvais TBT ?

Oui, c’est fréquent sur les sites avec un boot lourd (gros bundle initial) mais des interactions simples par la suite. L’inverse existe aussi : TBT acceptable mais INP mauvais si une interaction utilisateur post-chargement déclenche un recalcul lourd (filtre de catalogue, modal complexe). Les deux métriques ne mesurent pas la même chose, les écarts sont normaux.

Comment mesurer l’INP en laboratoire ?

L’INP ne se mesure pas directement en laboratoire car il dépend des interactions utilisateur réelles. Lighthouse propose depuis 2024 une approximation en simulant quelques interactions, mais la seule mesure fiable passe par les données RUM (Real User Monitoring) via CrUX, Google Search Console, ou une solution tierce (SpeedCurve, DebugBear, web-vitals.js intégré).

Quelles pages sont les plus affectées par l’INP ?

Les pages avec beaucoup d’interactivité : catalogues avec filtres, applications SPA, formulaires longs, tableaux interactifs, pages avec vidéo/galerie, dashboards. Les pages purement éditoriales (article de blog sans interaction au-delà du scroll) sont généralement moins exposées à des problèmes INP, car l’utilisateur interagit peu avec le DOM.