Comment optimiser les Core Web Vitals sur mobile pour réduire l’INP ?

Pour réduire l’INP sur mobile, il ne suffit pas d’accélérer le téléchargement des pages : après un clic, une pression ou une saisie au clavier, le navigateur doit afficher la frame suivante au plus vite. La compression des images et l’utilisation d’un CDN peuvent améliorer l’expérience de chargement, mais ne résolvent pas directement le manque de réponse après un clic sur un bouton. Si le thread principal est occupé par l’exécution de scripts ou le rendu de la page, les interactions peuvent toujours être saccadées.

Pour savoir comment optimiser les Core Web Vitals afin d’améliorer l’expérience mobile, il faut décomposer l’INP en délai d’entrée, durée de traitement des événements et délai de présentation, puis intervenir sur les sources de ralentissement. Raccourcir uniquement le gestionnaire de clic ou améliorer le score d’un seul test en laboratoire ne suffit pas à prouver que la réactivité des interactions s’est améliorée pour les utilisateurs réels.

L’INP mesure le temps entre une interaction et la frame suivante, pas le temps nécessaire à l’achèvement d’une opération métier

L’INP, ou Interaction to Next Paint, observe les clics, pressions et interactions au clavier admissibles au cours du cycle de vie d’une page. Il reflète la réactivité des interactions les plus lentes. Lorsque les interactions sont nombreuses, le calcul écarte, selon certaines règles, une petite partie des valeurs extrêmes. Il ne s’agit donc ni du temps moyen de toutes les interactions, ni simplement de la valeur maximale absolue.

Dans l’évaluation des Core Web Vitals de Google, un INP inférieur ou égal à 200 millisecondes est considéré comme « bon », un INP supérieur à 200 et inférieur ou égal à 500 millisecondes comme « à améliorer », et un INP supérieur à 500 millisecondes comme « médiocre ». La conformité d’un site est évaluée au 75e percentile des données de visites réelles, séparément sur mobile et sur ordinateur. Cette mesure à l’échelle du site est distincte de la sélection d’interactions représentatives au sein d’une seule visite.

L’INP ne correspond pas non plus au temps de réponse d’une API. Après l’envoi d’une demande de renseignements, si la page affiche immédiatement un état « Envoi en cours » et que la requête réseau se termine ensuite, l’INP de cette interaction peut être faible. Toutefois, un INP faible ne signifie pas que l’opération a abouti : le temps de réponse de la requête, le taux d’échec et les soumissions en double doivent être suivis séparément.

Repérez d’abord l’étape qui ralentit, puis choisissez les améliorations à apporter

Le délai d’entrée d’une interaction correspond au temps d’attente entre l’action de l’utilisateur et le début de l’exécution du gestionnaire d’événement. La durée de traitement est le temps consacré à l’exécution des gestionnaires concernés. Le délai de présentation correspond au temps entre la fin du gestionnaire et l’affichage de la frame suivante. Chacune de ces étapes peut constituer un goulot d’étranglement sur mobile.

Si, au moment où l’utilisateur clique, le thread principal analyse un script, exécute du code tiers ou traite une autre tâche, le délai d’entrée augmente. Si le gestionnaire filtre de manière synchrone un grand nombre de produits, valide l’ensemble d’un formulaire ou met à jour de nombreux composants, la durée de traitement augmente. Enfin, si la fin du gestionnaire est suivie de calculs de style, de mises en page et de dessins de grande ampleur, le délai de présentation augmente.

Vous pouvez enregistrer dans le panneau Performances de Chrome DevTools des opérations comme l’ouverture d’un menu, le filtrage de produits, le changement de spécification et l’envoi d’une demande de renseignements, puis examiner les tâches du thread principal et les activités de rendu le long du parcours de l’interaction. Les tâches de plus de 50 millisecondes sont des tâches longues, mais elles ne constituent qu’un indice pour le diagnostic : plusieurs tâches courtes successives peuvent également retarder le rendu. L’absence de tâche longue ne prouve donc pas que l’INP est conforme.

Il est plus important de réduire les blocages que de simplement différer les scripts

Lorsque le délai d’entrée est élevé, vérifiez si des scripts s’exécutent de manière intensive au moment où l’utilisateur commence à interagir. Sur les sites marketing, les outils de chat en ligne, les balises d’analyse, le suivi publicitaire et les fenêtres pop-up méritent d’être examinés individuellement en fonction de leur moment de chargement et de leur coût d’exécution. L’utilisation de async ou defer modifie le moment du chargement et de l’exécution des scripts, mais ne supprime pas l’occupation du thread principal qu’ils entraînent à l’exécution.

