Expliquez-moi ce que fait réellement le navigateur entre l'exécution d'un gestionnaire de clic et l'apparition de la frame suivante à l'écran.

Le gestionnaire de clic s'exécute jusqu'au bout comme une seule tâche. Toutes les microtâches qu'il a mises en file, y compris les callbacks de promesses résolues, se vident ensuite, avant tout le reste. Seulement après, si une frame est due, le navigateur exécute les callbacks requestAnimationFrame et passe par le style, le layout, le paint et le composite. Une tâche longue ou une chaîne interminable de microtâches retarde cette frame, et les utilisateurs lisent ce retard comme des saccades.

Le gestionnaire lui-même est une tâche sur le thread principal, donc il s'exécute du début à la fin sans rien pour l'interrompre. Dès qu'il retourne, le navigateur vide la file des microtâches, donc toute continuation d'await ou tout callback then de promesse s'exécute là, et si celles-ci continuent d'empiler des microtâches le navigateur n'a jamais l'occasion de peindre. Une fois cette file vide, et seulement si une frame est vraiment due, le navigateur exécute les callbacks requestAnimationFrame, recalcule le style, fait le layout, peint et compose. C'est pour ça que je considère les tâches longues comme le vrai ennemi. Sur un tableau de bord sur lequel j'ai travaillé, un changement de filtre faisait un tri synchrone d'environ quarante mille lignes dans le gestionnaire, et le clic semblait mort pendant environ deux cents millisecondes. En le découpant pour que le gestionnaire ne mette à jour que le champ, puis en rendant la main avec scheduler.yield avant la passe coûteuse, le budget de frame est resté intact et l'interaction a commencé à répondre immédiatement alors que le travail total était identique.