Voici quelques exemples d’interactions :
- Cliquer sur un lien ou un bouton.
- Saisir du texte dans un champ vide.
- Sélectionner un menu déroulant.
- Cocher une case.
Certains événements comme le défilement ou le zoom ne sont pas pris en compte.
Voyons quel score viser et comment l’améliorer.
Un bon score FID est inférieur à 100 ms et se mesure à partir des données du Chrome User Experience Report (CrUX). Il s’agit de données provenant de véritables utilisateurs de Chrome ayant accepté de partager ces informations lorsqu’ils visitent votre site. Il faut que 75 % des interactions obtiennent une réponse en moins de 100 ms.
Votre page peut être classée dans l’une des catégories suivantes :
- Bon : <= 100 ms
- À améliorer : > 100 ms et <= 300 ms
- Médiocre : > 300 ms
Données sur le FID
95,3 % des sites se situaient dans la catégorie « bon » pour le FID en avril 2023. Cette donnée porte sur l’ensemble des sites mesurés. Comme indiqué plus haut, il faut que 75 % des interactions obtiennent une réponse en moins de 100 ms pour qu’un site soit classé comme « bon ».
Sur la plupart des sites, la majorité des pages valident le test CWV pour le FID. Je ne pense pas que ce soit réellement la meilleure méthode pour mesurer la réactivité, et Google a remplacé le FID par l’Interaction to Next Paint (INP) en mars 2024. Au lieu de se limiter à la première interaction, l’INP examine la latence de toutes les interactions de l’utilisateur.
Lorsque nous avons mené une étude sur les Core Web Vitals, nous avons constaté que pratiquement personne n’a besoin de se soucier du FID sur ordinateur, et que très peu de sites doivent s’en soucier sur mobile.
Peu de sites doivent s’inquiéter du FID, même sur les connexions lentes, puisque la plupart de leurs pages passent le test.
Nos données au niveau de la page, issues de cette étude, vont dans le même sens. Le FID ne semble pas être une préoccupation pour la plupart des pages.
Le seul score FID qui compte vraiment provient du Chrome User Experience Report (CrUX), qui s’appuie sur les données de véritables utilisateurs de Chrome ayant choisi de les partager.
Il s’agit des données de terrain (field data), qui donnent la meilleure idée des performances réelles du FID dans différentes conditions de réseau, sur différents appareils, avec ou sans cache, etc. Ce sont aussi les données que Google utilise effectivement pour évaluer les Core Web Vitals.
Pour des tests cohérents et reproductibles, il existe également les données de laboratoire (lab data), collectées dans des conditions identiques. Le FID n’est pas disponible dans les tests en laboratoire, car les outils de test ne simulent pas d’interactions utilisateur. Vous pouvez toutefois utiliser le Total Blocking Time (TBT) comme indicateur de substitution. En améliorant les processus bloqués, vous améliorerez également votre FID.
Mesurer le FID pour une seule URL
PageSpeed Insights récupère des données de terrain au niveau de la page que vous ne pouvez pas interroger directement dans le jeu de données CrUX. L’outil fournit également des données à l’échelle du domaine afin de comparer les performances d’une page à celles de l’ensemble du site, et exécute des tests en laboratoire basés sur Google Lighthouse pour vous fournir le TBT.
Mesurer le FID pour plusieurs URL ou un site entier
Vous pouvez obtenir les données CrUX dans Google Search Console, classées dans les catégories bon, à améliorer et médiocre.
En cliquant sur l’un des problèmes, vous obtenez une répartition par groupes de pages affectées. Ces groupes rassemblent des pages ayant des valeurs similaires, vraisemblablement issues d’un même modèle. Une seule modification appliquée au modèle suffira à corriger toutes les pages du groupe.
Si vous souhaitez obtenir à la fois des données de laboratoire et des données de terrain à grande échelle, le seul moyen est de passer par l’API PageSpeed Insights. Vous pouvez vous y connecter facilement avec Site Audit d’Ahrefs et obtenir des rapports détaillés sur vos performances. C’est gratuit pour les sites vérifiés disposant d’un compte Ahrefs Webmaster Tools (AWT).
Notez que les données Core Web Vitals affichées dépendent du user-agent sélectionné pour votre crawl lors de la configuration. Si vous explorez le site en mode mobile, vous obtiendrez les valeurs CWV mobiles renvoyées par l’API.
Outil gratuit : vérifiez les CWV et Lighthouse jusqu’à 10 pages
Voici un autre outil gratuit qui vous permet d’analyser jusqu’à 10 pages ou sites simultanément pour vous comparer à vos concurrents.
Configuration :
- Saisissez votre clé d’API Google PageSpeed Insights dans le champ prévu à cet effet. (Pour générer une clé d’API, voir ici.)
- Ajoutez les URL à analyser (une par ligne).
Lancement de l’analyse :
- Cliquez sur le bouton « Check CWV » pour démarrer la récupération des indicateurs. Un indicateur de progression affichera l’état des requêtes.
Consultation des résultats :
Les résultats sont présentés sous forme de cartes de score classées par catégorie :
- CWV Desktop pour la page
- CWV Desktop pour l’origine
- Lighthouse Desktop
- CWV Mobile pour la page
- CWV Mobile pour l’origine
- Lighthouse Mobile
Chaque indicateur est associé à un code couleur reflétant la performance :
- Vert : Bon
- Jaune : À améliorer
- Rouge : Médiocre
Vérificateur en masse des Core Web Vitals
Voici un aperçu pour vous donner une idée de l’apparence des cartes de score. Vous pouvez aussi l’utiliser comme outil autonome : test de vitesse de site web (en anglais).
Du JavaScript qui se dispute le thread principal. Il n’y a qu’un seul thread principal, et chaque script doit attendre son tour pour y exécuter ses tâches.
C’est comme une cuisinière à un seul feu sur laquelle vous devez cuire vos plats un par un, alors que plusieurs plats vous attendent.
Pendant qu’une tâche s’exécute, la page ne peut pas répondre aux interactions de l’utilisateur. C’est ce délai que l’utilisateur perçoit. Plus la tâche est longue, plus le délai ressenti par l’utilisateur est important.
Les pauses entre les tâches sont les occasions pour la page de basculer vers la tâche d’interaction utilisateur et de répondre à son action. Le phénomène est aggravé sur les appareils les moins performants, car le JavaScript peut mettre plus de temps à être traité et provoquer des délais plus longs.
Dans PageSpeed Insights, vous verrez un onglet TBT qui regroupe les problèmes liés au blocage du thread principal. Ce sont ces problèmes qu’il faudra résoudre pour améliorer le FID.
La plupart des pages passent les tests FID. Cependant, si vous devez travailler sur le FID, voici quelques pistes à explorer :
1. Réduisez la quantité de JavaScript
Si vous pouvez réduire la quantité de JavaScript exécuté, commencez par là. Concentrez-vous sur le JavaScript chargé en début de page. Si peu d’optimisations ont été réalisées, le début du processus de chargement peut être saturé par une multitude de scripts JavaScript qui essaient tous de s’exécuter sur cet unique thread principal.
2. Chargez le JavaScript plus tard si possible
Tout JavaScript dont vous n’avez pas besoin immédiatement doit être chargé plus tard. Il existe deux principales méthodes pour cela : les attributs defer et async. Ces attributs peuvent être ajoutés à vos balises <script>.
Par défaut, un script bloque le parseur le temps de son téléchargement et de son exécution. async permet au parsing et au téléchargement de se dérouler simultanément, mais bloque tout de même le parsing pendant l’exécution du script. defer ne bloque pas le parsing pendant le téléchargement, et le script n’est exécuté qu’une fois le parsing du HTML terminé.
Lequel choisir ? Pour tout ce que vous voulez charger plus tôt ou qui comporte des dépendances, j’aurais tendance à privilégier async.
Par exemple, j’utilise généralement async pour les balises analytics afin de comptabiliser davantage d’utilisateurs. Préférez defer pour tout ce qui n’est pas nécessaire immédiatement ou qui n’a pas de dépendances. Ces attributs sont très simples à ajouter.
Voici quelques exemples :
Standard :
<script src="https://www.domain.com/file.js"></script>
Async :
<script src="https://www.domain.com/file.js" async></script>
Defer :
<script src="https://www.domain.com/file.js" defer></script>
3. Découpez les tâches longues
Une autre option consiste à fractionner le JavaScript pour qu’il s’exécute moins longtemps. L’idée est de prendre ces tâches longues qui retardent la réponse aux interactions de l’utilisateur, et de les découper en tâches plus petites qui bloquent moins longtemps. Cela passe par le code splitting, qui consiste à scinder le code en plus petits morceaux.
4. Utilisez les web workers
Il existe également la possibilité de déplacer une partie du JavaScript vers un web worker. Comme mentionné plus haut, le JavaScript se dispute l’unique thread principal du navigateur : c’est un contournement qui lui offre un autre endroit où s’exécuter.
Quelques compromis s’imposent en matière de mise en cache. De plus, le web worker ne peut pas accéder au DOM, il ne peut donc procéder à aucune mise à jour ni modification. Si vous comptez déplacer du JavaScript vers un web worker, il vous faudra un développeur qui maîtrise vraiment le sujet.
5. Utilisez le prerendering ou le rendu côté serveur (SSR)
Si vous utilisez un framework JavaScript, une quantité importante de code est nécessaire pour charger la page. Ce code peut être long à traiter dans le navigateur, provoquant des délais. En recourant au prerendering ou au SSR, vous transférez cette charge du navigateur vers le serveur.
Conclusion
Même si le FID a été remplacé par l’INP en mars 2024, il reste utile de chercher à l’améliorer. La plupart des optimisations que vous mettez en place pour améliorer le TBT et le FID amélioreront également l’INP.
Si vous avez des questions, contactez-moi sur X.
