Peut-on avoir d'excellentes Core Web Vitals tout en ayant un site techniquement défaillant ?

Pourquoi ces trois métriques peuvent-elles diverger aussi radicalement ?

Le First Input Delay mesure le temps de réponse à la première interaction utilisateur — un clic, un tap, une saisie. C'est une métrique très ciblée, qui capture un instant T : le moment où l'utilisateur veut agir et où le navigateur répond.

Le Time to Interactive et le Total Blocking Time, eux, balayent une fenêtre temporelle beaucoup plus large. Le TTI attend que la page soit complètement stable et réactive pendant 5 secondes consécutives. Le TBT additionne tous les longs blocs de tâches JavaScript qui auraient pu bloquer l'interface entre le First Contentful Paint et le TTI.

Concrètement ? Un script lourd qui s'exécute après que l'utilisateur a cliqué — par exemple un SDK analytics, un widget de chat, un script de tracking publicitaire — va plomber le TTI et le TBT sans toucher au FID. L'utilisateur a déjà interagi, le navigateur a répondu rapidement, le FID est excellent. Mais techniquement, la page reste instable pendant plusieurs secondes à cause de ces blocs JS asynchrones.

Google dit que « l'expérience utilisateur réelle est bonne » — qu'est-ce que ça signifie vraiment ?

Google fait ici référence aux données terrain du Chrome User Experience Report (CrUX), qui agrègent les métriques mesurées sur de vrais navigateurs, dans de vraies conditions réseau, avec de vrais utilisateurs. Si ton FID CrUX est vert, c'est que tes visiteurs réels ne rencontrent pas de latence perceptible quand ils interagent.

Le piège, c'est que Lighthouse — qui tourne en labo, dans un environnement contrôlé — peut t'afficher un TTI catastrophique et un TBT rouge vif, alors que tes utilisateurs ne s'en rendent même pas compte. Pourquoi ? Parce que Lighthouse simule un CPU 4x plus lent et un réseau 3G, et qu'il exécute tous les scripts dans une séquence linéaire. Dans la vraie vie, un CPU moderne digère ces blocs JS en parallèle, et l'utilisateur a déjà scrollé ou cliqué avant que le dernier widget ait fini de se charger.

Faut-il ignorer le TTI et le TBT si le FID est bon ?

Non. Mais il faut contextualiser. Si ton FID CrUX est excellent et que tes utilisateurs ne remontent aucune plainte d'interface bloquée, alors oui, un TTI médiocre en labo peut être un faux positif. C'est ce que Martin Splitt appelle un « edge case ».

En revanche, si ton FID est bon mais que ton TTI est catastrophique à cause de blocs JS qui s'exécutent pendant que l'utilisateur scrolle, tu risques des micro-freezes, des animations saccadées, des clics qui ne répondent pas immédiatement. Ce ne sont pas des problèmes de FID — c'est de la réactivité continue, que le FID ne mesure pas. Et ça, ça dégrade l'expérience, même si Lighthouse ne le capture pas parfaitement.

• Le FID mesure la latence d'entrée initiale, pas la fluidité globale de l'interface après le premier clic.
• Le TTI et le TBT capturent la charge CPU pendant la phase de chargement, mais peuvent être trompeurs si les blocs JS surviennent après l'interaction utilisateur.
• Les données CrUX sont la référence — si tes métriques terrain sont bonnes, les scores Lighthouse en labo peuvent être relativisés.
• Un TTI élevé peut signaler un problème réel si l'interface reste bloquée pendant que l'utilisateur interagit — ne l'ignore pas systématiquement.
• Google recommande de signaler ces cas limites à l'équipe Lighthouse pour affiner les modèles de scoring en labo.

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

Absolument. J'ai vu des dizaines de sites afficher un FID CrUX à 100 ms et un TTI Lighthouse à 12 secondes. Le coupable le plus fréquent ? Les scripts tiers — Google Tag Manager qui déclenche 15 tags en cascade, des SDK publicitaires qui parsent le DOM, des widgets de chat qui injectent du HTML dynamique.

Le problème, c'est que ces scripts s'exécutent souvent après que l'utilisateur a scrollé, cliqué sur un lien, ou commencé à lire. Le FID reste excellent parce que le navigateur a répondu à la première interaction avant que le chaos commence. Mais si tu ouvres les DevTools et que tu enregistres une trace de performance, tu vois des blocs de 200-300 ms qui bloquent le thread principal pendant plusieurs secondes. Et ça, Lighthouse le détecte — à raison.

