Peut-on avoir un bon FID avec un TTI catastrophique ?

Pourquoi un bon FID peut-il coexister avec un TTI désastreux ?

Le First Input Delay mesure uniquement le délai entre la première interaction utilisateur (clic, tap) et la réponse du navigateur. C'est une métrique ponctuelle, capturée au moment précis où l'utilisateur agit pour la première fois sur la page.

Time to Interactive et Total Blocking Time, eux, évaluent la disponibilité du thread principal sur une fenêtre temporelle beaucoup plus large. TTI mesure le temps avant que la page devienne pleinement interactive et stable pendant au moins 5 secondes. TBT additionne tous les blocages du thread principal supérieurs à 50ms entre FCP et TTI.

Le paradoxe survient quand l'utilisateur interagit pendant une courte fenêtre de disponibilité du thread — obtenant ainsi un FID excellent — alors que le reste du chargement reste pollué par des scripts lourds qui bloquent le thread de manière intermittente. FID ne capture qu'un instant ; TTI/TBT scrutent toute la période de chargement.

Que signifie concrètement « blocages intermittents du thread principal » ?

Imagine une page où un script lourd s'exécute par vagues : 200ms de blocage, puis 100ms de respiration, puis 300ms de blocage, etc. Si l'utilisateur clique pendant une de ces fenêtres de respiration, FID sera quasi nul — excellent score Core Web Vitals.

Mais du point de vue de TTI, la page n'est pas stable : elle reste bloquée par intermittence. TBT additionnera tous ces pics, aboutissant à un score médiocre voire catastrophique. Les outils lab (Lighthouse, PageSpeed Insights en mode lab) détectent ces patterns ; FID en RUM (Real User Monitoring) ne capture qu'une fraction de la réalité.

C'est typiquement le cas avec des librairies qui s'exécutent en chunks asynchrones, des trackers analytics mal optimisés, ou des frameworks JavaScript qui hydratent progressivement le DOM par morceaux.

Dans quels cas faut-il vraiment s'inquiéter ?

Si tes données CrUX (Chrome User Experience Report) montrent un bon FID field mais que tes audits Lighthouse affichent un TTI/TBT rouge, deux scénarios possibles. Premier cas : ton trafic réel interagit principalement dans les fenêtres de disponibilité du thread — ton FID est bon parce que tes utilisateurs ont de la chance. Deuxième cas : c'est un artefact de mesure.

Martin Splitt dit explicitement : si l'expérience utilisateur réelle reste bonne malgré des métriques contradictoires, il peut s'agir d'un edge case des outils. Autrement dit : les métriques mentent parfois. L'enjeu est de déterminer si c'est un vrai problème d'UX ou un problème de mesure.

• FID mesure un instant : la première interaction utilisateur, pas la stabilité générale du thread principal.
• TTI et TBT scrutent toute la période de chargement : ils détectent les blocages intermittents que FID peut manquer.
• Un bon FID avec un mauvais TTI/TBT signale souvent des scripts lourds qui s'exécutent par vagues, créant des fenêtres de disponibilité aléatoires.
• Si l'UX réelle est bonne, il peut s'agir d'une limite technique des outils de mesure — à remonter à l'équipe Lighthouse.
• Ne jamais se fier à une seule métrique pour diagnostiquer un problème de performance : croiser field data (CrUX) et lab data (Lighthouse) est essentiel.

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

Absolument. On observe régulièrement ce pattern sur des sites e-commerce ou médias qui chargent des trackers analytics, des bannières publicitaires ou des widgets tiers de manière asynchrone. Le FID field reste bon parce que l'utilisateur moyen clique pendant une fenêtre de disponibilité, mais Lighthouse hurle au rouge sur TTI/TBT parce que le thread principal est pollué par intermittence.

Ce qui est intéressant, c'est que Google reconnaît ouvertement que les métriques peuvent mentir — ou du moins ne pas refléter l'expérience réelle. C'est rare de voir une admission aussi directe que « il peut s'agir d'un edge case des outils de mesure ». Cela valide ce que beaucoup de praticiens suspectaient : les Core Web Vitals ne sont pas infaillibles.

Attention toutefois : ce n'est pas un blanc-seing pour ignorer TTI/TBT. Si tes données CrUX montrent un FID stable et bon sur 28 jours, mais que Lighthouse reste rouge, creuse. Peut-être que ton trafic réel est mobile léger (interactions tardives, après stabilisation du thread), tandis que ton audit lab simule un desktop rapide (interaction précoce, pendant les blocages). [A vérifier] : Google ne précise pas si ce pattern est plus fréquent sur mobile ou desktop, ni s'il y a une corrélation avec des frameworks JS spécifiques.

Quelles nuances faut-il apporter à cette déclaration ?

Martin Splitt dit « si l'expérience utilisateur réelle est bonne ». Mais comment mesurer cette « bonne expérience » de manière objective ? FID seul ne suffit pas — c'est précisément le sujet de la déclaration. Interaction to Next Paint (INP) est censé mieux capturer la réactivité globale, mais il n'était pas encore Core Web Vital au moment de cette déclaration.

