FID (First Input Delay)

Le First Input Delay (FID) est un Core Web Vital qui mesure le temps entre la première interaction d'un utilisateur avec une page — cliquer sur un bouton, toucher un lien, appuyer sur une touche — et le moment où le navigateur commence à traiter cet événement. Il capture la réactivité plutôt que la vitesse de chargement visuelle. Un bon score FID est inférieur à 100 millisecondes, ce qui signifie que la page paraît instantanée pour l'utilisateur. Tout ce qui dépasse 300 millisecondes est considéré comme mauvais. Le FID mesure précisément le délai d'entrée causé par le thread principal du navigateur occupé par d'autres tâches, comme l'analyse de JavaScript ou l'exécution de scripts de longue durée. Il ne mesure pas le temps que met le navigateur à finir de traiter l'événement ou à mettre à jour l'interface ensuite.

Lorsqu'un lecteur clique sur un bouton et que rien ne se passe pendant un instant perceptible, la page semble cassée. Une réponse lente aux entrées frustre les utilisateurs et augmente les [taux de rebond](/glossary/bounce-rate). Google a utilisé le FID comme signal de classement au sein de son évaluation des Core Web Vitals, de sorte que les pages avec un mauvais FID peuvent être moins bien classées dans les résultats de recherche. Pour les éditeurs qui partagent des flipbooks et des documents interactifs, une première interaction poussive sape l'impression professionnelle que ton contenu est censé créer. Les utilisateurs mobiles sont particulièrement touchés, car les appareils mobiles ont souvent moins de puissance de traitement, rendant l'encombrement du thread principal plus perceptible.

Les flipbooks FlipLink sont optimisés pour garder un FID bas en différant le JavaScript non critique jusqu'après le rendu initial. Le moteur de feuilletage Three.js se charge progressivement, de sorte que la barre d'outils de la visionneuse et les contrôles de navigation répondent immédiatement lorsqu'un lecteur interagit pour la première fois. Les pixels de suivi et les scripts d'analyse sont chargés de manière asynchrone pour éviter de bloquer le thread principal. Lorsque tu [intègres un flipbook](/glossary/responsive-embed) sur ton propre site web, le code d'intégration de FlipLink utilise le chargement différé et l'initialisation asynchrone, de sorte que le flipbook n'ajoute pas de délai d'entrée à ta page hôte. Ces optimisations garantissent que les flipbooks intégrés et partagés paraissent réactifs dès le premier clic, qu'ils soient consultés sur ordinateur ou sur mobile.

| Évaluation | Seuil FID | Ce que ça signifie | |--------|--------------|---------------| | Bon | ≤ 100 ms | La page répond instantanément aux entrées | | À améliorer | 101–300 ms | Délai perceptible avant la réponse | | Mauvais | > 300 ms | La page semble peu réactive ou figée | Le FID est mesuré au 75e centile des chargements de page dans le Chrome User Experience Report (CrUX). Cela signifie que 75 % de tes visiteurs doivent connaître un FID de 100 ms ou moins pour que ta page franchisse le seuil « bon ». Tu peux mesurer le FID à l'aide de Google PageSpeed Insights, de Lighthouse ou de la bibliothèque JavaScript Web Vitals dans ta propre configuration d'analyse.

Le FID ne mesure que la portion de délai du traitement de l'événement — l'écart entre le déclenchement de l'événement d'entrée et le démarrage de l'exécution du gestionnaire d'événement par le navigateur. Il n'inclut pas le temps que met le gestionnaire à s'exécuter ni le temps que met le navigateur à redessiner l'écran. La cause la plus courante d'un FID élevé est la présence de longues tâches JavaScript sur le thread principal. Lorsque le navigateur est occupé à exécuter un script qui prend 200 ms ou plus, toute entrée de l'utilisateur durant cette fenêtre est mise en file d'attente et retardée. Les sources courantes de blocage du thread principal incluent : - **Les gros bundles JavaScript** analysés et compilés au chargement de la page - **Les scripts tiers** (analytique, publicités, widgets de chat) exécutés de manière synchrone - **Les manipulations lourdes du DOM** durant le rendu initial - **Le chargement non optimisé des polices web** qui déclenche des recalculs de mise en page Pour réduire le FID, fractionne les longues tâches en petits morceaux, diffère les scripts non essentiels, utilise le découpage de code pour ne charger que le JavaScript nécessaire à la vue courante et minimise l'impact des scripts tiers.

Google a officiellement remplacé le FID par l'[Interaction to Next Paint (INP)](/glossary/core-web-vitals) comme Core Web Vital en mars 2024. Alors que le FID ne mesure que la première interaction, l'INP mesure la réactivité de toutes les interactions tout au long du cycle de vie de la page et retient la pire (ou la quasi-pire pour les pages comportant de nombreuses interactions). Cela fait de l'INP une mesure de réactivité plus complète. Différences clés : - **Portée** : le FID ne mesure que le délai de la première interaction. L'INP mesure chaque interaction (clics, touchers, appuis sur touche) et rapporte la pire. - **Ce qui est mesuré** : le FID ne mesure que le délai d'entrée (le temps avant que le gestionnaire ne s'exécute). L'INP mesure la durée complète depuis l'entrée jusqu'à la prochaine mise à jour visuelle (paint). - **Seuil** : un bon FID est ≤ 100 ms. Un bon INP est ≤ 200 ms. - **Statut** : le FID est déprécié en tant que Core Web Vital mais reste rapporté par de nombreux outils. L'INP est la mesure officielle actuelle. Même si le FID n'est plus un Core Web Vital, les optimisations qui améliorent le FID — réduire le blocage du thread principal, différer les scripts, découper le code — améliorent aussi l'INP. La visionneuse de FlipLink est optimisée pour les deux mesures.