Rejeter vos gestionnaires d'entrée

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 les frames de se terminer et peuvent entraîner des de mise en page.

Résumé

  • Évitez d'utiliser des gestionnaires d'entrées de longue durée. ils peuvent bloquer le défilement.
  • Ne modifiez pas le style des gestionnaires d'entrées.
  • Réfuter vos gestionnaires stocker les valeurs d'événement et gérer les modifications de style dans le prochain rappel requestAnimationFrame.

Éviter les gestionnaires d'entrées 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, qui utilise JavaScript, la mise en page, les styles ou la peinture.

Défilement léger compositeur uniquement.

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 du stuttering et des images manquées.

Défilement important le compositeur est bloqué sur JavaScript.

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 le suggère la section Éviter les mises en page complexes et volumineuses, vous allez déclencher une mise en page synchrone forcée.

Défilement important le compositeur est bloqué sur JavaScript.

Ignorer vos gestionnaires de défilement

La solution aux deux problèmes ci-dessus est la même: vous devez toujours refuser les modifications visuelles au rappel requestAnimationFrame suivant:

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 réduire la taille de vos gestionnaires d'entrées, ce qui est très pratique, car vous ne bloquez plus des éléments tels que le défilement ou l'interaction avec du code coûteux en calcul.