Pourquoi le debounce et le throttle sont importants dans les interfaces

Certaines événements DOM se déclenchent à une fréquence extrêmement élevée. L’événement keypress se déclenche à chaque frappe. L’événement scroll se déclenche des dizaines de fois par seconde pendant le défilement. L’événement resize se déclenche continuellement lorsque l’utilisateur fait glisser la bordure de la fenêtre. Traiter chaque événement individuellement peut surcharger le navigateur comme votre serveur.

Si votre gestionnaire de frappe effectue un appel à l’interface de programmation à chaque frappe, un utilisateur qui saisit « crochets React » déclenche autant de requêtes réseau qu’il y a de caractères, dont la plupart correspondent à des requêtes incomplètes. De même, mettre à jour une animation parallaxe à chaque pixel de défilement provoque des centaines de nouveaux rendus React par seconde. Cela gaspille du temps processeur, du réseau et de la batterie.

La temporisation différée retarde l’exécution jusqu’à ce que l’événement ait cessé de se déclencher pendant une durée donnée. Si l’utilisateur continue de saisir du texte, le minuteur est réinitialisé à chaque frappe. Ce n’est qu’après N millisecondes de silence que le gestionnaire s’exécute enfin, une seule fois. La temporisation différée répond à la question : « exécuter ceci une fois que l’utilisateur a fini d’effectuer une action ».

La limitation de fréquence limite l’exécution à une fois au maximum par intervalle, quel que soit le nombre d’événements déclenchés. Si l’utilisateur fait défiler rapidement la page, une limitation à 100 ms garantit que votre gestionnaire ne s’exécute pas plus de 10 fois par seconde. La limitation de fréquence répond à la question : « exécuter ceci régulièrement, mais pas plus souvent qu’une fois toutes les N millisecondes ».

La temporisation différée est le bon choix lorsque seule la valeur finale après l’arrêt de l’utilisateur vous intéresse. Cas classiques : le champ de recherche (envoyer une requête à l’interface de programmation après une pause de saisie), le gestionnaire de redimensionnement de la fenêtre (recalculer la mise en page une fois le redimensionnement terminé) et la validation d’un champ de formulaire qui interroge un serveur (attendre la saisie complète avant de valider).

La limitation de fréquence est le bon choix lorsque vous souhaitez des mises à jour régulières pendant une activité continue. Cas classiques : le gestionnaire de position de défilement (mettre à jour une barre de progression de lecture ou un en-tête fixe à 30 images par seconde au maximum), le suivi des mouvements de la souris (enregistrer la position du curseur pour l’analyse) et les gestionnaires d’événements de glissement (mettre à jour fluidement la position d’un élément déplaçable sans saturer le système).

Écrire une temporisation différée ou une limitation de fréquence sans bien en comprendre tous les mécanismes entraîne des erreurs, comme l’omission de l’événement final, un déclenchement sur le mauvais front ou l’absence de nettoyage des minuteurs lors du démontage du composant. Il vaut généralement mieux utiliser des implémentations éprouvées de bibliothèques telles que lodash, qui gèrent correctement tous les cas particuliers.

Lodash fournit _.debounce(fn, wait) et _.throttle(fn, wait), avec des options pour le comportement au début et à la fin de la séquence. La fonction renvoyée possède une méthode .cancel() pour annuler une invocation en attente et une méthode .flush() pour l’exécuter immédiatement. Dans React, ces fonctions doivent être enveloppées dans useRef afin d’éviter leur recréation lors d’un nouveau rendu.

Même 50 rendus React supplémentaires par seconde dus à un gestionnaire de défilement sans limitation peuvent consommer une quantité importante de processeur, notamment sur les appareils mobiles peu puissants. Un budget de 16 ms par image (60 images par seconde) signifie que chaque nouveau rendu doit s’achever en moins de 16 millisecondes pour éviter les images sautées. La temporisation différée et la limitation de fréquence constituent votre première ligne de défense contre les problèmes de fréquence d’images.

Tous les gestionnaires à haute fréquence n’ont pas besoin d’une temporisation différée. Si le gestionnaire d’événement se contente de lire une valeur sans mettre à jour l’état ni appeler d’interfaces de programmation — par exemple, enregistrer la dernière position de la souris dans une référence — aucune temporisation n’est nécessaire. Limitez uniquement les gestionnaires qui déclenchent des opérations coûteuses : mises à jour d’état, appels à des interfaces de programmation ou mesures du DOM.

Lorsqu’un composant est démonté, tout appel temporisé en attente doit être annulé afin d’empêcher une mise à jour d’état après le démontage. Si vous utilisez un useRef pour stocker la fonction temporisée, appelez debouncedFn.cancel() dans le nettoyage de useEffect. Les fonctions temporisées de Lodash exposent cette méthode précisément à cette fin.

Quelle technique devez-vous utiliser pour déclencher un appel à l’interface de programmation lorsque l’utilisateur cesse de saisir du texte dans un champ de recherche ?

Les événements à haute fréquence comme keypress, scroll et resize peuvent entraîner des problèmes de performance si les gestionnaires s’exécutent à chaque événement. La temporisation différée attend le silence et convient particulièrement aux champs de recherche et aux gestionnaires de redimensionnement. La limitation de fréquence réduit la fréquence d’exécution et convient particulièrement au défilement et au glissement. Utilisez les implémentations de lodash stockées dans des références et annulez-les toujours lors du démontage du composant.