Les gestionnaires d'entrées sont une cause potentielle de problèmes de performances dans vos applications, car ils peuvent bloquer l'affichage des frames et entraîner des tâches de mise en page supplémentaires et inutiles.
Les gestionnaires d'entrées sont une cause potentielle de problèmes de performances dans vos applications, car ils peuvent empêcher l'exécution des frames et entraîner des tâches de mise en page supplémentaires et inutiles.
Résumé
- Évitez les gestionnaires d'entrées de longue durée, car ils peuvent bloquer le défilement.
- Ne modifiez pas le style des gestionnaires d'entrées.
- Repoussez vos gestionnaires, stockez les valeurs d'événement et gérez les changements de style dans le prochain rappel requestAnimationFrame.
Éviter les gestionnaires d'entrée de longue durée
Dans les cas les plus rapides, lorsqu'un utilisateur interagit avec la page, le fil de discussion du compositeur de la page peut prendre l'entrée tactile de l'utilisateur et simplement déplacer le contenu. Cela ne nécessite aucun travail de la part du thread principal, où JavaScript, la mise en page, les styles ou la peinture sont effectués.
Toutefois, si vous associez un gestionnaire d'entrée, tel que touchstart, touchmove ou touchend, le thread du compositeur doit attendre la fin de l'exécution de ce gestionnaire, car vous pouvez choisir d'appeler preventDefault() et d'arrêter le défilement tactile. Même si vous n'appelez pas preventDefault(), le compositeur doit attendre. Par conséquent, le défilement de l'utilisateur est bloqué, ce qui peut entraîner des à-coups et des images manquantes.
En bref, vous devez vous assurer que tous les gestionnaires d'entrées que vous exécutez doivent s'exécuter rapidement et permettre au compositeur de faire son travail.
Éviter les changements de style dans les gestionnaires d'entrées
Les gestionnaires d'entrée, comme ceux du défilement et du toucher, sont programmés pour s'exécuter juste avant les rappels requestAnimationFrame.
Si vous apportez une modification visuelle dans l'un de ces gestionnaires, des modifications de style seront en attente au début de requestAnimationFrame. Si vous lisez ensuite les propriétés visuelles au début du rappel requestAnimationFrame, comme indiqué dans Éviter les mises en page volumineuses et complexes et les rafales de mises en page, vous déclencherez une mise en page synchrone forcée.
Ignorer vos gestionnaires de défilement
La solution aux deux problèmes ci-dessus est la même : vous devez toujours debouncer les modifications visuelles du prochain rappel requestAnimationFrame :
function onScroll (evt) {
// Store the scroll value for laterz.
lastScrollY = window.scrollY;
// Prevent multiple rAF callbacks.
if (scheduledAnimationFrame)
return;
scheduledAnimationFrame = true;
requestAnimationFrame(readAndUpdatePage);
}
window.addEventListener('scroll', onScroll);
Cela présente également l'avantage de garder vos gestionnaires d'entrée légers, ce qui est génial, car vous ne bloquez plus des éléments tels que le défilement ou le toucher sur du code coûteux en calcul.