Can you really have a good FID while suffering from catastrophic TTI?

How can a good FID coexist with a disastrous TTI?

First Input Delay measures only the delay between the user's first interaction (click, tap) and the browser's response. It’s a snapshot metric, captured at the precise moment when the user acts for the first time on the page.

Time to Interactive and Total Blocking Time, on the other hand, evaluate the availability of the main thread over a much wider time window. TTI measures the time before the page becomes fully interactive and stable for at least 5 seconds. TBT adds up all main thread blocking events longer than 50ms between FCP and TTI.

The paradox occurs when the user interacts during a brief window of thread availability — thus achieving an excellent FID — while the rest of the loading remains plagued by heavy scripts that intermittently block the thread. FID captures only a moment; TTI/TBT scrutinize the entire loading period.

What does

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.