Deuxième nuance : « remonter le cas à l'équipe Lighthouse » est un conseil valable, mais combien de SEO vont vraiment le faire ? En pratique, si ton FID field est bon et que tes utilisateurs ne se plaignent pas, tu vas probablement ignorer le TTI/TBT lab. C'est pragmatique, mais risqué : un changement de pattern de trafic (plus d'interactions précoces) pourrait faire basculer ton FID field dans le rouge du jour au lendemain.

Enfin, cette déclaration date d'une époque où FID était encore la métrique Core Web Vital de référence pour l'interactivité. Depuis mars 2024, INP a remplacé FID. Le paradoxe FID/TTI est donc partiellement résolu — INP mesure toutes les interactions, pas seulement la première. Mais le principe reste valable : les métriques lab et field peuvent diverger, et il faut croiser les deux pour diagnostiquer correctement.

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

Si ton FID field est mauvais ET ton TTI/TBT lab est mauvais, pas de débat : tu as un vrai problème de performance. Les deux sources de données convergent — le thread principal est saturé, et l'expérience utilisateur en souffre. Pas d'edge case métrique ici, juste du JavaScript mal optimisé.

De même, si ton FID field est bon mais que tes métriques business (taux de rebond, taux de conversion, temps d'engagement) sont médiocres, ne te cache pas derrière un « edge case Lighthouse ». L'utilisateur peut techniquement interagir rapidement, mais si le contenu ou l'interface est décevant, FID ne sauvera rien. Les Core Web Vitals ne mesurent pas l'utilité ou la pertinence du contenu — ils mesurent la performance technique.

Enfin, sur des SPA (Single Page Applications) complexes avec hydratation progressive, ce pattern FID bon / TTI mauvais est presque systématique. Ce n'est pas un edge case, c'est un pattern architectural. Si tu as un Next.js ou un Nuxt avec Server-Side Rendering + hydratation client lourde, tu vas forcément avoir un TTI élevé. L'enjeu est alors d'optimiser le code splitting et le lazy loading, pas de chercher un bug Lighthouse.

Comment diagnostiquer correctement ce pattern FID/TTI contradictoire ?

Première étape : croiser field data et lab data. Vérifie ton FID dans CrUX (via PageSpeed Insights, Search Console, ou BigQuery) sur 28 jours. Compare avec un audit Lighthouse récent sur la même URL. Si FID field est vert et TTI/TBT lab est rouge, tu es potentiellement dans le cas décrit par Martin Splitt.

Deuxième étape : analyser les traces de performance en DevTools. Ouvre Chrome DevTools > Performance, enregistre un chargement complet, et scrute le main thread. Cherche des patterns de blocage intermittent : des pics lourds (>50ms) espacés de fenêtres de disponibilité. Si tu vois ce pattern, c'est probablement ce qui explique le paradoxe.

Troisième étape : tester sur des devices et connexions variés. Un FID bon sur desktop 4G peut devenir catastrophique sur mobile 3G. Utilise WebPageTest avec des profils de throttling différents. Si le pattern FID/TTI reste contradictoire sur tous les profils, c'est plus probablement un edge case métrique. Si ça diverge selon le device, c'est un vrai problème de performance contextuel.

Que faire concrètement si tu es dans ce cas de figure ?

Si ton FID field est bon et que l'expérience utilisateur réelle ne montre aucun signe de dégradation (taux de rebond stable, conversion normale, pas de plaintes), tu peux considérer que le TTI/TBT lab est un faux positif. Mais ne t'arrête pas là : ouvre un ticket sur le repo GitHub de Lighthouse en documentant ton cas avec des screenshots, des traces de performance, et des liens CrUX.

En parallèle, optimise quand même ton JavaScript. Même si FID est bon aujourd'hui, un changement de comportement utilisateur (interactions plus précoces) ou une évolution du code (ajout d'un nouveau tracker) pourrait faire basculer FID dans le rouge. Code splitting, lazy loading des scripts non critiques, defer ou async sur les tiers — les classiques. L'objectif est de réduire les blocages intermittents du thread principal, même s'ils ne pénalisent pas encore FID.

Enfin, si tu es sur un site complexe avec des enjeux business forts, monitore INP (Interaction to Next Paint) même si FID reste ta métrique Core Web Vital actuelle. INP capture mieux la réactivité globale et détecte les problèmes que FID peut manquer. Si INP est bon ET FID est bon, tu es probablement safe. Si INP est rouge, creuse — tu as un vrai problème d'interactivité.

Quelles erreurs éviter dans ce contexte ?

Erreur n°1 : ignorer TTI/TBT sous prétexte que FID est bon. Même si c'est un edge case métrique, les blocages intermittents du thread principal dégradent l'expérience utilisateur de manière subtile — scrolling saccadé, animations qui lag, formulaires qui répondent mal. FID ne capture qu'un instant ; l'utilisateur vit toute la session.

Erreur n°2 : sur-optimiser pour Lighthouse au détriment de l'UX réelle. Si ton FID field est bon, ne casse pas ton architecture juste pour faire passer TTI lab au vert. Lighthouse simule des conditions lab qui ne reflètent pas toujours ton trafic réel. Priorise les optimisations qui améliorent l'expérience terrain, pas juste le score Lighthouse.

Erreur n°3 : ne pas documenter et remonter les edge cases. Si tu es convaincu que c'est un bug ou une limite des outils de mesure, aide l'équipe Lighthouse à améliorer leurs métriques en documentant ton cas. Plus il y a de cas remontés, plus les outils s'affinent — c'est dans l'intérêt de tout l'écosystème.

• Croiser systématiquement CrUX (field data) et Lighthouse (lab data) avant de tirer des conclusions.
• Analyser les traces de performance en DevTools pour identifier les blocages intermittents du thread principal.
• Tester sur devices et connexions variés (mobile 3G, desktop 4G, etc.) pour contextualiser les résultats.
• Monitore INP en complément de FID pour capturer la réactivité globale, pas seulement la première interaction.
• Optimiser le JavaScript (code splitting, lazy loading, defer/async) même si FID field est bon, pour anticiper les changements de comportement utilisateur.
• Documenter et remonter les edge cases à l'équipe Lighthouse via GitHub si l'expérience réelle contredit les métriques lab.