Core Web Vitals Google : comment optimiser le First Input Delay (FID)

Pour une métrique équivalente au FID avec des outils de Synthetic Monitoring, vous pouvez observer le Total Blocking Time (TBT). FID et TBT ne mesurent pas exactement la même chose dans les mêmes conditions, mais les améliorations du TBT permettent généralement d’améliorer le FID.

La principale cause d'un mauvais FID est une exécution JavaScript lourde. L'optimisation de la façon dont JavaScript est analysé, compilé et s’exécute sur votre page web réduira directement le FID.

First Input Delay : l’exécution JavaScript lourde

Le navigateur ne peut pas répondre à la plupart des actions de l’utilisateur tant qu'il exécute du JavaScript sur le thread principal. En d'autres termes, le navigateur ne peut pas réagir aux inputs des utilisateurs lorsque le thread principal est occupé. Pour régler ce problème et observer une amélioration de vos performances, vous pouvez opter pour l’une de ces techniques que nous allons détailler ci-dessous :

• Diviser les Long Tasks
• Optimiser votre page pour qu’elle soit prête à répondre aux interactions
• Utiliser un Web Worker
• Réduire le temps d’exécution des JavaScript

(NdT : nous proposons régulièrement des techniques et astuces pour vous aider à améliorer l'ensemble de vos métriques webperf dans notre newsletter mensuelle, vous pouvez vous y abonner ici.)

Diviser les Long Tasks pour un meilleur FID

Si vous avez déjà tenté de réduire la quantité de JavaScript qui se charge sur une seule page, il peut être utile de diviser les Long Tasks en tâches asynchrones plus petites.

Les tâches longues (Long Tasks) sont des périodes d'exécution de JavaScript pendant lesquelles les utilisateurs peuvent se trouver devant une interface qui ne répond pas, c'est un problème frustrant. Tout morceau de code qui bloque le thread principal pendant 50 ms ou plus peut être qualifié de tâche longue. Dans cette situation, le chargement et l'exécution du JS prend trop d’importance par rapport aux besoins immédiats de l’utilisateur. 

La division des tâches longues peut alors réduire l’Input Delay sur votre site pour une meilleure réactivité :

Visualisation Chrome DevTools de Long Tasks dans Performance Panel

Le FID devrait s'améliorer sensiblement à mesure que vous adoptez les bonnes pratiques telles que le code-splitting et la division de vos Long Tasks. Bien que TBT ne soit pas une mesure Field, il permet d’évaluer l'impact des techniques appliquées pour une optimisation du Time To Interactive (TTI) et du FID. Vous pouvez approfondir le sujet de l’effet des Longs Tasks sur le TTI (ressource en anglais).

Optimiser votre page pour qu’elle soit prête à répondre aux interactions

JavaScript est souvent à l’origine des mauvais scores FID et TBT, voyons comment en 3 points courants.

• L'exécution de scripts propriétaires (first party) peut retarder la préparation aux interactions.
• L’importance de la taille du JS, des temps d'exécution longs et un découpage inefficace peuvent dégrader la capacité d’une page à répondre aux inputs de l'utilisateur, et donc avoir un impact sur le FID, le TBT et le TTI. Le chargement progressif du code et des fonctionnalités peut aider à améliorer la réactivité aux interactions.
• Les applications rendues côté serveur peuvent sembler faciliter l’affichage rapide des premiers pixels à l’écran, mais méfiez-vous des interactions des utilisateurs bloquées par des exécutions de script lourdes (par exemple, une réhydratation pour reconnecter les listeners). Cela peut prendre plusieurs centaines de millisecondes, parfois même quelques secondes, si du code-splitting basé sur des routes est utilisé. Pensez à déplacer plus de calcul côté serveur, ou à générer davantage de contenu statique pendant la construction de la page.

L'image ci-dessous montre des scores TBT avant et après l'optimisation du chargement de scripts propriétaires pour une application. En sortant le chargement (et l'exécution) de scripts coûteux pour un composant non essentiel du chemin critique, les utilisateurs peuvent  interagir avec la page beaucoup plus tôt.

La récupération de données (data-fetching) peut avoir un impact sur de nombreux aspects de la préparation à l'interaction 

• Attendre la fin du chargement de requêtes faites en cascade (par exemple, JS et récupération de données pour les composants) peut avoir un impact sur la latence des interactions. Essayez de minimiser les dépendances dans le cadre de récupération de données issues de requêtes faites en cascade.
• Un grand volume de données inlinées peut réduire le temps d'analyse HTML et avoir un impact sur les mesures d’affichage et d'interaction. Essayez de minimiser la quantité de données à traiter côté client.

L'exécution de scripts tiers peut également augmenter la latence des interactions 

• De nombreux sites incluent des Third Parties qui peuvent occuper le réseau et rendre le thread principal momentanément indisponible, ce qui a un impact sur la latence des interactions. Pour éviter cela, vous pouvez opter pour le chargement à la demande de code tiers (par exemple, ne chargez pas les publicités en-dessous de la ligne de flottaison tant qu’elles ne se trouvent à proximité du viewport).
• Dans certains cas, les scripts tiers peuvent préempter les scripts propriétaires en termes de priorité et de bande passante sur le thread principal, retardant également le moment auquel une page est prête pour l'interaction. Priorisez le chargement pour que les utilisateurs voient ce qui a le plus de valeur en premier.

Utiliser un Web Worker pour améliorer le First Input Delay

Un thread principal bloqué est l'une des principales causes d'attente suite à une interaction. Les Web Workers permettent d'exécuter le JavaScript sur un thread en arrière-plan. Le déplacement des opérations non UI vers un thread séparé aide à réduire le temps de blocage du thread principal, et par conséquent à améliorer le FID.

Pensez à utiliser les bibliothèques suivantes pour faciliter l'utilisation des Web Workers sur votre site :

• Comlink : une aide pour abstraire postMessage et le rendre plus facile à utiliser
• Workway : une aide à l’export de Web Worker
• Workerize : une aide pour déplacer des modules dans un Web Worker

Pour aller plus loin, voici un guide sur la façon dont les Web Workers peuvent exécuter du code en dehors du thread principal.

Réduire le temps d’exécution du JavaScript pour une meilleure interactivité

Limiter la quantité de JS sur votre page réduit le temps que le navigateur doit passer à analyser, compiler et exécuter du code. Votre page peut alors répondre plus vite aux interactions.

Pour réduire la quantité de JavaScript exécuté sur votre page :

• Différez le JavaScript inutilisé
• Réduisez les polyfills inutilisés

Différer le code JavaScript inutilisé 

Par défaut, tout JavaScript bloque le rendu. Lorsque le navigateur rencontre une balise de script qui renvoie à un fichier JS externe, il doit suspendre ce qu'il fait et télécharger, analyser, compiler et exécuter ce script. Par conséquent, vous avez tout intérêt à charger uniquement le code nécessaire à la page ou répondre aux inputs de l'utilisateur.

Pour vous aider dans ce sens, l'onglet Coverage de Chrome DevTools indique la quantité de JavaScript non utilisée sur votre page web.

Ainsi, pour réduire le JavaScript inutilisé sur une page : 

• divisez vos bundles JS ;
• différez tout JavaScript non critique, y compris les scripts tiers, en utilisant async ou defer.

Le code-splitting consiste à fractionner un grand bundle JS en petits morceaux qui peuvent être chargés de manière conditionnelle (également connu sous le nom lazy loading). La plupart des navigateurs récents prennent en charge la syntaxe d'importation dynamique pour une récupération de module à la demande :

import('module.js')	
 .then((module) => {	
   // Do something with the module.	
});	

L'importation dynamique de JavaScript sur certaines interactions utilisateur (telles que la modification de route ou l'affichage d'une fenêtre modale) garantit alors que le code non utilisé pour le chargement initial de la page ne sera récupéré qu'en cas de besoin. 

Outre la prise en charge générale du navigateur, la syntaxe d'importation dynamique peut être utilisée dans de nombreux outils de build différents.

• Si vous utilisez webpack, Rollup, ou Parcel comme bundler de modules, profitez de leur prise en charge d'importation dynamique. 
• Les frameworks côté client, comme React, Angular, et Vue fournissent des abstractions pour faciliter le lazy loading au niveau composant.

Voici un article pour aller plus loin sur le sujet du code-splitting (en anglais).

Outre le code-splitting, utilisez toujours async ou defer pour les scripts qui ne sont pas nécessaires pour le chemin critique ou le contenu au-dessus de la ligne de flottaison.

<script defer src="…"></script>	
<script async src="…"></script>	

À moins qu'il n'y ait une raison spécifique de ne pas le faire, tous les scripts tiers doivent être chargés avec defer ou async par défaut.

Réduire les polyfills inutilisés 

Si vous écrivez du code à l'aide d’une syntaxe JavaScript moderne et que vous visez des API modernes, vous devrez le transpiler et inclure des polyfills pour qu'il fonctionne sur les navigateurs plus anciens.

L'un des principaux problèmes de performance liés à l'inclusion de polyfills et de code transpilé vient du fait que les nouveaux navigateurs ne devraient pas avoir à le télécharger s'ils n'en ont pas besoin. Pour réduire la taille JavaScript de votre application, minimisez autant que possible les polyfills inutilisés et limitez leur utilisation aux environnements où ils sont nécessaires.

Pour optimiser l'utilisation de polyfill sur votre site :

• Si vous utilisez Babel comme transpileur, utilisez @babel/preset-env pour inclure seulement les polyfills pour les navigateurs que vous visez. Pour Babel 7.9, activez l’option bugfixes pour exclure les polyfills inutiles.
• Utilisez le pattern module/nomodule pour obtenir deux bundles séparés (@babel/preset-env supporte aussi ceci via target.esmodules).

<script type="module" src="modern.js"></script>	
<script nomodule src="legacy.js" defer></script>	

De nombreuses fonctionnalités ECMAScript plus récentes compilées avec Babel sont déjà prises en charge dans les environnements qui gèrent les modules JavaScript. Ainsi, en simplifiant le processus, vous vous assurez que seul le code transpilé est utilisé pour les navigateurs qui en ont réellement besoin.

Vous trouverez ici un guide pour plus de détails sur les techniques pour servir le bon code aux navigateurs récents (en anglais) pour des pages plus rapides.

Les outils de développement pour monitorer le First Input Delay

Différents outils sont disponibles pour mesurer et optimiser le FID.

• Lighthouse n'inclut pas la prise en charge du FID car il s'agit d'une mesure Field. Cependant, le Total Blocking Time (TBT) peut être utilisé pour s’en approcher. Les optimisations qui améliorent le TBT devraient également améliorer le FID.

• Chrome User Experience Report de Google propose des valeurs FID issues de conditions réelles et agrégées pour un site donné.

Pour approfondir le sujet en vidéo, le replay de notre webinaire dédié au FID est ici :

Au-delà du FID et des Core Web Vitals,
vous souhaitez en savoir plus sur l'ensemble de vos indicateurs webperf,
comprendre leur fonctionnement et les améliorer ?