Maintenant, est-ce que ça impacte le ranking ? [À vérifier]. Google dit utiliser les Core Web Vitals (dont le FID, remplacé par l'INP en mars 2024) comme signal de classement, mais on ne sait pas quelle pondération est donnée au TTI ou au TBT. Mon hypothèse — et c'est une hypothèse — c'est que Google agrège plusieurs signaux d'expérience, et qu'un FID excellent peut compenser un TTI médiocre, surtout si les données CrUX montrent une expérience fluide. Mais Google ne le confirme nulle part officiellement.

Quelles nuances faut-il apporter à cette logique ?

Soyons honnêtes : le FID est une métrique limitée. Il mesure uniquement la latence de la première interaction, et il ne capte ni les clics suivants, ni les animations, ni le scroll jank. Google l'a d'ailleurs remplacé par l'Interaction to Next Paint (INP) en 2024, justement parce que le FID était trop permissif.

Donc si tu te reposes uniquement sur le FID pour dire « mon site est rapide », tu passes à côté de la moitié du tableau. Un site peut avoir un FID à 50 ms et un INP à 400 ms si chaque interaction suivante déclenche un re-render lourd ou un fetch API bloquant. Et ça, les utilisateurs le ressentent — même si le FID ne le montre pas.

Autre nuance : le TTI et le TBT sont des métriques de labo, pas de terrain. Elles sont utiles pour diagnostiquer des problèmes de charge CPU, mais elles ne reflètent pas forcément ce que vivent tes utilisateurs avec un CPU moderne, une connexion 4G, et un navigateur qui optimise l'exécution JS en arrière-plan. Si Lighthouse te hurle dessus avec un TTI à 15 secondes mais que ton FID CrUX est à 90 ms, alors oui, c'est probablement un edge case. Mais si ton INP CrUX est dans le rouge, alors ton TTI de labo te raconte une vérité — ton JS est trop lourd.

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

Si ton site est une application web interactive — un SaaS, un éditeur en ligne, un dashboard — alors le TTI et le TBT sont beaucoup plus pertinents. Pourquoi ? Parce que tes utilisateurs ne font pas qu'un seul clic et repartent. Ils interagissent en continu, ils ouvrent des modales, ils remplissent des formulaires, ils déclenche des actions asynchrones.

Dans ce cas, un TTI élevé signale que ton interface reste bloquée pendant plusieurs secondes après le chargement initial, et que chaque interaction suivante risque de se heurter à du JS non résolu. Le FID peut être bon — parce que le premier clic arrive avant le chaos — mais l'expérience globale sera catastrophique. Et là, Lighthouse a raison de te signaler le problème.

Que faut-il faire concrètement si on se retrouve dans cette situation ?

D'abord, priorise les données CrUX. Ouvre la Google Search Console, consulte le rapport Core Web Vitals, et regarde ce que remontent les navigateurs de tes utilisateurs réels. Si ton FID (ou ton INP, depuis 2024) est vert et que tes URL passent le seuil des 75 % de bonnes expériences, alors ton TTI de labo peut attendre.

Ensuite, identifie les blocs JavaScript responsables. Ouvre Lighthouse, déroule la section « Diagnostics », et regarde « Avoid long main-thread tasks ». Tu vas voir une liste de scripts qui bloquent le thread principal. Si ce sont des scripts tiers — analytics, pub, widgets — demande-toi s'ils sont vraiment indispensables au-dessus de la ligne de flottaison. Souvent, ils peuvent être chargés en différé avec un simple defer ou async, voire lazy-loadés après le premier scroll.

Si les blocs JS proviennent de ton propre code — par exemple un framework front-end qui parse un gros état initial — alors là, c'est un chantier d'optimisation classique : code splitting, tree shaking, réduction de la taille du bundle, server-side rendering partiel. Pas de miracle, juste de l'ingénierie.

Quelles erreurs éviter quand on interprète ces métriques ?

Erreur numéro un : confondre les métriques de labo et les métriques terrain. Lighthouse te donne une photo dans des conditions dégradées — CPU lent, réseau lent, pas de cache. C'est utile pour détecter des régressions, mais ce n'est pas la réalité de tes utilisateurs. Les données CrUX, elles, agrègent des millions de sessions réelles. Si Lighthouse te dit rouge et CrUX te dit vert, crois CrUX.

Erreur numéro deux : optimiser pour un score Lighthouse au détriment de l'expérience réelle. J'ai vu des dev supprimer des fonctionnalités utiles — un chat support, un outil de recherche, un carrousel produit — juste pour faire passer le TTI de 8 à 4 secondes. Résultat : le score monte, mais les conversions chutent. Si une fonctionnalité apporte de la valeur et que les utilisateurs ne s'en plaignent pas, garde-la. Optimise-la, oui, mais ne la sacrifie pas.

Erreur numéro trois : ignorer complètement le TTI et le TBT sous prétexte que le FID est bon. Ces métriques capturent une forme de dette technique. Si ton TTI est catastrophique, c'est que ton front-end exécute trop de JS au chargement. Tôt ou tard, ça finira par impacter l'expérience — soit via l'INP, soit via des micro-freezes, soit via une hausse du taux de rebond. Traite ces signaux comme des alertes précoces, pas comme du bruit.

Comment vérifier que mon site n'est pas dans cet edge case ?

Compare tes données CrUX et tes scores Lighthouse. Si ton FID CrUX est < 100 ms et que ton TTI Lighthouse est > 7 secondes, alors oui, tu es probablement dans l'edge case décrit par Martin Splitt. Vérifie ensuite l'INP — si l'INP CrUX est bon aussi (< 200 ms), alors ton site répond bien aux interactions réelles, et le TTI de labo n'est qu'un faux positif partiel.

Maintenant, si ton INP CrUX est dans l'orange ou le rouge, alors ton TTI de labo te raconte une vérité : ton JS bloque l'interface, et tes utilisateurs le ressentent. Dans ce cas, il faut investiguer — ouvre une trace de performance dans Chrome DevTools, enregistre 5-6 secondes de chargement, et identifie les longs blocs. Souvent, c'est un script tiers mal configuré, un bundle JS trop lourd, ou un re-render React inutile.

• Consulter le rapport Core Web Vitals dans la Google Search Console pour voir les données CrUX réelles.
• Comparer le FID/INP terrain avec le TTI/TBT de labo — une divergence forte peut indiquer un edge case.
• Identifier les blocs JavaScript responsables via Lighthouse (section « Avoid long main-thread tasks »).
• Différer les scripts tiers non critiques avec defer, async, ou lazy loading après le premier scroll.
• Surveiller l'INP en plus du FID — c'est lui qui capture la réactivité continue, pas juste la première interaction.
• Si ton TTI reste mauvais malgré un bon FID/INP terrain, signale le cas à l'équipe Lighthouse pour contribuer à l'amélioration des modèles.