Erklär mir Schritt für Schritt, was der Browser eigentlich macht zwischen dem Moment, in dem ein Click-Handler läuft, und dem nächsten Frame auf dem Bildschirm.

Der Click-Handler läuft als eine einzige Task komplett durch. Danach wird die Microtask-Queue geleert, inklusive aufgelöster Promise-Callbacks, bevor sonst irgendetwas passiert. Erst dann, und nur wenn ein Frame fällig ist, führt der Browser die requestAnimationFrame-Callbacks aus und geht durch Style, Layout, Paint und Composite. Eine lange Task oder eine endlose Kette von Microtasks verzögert diesen Frame, und Nutzer lesen die Verzögerung als Ruckeln.

Der Handler selbst ist eine Task auf dem Main Thread, er läuft also von Anfang bis Ende durch, ohne dass ihn etwas unterbricht. Sobald er zurückkehrt, leert der Browser die Microtask-Queue, jede await-Fortsetzung und jeder then-Callback eines Promise läuft also genau dort, und wenn die immer weitere Microtasks einreihen, kommt der Browser nie zum Painten. Ist die Queue leer, und nur wenn tatsächlich ein Frame fällig ist, führt der Browser die requestAnimationFrame-Callbacks aus und geht dann durch Style-Recalc, Layout, Paint und Composite. Deshalb behandle ich lange Tasks als den eigentlichen Feind. Auf einem Dashboard, an dem ich gearbeitet habe, hat ein Filterwechsel im Handler synchron rund vierzigtausend Zeilen sortiert, und der Klick fühlte sich für etwa zweihundert Millisekunden tot an. Es so aufzuteilen, dass der Handler nur noch das Eingabefeld aktualisiert und dann mit scheduler.yield abgibt, bevor der teure Durchlauf startet, hat das Frame-Budget intakt gelassen, und die Interaktion hat sofort reagiert, obwohl die Gesamtarbeit identisch war.