Rejeter vos gestionnaires d'entrée

Les gestionnaires d'entrée sont une cause potentielle de problèmes de performances dans vos applications, car ils peuvent empêcher la finalisation des frames et entraîner un travail de mise en page supplémentaire et inutile.

Les gestionnaires d'entrée sont une cause potentielle de problèmes de performances dans vos applications, car ils peuvent empêcher la finalisation des frames et entraîner un travail de mise en page supplémentaire et inutile.

Résumé

  • Évitez les gestionnaires d'entrée de longue durée, car ils peuvent bloquer le défilement.
  • N'apportez pas de modifications de style dans les gestionnaires d'entrée.
  • Décompressez vos gestionnaires. Stockez les valeurs d'événement et gérez les modifications de style dans le rappel requestAnimationFrame suivant.

Éviter les gestionnaires d'entrée de longue durée

Dans le cas le plus rapide possible, lorsqu'un utilisateur interagit avec la page, le thread 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ù sont effectués JavaScript, la mise en page, les styles ou la peinture.

Le défilement léger : le délai entre le moment où l'utilisateur touche l'écran et le moment où le GPU valide l'opération est minimal avec le 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'empêcher le défilement tactile. Même si vous n'appelez pas preventDefault(), le compositeur doit attendre, et le défilement de l'utilisateur est bloqué, ce qui peut entraîner des saccades et des frames manquées.

Défilement intensif : après l'interaction de l'utilisateur, le défilement est bloqué et l'envoi à la GPU est retardé par le gestionnaire "onTouchMove".

En bref, vous devez vous assurer que tous les gestionnaires d'entrée que vous exécutez s'exécutent rapidement et permettent au compositeur de faire son travail.

Éviter les modifications de style dans les gestionnaires d'entrée

Les gestionnaires d'entrée, tels que ceux de défilement et de 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 le conseil “Éviter les mises en page volumineuses et complexes et le thrashing de mise en page”, vous déclencherez une mise en page synchrone forcée.

Le défilement intensif et la lecture du style de planification après requestAnimationFrame entraînent une synchronisation forcée de la mise en page.

Décompressez vos gestionnaires de défilement

La solution aux deux problèmes ci-dessus est la même : vous devez toujours décompresser les modifications visuelles dans le 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 supplémentaire de maintenir la légèreté de vos gestionnaires d'entrée, ce qui est idéal, car vous ne bloquez plus les éléments tels que le défilement ou le toucher sur du code coûteux en termes de calcul.