Me explique o que o navegador realmente faz entre um handler de clique executar e o próximo frame aparecer na tela.

O handler de clique roda até o fim como uma única task. Todas as microtasks que ele enfileirou, incluindo callbacks de promises resolvidas, são drenadas em seguida, antes de qualquer outra coisa acontecer. Só então, se um frame estiver previsto, o navegador roda os callbacks de requestAnimationFrame e passa por style, layout, paint e composite. Uma long task ou uma cadeia infinita de microtasks atrasa esse frame, e usuários leem o atraso como travamento.

O handler em si é uma task na main thread, então roda do começo ao fim sem nada interrompendo. Assim que retorna, o navegador drena a fila de microtasks, então qualquer continuação de await ou callback de then de promise roda ali mesmo, e se essas continuarem enfileirando mais microtasks o navegador nunca tem chance de pintar. Quando essa fila esvazia, e só se um frame estiver de fato previsto, o navegador roda os callbacks de requestAnimationFrame, recalcula style, faz layout, pinta e compõe. É por isso que trato long tasks como o inimigo real. Num dashboard em que trabalhei, uma troca de filtro fazia uma ordenação síncrona de umas quarenta mil linhas dentro do handler, e o clique parecia morto por uns duzentos milissegundos. Dividir aquilo para o handler só atualizar o input, e então devolver o controle com scheduler.yield antes da passada cara, manteve o orçamento de frame intacto e a interação passou a responder de imediato, mesmo com o trabalho total idêntico.