Les scripts non indispensables peuvent être chargés en fonction de l’utilisation de la page, du consentement de l’utilisateur ou des besoins réels. Supprimez également les balises en double. Le chargement différé ne doit pas conduire à lancer tous les scripts au premier clic : cela ne ferait que déplacer leur coût de chargement sur le parcours d’interaction.

Les calculs synchrones doivent être répartis en lots, en cédant le thread principal entre chaque lot. Les navigateurs compatibles peuvent utiliser scheduler.yield() ; les autres environnements nécessitent une solution de repli. Le recours à Promise ou à queueMicrotask pour fractionner le travail n’est pas fiable, car la file des microtâches peut continuer à s’exécuter avant le rendu. Les calculs gourmands en CPU qui ne dépendent pas du DOM peuvent être déplacés dans un Web Worker, en tenant compte du coût des communications et de la copie des données.

Réduisez à la fois le travail des gestionnaires d’événements et celui du rendu

Un gestionnaire de clic doit d’abord effectuer les changements d’état indispensables, par exemple afficher un état de chargement, signaler l’option sélectionnée ou désactiver les soumissions répétées, puis planifier les tâches non urgentes. Modifier l’interface avant d’exécuter encore une série de calculs synchrones ne signifie pas que l’utilisateur a déjà vu le retour visuel : le navigateur doit avoir l’occasion d’effectuer le rendu.

Le filtrage des produits peut mettre en cache les résultats de calcul afin d’éviter de parcourir à nouveau toutes les données à chaque interaction. La validation d’un formulaire doit éviter de recalculer l’ensemble du formulaire à chaque caractère saisi. Le debounce convient pour réduire le nombre de requêtes non urgentes, mais ne doit pas retarder le retour visuel d’un bouton ni masquer le ralentissement d’une opération nécessaire.

Lorsque le délai de présentation est élevé, examinez la taille du DOM, la portée des effets des styles et les limites de mise à jour des composants. La virtualisation peut être utilisée pour les longues listes de produits, mais les besoins en matière d’accessibilité et d’exploration par les moteurs de recherche doivent également être pris en compte. Les alternances répétées entre l’écriture des styles et la lecture des dimensions peuvent déclencher des mises en page forcées : regroupez autant que possible les lectures, puis les écritures. Dans les applications basées sur un framework, vérifiez également si une modification d’état locale provoque la mise à jour de composants sans rapport avec elle, au lieu de vous limiter à mesurer la durée des gestionnaires.

requestAnimationFrame n’est pas non plus un conteneur pour les tâches coûteuses : le code qu’il exécute l’est avant le rendu et, s’il comporte beaucoup de calculs, il peut bloquer la frame suivante.

Vérifiez les résultats à partir des données de visites réelles, pas d’un seul test

Les tests en laboratoire permettent de reproduire les causes des problèmes ; la mesure auprès d’utilisateurs réels permet d’en confirmer l’ampleur. Les données CrUX de PageSpeed Insights reflètent l’expérience des utilisateurs réels. Lorsque le trafic est insuffisant, les données au niveau de la page peuvent manquer ; l’absence de données ne signifie pas que les performances sont bonnes. Le temps de blocage total de Lighthouse peut aider à détecter la pression exercée sur le thread principal pendant le chargement, mais ne remplace pas l’INP.

Sur votre site, vous pouvez utiliser web-vitals et ses fonctions d’attribution pour enregistrer la cible de l’interaction, le type de page et la durée de chaque étape, tout en évitant de collecter des données personnelles comme le contenu des formulaires. Les tests doivent couvrir de véritables appareils mobiles et des conditions raisonnables de ralentissement du CPU. Le simple fait d’afficher une fenêtre étroite dans un navigateur de bureau ne permet pas de prendre en compte les différences de puissance de traitement des appareils mobiles.

Lors de la validation avant mise en production, comparez la distribution de l’INP sur des pages similaires et dans des conditions d’appareil comparables, puis vérifiez à nouveau que les interactions clés fonctionnent toujours correctement. CrUX s’appuie sur des données glissantes sur 28 jours : il ne faut pas s’attendre à ce que les modifications reflètent immédiatement tous les résultats. Selon la définition de l’INP par Google, la preuve d’une optimisation efficace est une réduction du temps d’attente lors des interactions réelles, et non une diminution du poids des ressources ou une hausse du score d’un test.