Rejeter vos gestionnaires d'entrée

Les gestionnaires d'entrée peuvent causer des problèmes de performances dans vos applications. En effet, ils peuvent empêcher la fin de l'exécution des frames et entraîner des tâches de mise en page supplémentaires et inutiles.

Les gestionnaires d'entrée peuvent causer des problèmes de performances dans vos applications, car ils peuvent bloquer la fin 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.
• Rejetez 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ées de longue durée

Dans le cas le plus rapide possible, lorsqu'un utilisateur interagit avec la page, le fil de discussion du compositeur de la page peut prendre la saisie tactile de l'utilisateur et simplement déplacer le contenu. Cela ne nécessite aucun travail de la part du thread principal, qui utilise JavaScript, la mise en page, les styles ou la peinture.

Toutefois, si vous associez un gestionnaire d'entrée, tel que touchstart, touchmove ou touchend, le thread compositeur doit attendre la fin de son exécution, 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 un saccades et des images manquées.

En bref, vous devez vous assurer que tous les gestionnaires d'entrée 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ée

Les gestionnaires d'entrée, comme ceux pour le défilement et l'appui, sont programmés pour s'exécuter juste avant tout rappel requestAnimationFrame.

Si vous apportez une modification visuelle dans l'un de ces gestionnaires, des changements 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 le suggère le conseil de la section Éviter les mises en page volumineuses et complexes et le thrashing de mise en page, vous déclenchez une mise en page synchrone forcée.

Rejeter vos gestionnaires de défilement

La solution aux deux problèmes ci-dessus est la même: vous devez toujours rejeter les modifications visuelles au 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);

Cette approche présente également l'avantage de réduire la légèreté de vos gestionnaires d'entrée, ce qui est très utile, car vous ne bloquez plus des éléments tels que le défilement ou l'appui sur du code coûteux en ressources de calcul.