Découvrez ce qu'est le délai d'entrée et apprenez à le réduire afin d'accélérer l'interactivité.
Les interactions sur le Web sont complexes, car toutes sortes d'activités se produisent dans le navigateur pour les générer. Cependant, ils ont tous un point en commun : ils subissent un certain délai d'entrée avant que leurs rappels d'événement ne commencent à s'exécuter. Dans ce guide, vous allez découvrir ce qu'est le délai d'entrée et ce que vous pouvez faire pour le réduire afin que les interactions sur votre site Web s'exécutent plus rapidement.
Qu'est-ce que le délai d'entrée ?
Le délai de saisie correspond à la période écoulée entre le moment où l'utilisateur interagit avec une page (en appuyant sur un écran, en cliquant avec la souris ou en appuyant sur une touche, par exemple) jusqu'au moment où les rappels d'événement pour l'interaction commencent à s'exécuter. Chaque interaction commence par un certain délai d'entrée.
![Visualisation simplifiée du délai d'entrée. À gauche, on peut voir un dessin au trait d'un curseur de souris avec une étoile en arrière-plan, qui indique le début d'une interaction. À droite figure un dessin au trait d'une roue dentée, qui indique à quel moment les gestionnaires d'événements d'une interaction commencent à s'exécuter. L'espace entre les deux correspond au délai d'entrée encadré par une accolade.](https://web.developers.google.cn/static/articles/optimize-input-delay/image/a-simplified-visualizatio-d1514b424d9ec.png?authuser=6&hl=fr)
Une partie du délai d'entrée est inévitable: il faut toujours un certain temps au système d'exploitation pour reconnaître un événement d'entrée et le transmettre au navigateur. Toutefois, cette partie du délai d'entrée n'est généralement pas visible. D'autres événements peuvent survenir sur la page elle-même et ainsi entraîner des délais de saisie suffisamment longs pour provoquer des problèmes.
À propos du délai d'entrée
De manière générale, chaque partie d'une interaction doit être aussi courte que possible afin que votre site Web ait les meilleures chances d'atteindre la "bonnes" de la métrique Interaction to Next Paint (INP) : de sécurité, quel que soit l'appareil de l'utilisateur. Contrôler le délai d'entrée n'est qu'une partie de l'atteinte de ce seuil.
Par conséquent, vous devez chercher le délai d'entrée le plus court possible pour atteindre la valeur « bonne » de l'INP. de sortie. Sachez toutefois que vous ne pouvez pas vous attendre à éliminer complètement les délais d'entrée. Tant que vous évitez les tâches excessives du thread principal lorsque les utilisateurs tentent d'interagir avec votre page, le délai de saisie doit être suffisamment faible pour éviter les problèmes.
Réduire le délai d'entrée
Comme indiqué précédemment, un certain délai d'entrée est inévitable, tandis qu'un certain délai d'entrée est évitable. Voici quelques éléments à prendre en compte si vous rencontrez des problèmes avec de longs délais de saisie.
Éviter les minuteurs récurrents qui lancent un travail excessif du thread principal
En JavaScript, deux fonctions de minuterie couramment utilisées peuvent contribuer au délai d'entrée: setTimeout
et setInterval
. La différence entre les deux est que setTimeout
planifie un rappel pour qu'il s'exécute après un délai spécifié. setInterval
, en revanche, planifie un rappel pour qu'il s'exécute toutes les n millisecondes indéfiniment ou jusqu'à ce que le minuteur soit arrêté avec clearInterval
.
setTimeout
ne pose pas de problème en soi. Il peut même être utile pour éviter les longues tâches. Toutefois, cela dépend du moment où le délai d'inactivité s'est produit et de la tentative ou non d'interaction de l'utilisateur avec la page lors de l'exécution du rappel.
De plus, setTimeout
peut être exécuté dans une boucle ou de manière récursive, où il agit davantage comme setInterval
, mais de préférence, il ne planifie pas l'itération suivante tant que la précédente n'est pas terminée. Bien que cela signifie que la boucle cède au thread principal chaque fois que setTimeout
est appelé, vous devez veiller à ce que son rappel ne fasse pas un travail excessif.
setInterval
exécute un rappel sur un intervalle. Il est donc beaucoup plus susceptible de perturber les interactions. En effet, contrairement à une seule instance d'un appel setTimeout
, qui est un rappel ponctuel qui peut entraver une interaction avec l'utilisateur, la nature récurrente de setInterval
rend beaucoup plus susceptible d'entraver une interaction, ce qui augmente le délai d'entrée de l'interaction.
![Capture d'écran du Profileur de performances dans les outils pour les développeurs Chrome montrant le délai de saisie. Une tâche déclenchée par une fonction de minuteur se produit juste avant qu'un utilisateur ne lance une interaction de clic. Cependant, le minuteur prolonge le délai d'entrée, provoquant l'exécution des rappels d'événement de l'interaction plus tard qu'ils ne le feraient autrement.](https://web.developers.google.cn/static/articles/optimize-input-delay/image/a-screenshot-the-perform-0955d1c357d1f.png?authuser=6&hl=fr)
setInterval
précédent, contribuant au délai d'entrée, comme illustré dans le panneau "Performances" des outils pour les développeurs Chrome. Le délai d'entrée ajouté entraîne l'exécution des rappels d'événement pour l'interaction plus tard qu'ils ne le pourraient autrement.
Si des minuteurs ont lieu dans le code propriétaire, c'est vous qui les contrôlez. Évaluez si vous en avez besoin ou faites de votre mieux pour les réduire autant que possible. Cependant, dans les scripts tiers, les minuteurs sont différents. Souvent, vous ne contrôlez pas le fonctionnement d'un script tiers. Pour résoudre les problèmes de performances dans le code tiers, vous devez souvent collaborer avec les personnes concernées pour déterminer si un script tiers donné est nécessaire. Si tel est le cas, contactez un fournisseur de script tiers pour déterminer comment résoudre les problèmes de performances qu'ils peuvent causer sur votre site Web.
Éviter les longues tâches
Une façon d'atténuer les longs délais d'entrée consiste à éviter les longues tâches. Lorsque des tâches de thread principal excessives bloquent le thread principal lors des interactions, cela s'ajoute au délai d'entrée avant que les longues tâches aient pu se terminer.
![Visualisation de la durée pendant laquelle les tâches prolongent le délai d'entrée En haut, une interaction se produit peu de temps après l'exécution d'une seule longue tâche, ce qui entraîne un délai d'entrée important qui entraîne l'exécution des rappels d'événements beaucoup plus tard qu'ils ne le devraient. En bas de l'écran, une interaction se produit à peu près au même moment, mais la tâche longue est divisée en plusieurs tâches plus petites grâce au rendement, ce qui permet aux rappels d'événement de l'interaction de s'exécuter beaucoup plus tôt.](https://web.developers.google.cn/static/articles/optimize-input-delay/image/a-visualization-how-long-af65d3963b8fb.png?authuser=6&hl=fr)
En plus de réduire la quantité de travail que vous effectuez dans une tâche (et vous devez toujours vous efforcer d'effectuer le moins de travail possible sur le thread principal), vous pouvez améliorer la réactivité aux entrées utilisateur en divisant les longues tâches.
Tenez compte des interactions et du chevauchement
Si vos interactions se chevauchent, l'optimisation de l'INP peut s'avérer particulièrement difficile. Le chevauchement d'interactions signifie qu'après avoir interagi avec un élément, vous effectuez une autre interaction avec la page avant que l'interaction initiale ait eu la possibilité d'afficher le frame suivant.
![Représentation des tâches qui peuvent se chevaucher pour produire de longs délais d'entrée. Dans cette représentation, une interaction de clic chevauche une interaction de clavier afin d'augmenter le délai de saisie pour l'interaction de réduction.](https://web.developers.google.cn/static/articles/optimize-input-delay/image/a-depiction-when-tasks-8c6449133de24.png?authuser=6&hl=fr)
Les sources de chevauchement peuvent être aussi simples que les utilisateurs effectuant de nombreuses interactions dans un court laps de temps. Cela peut se produire lorsque les utilisateurs saisissent du texte dans des champs de formulaire, où de nombreuses interactions avec le clavier peuvent se produire en très peu de temps. Si le travail sur un événement clé est particulièrement coûteux (par exemple, dans le cas des champs de saisie semi-automatique où des requêtes réseau sont envoyées à un backend), deux options s'offrent à vous:
- Envisagez d'utiliser des entrées anti-rebond pour limiter le nombre de fois où un rappel d'événement s'exécute dans une période donnée.
- Utilisez
AbortController
pour annuler les requêtesfetch
sortantes afin que le thread principal ne soit pas encombré lors de la gestion des rappelsfetch
. Remarque: La propriétésignal
d'une instanceAbortController
peut également être utilisée pour annuler des événements.
L'augmentation du délai d'entrée dû aux interactions qui se chevauchent peut également entraîner des animations coûteuses. En particulier, les animations en JavaScript peuvent déclencher de nombreux appels requestAnimationFrame
, ce qui peut gêner les interactions de l'utilisateur. Pour contourner ce problème, utilisez des animations CSS dans la mesure du possible afin d'éviter la mise en file d'attente d'images d'animation potentiellement coûteuses. Toutefois, dans ce cas, assurez-vous d'éviter les animations non composées afin que les animations s'exécutent principalement sur les threads du GPU et du compositeur, et non sur le thread principal.
Conclusion
Même si les délais de saisie ne représentent pas la majorité du temps nécessaire à l'exécution de vos interactions, il est important de comprendre que chaque partie d'une interaction prend un temps que vous pouvez réduire. Si vous constatez que le délai de saisie est long, vous avez la possibilité de le réduire. Éviter les rappels récurrents de minuteur, répartir les longues tâches et être conscient des potentiels chevauchements d'interactions peut vous aider à réduire le délai d'entrée, ce qui accélère l'interactivité pour les utilisateurs de votre site Web.
Image principale tirée de Unsplash, par Erik Mclean.