- Navios
- 20 de agosto de 2026 às 22:18 UTC
- Autor
- Kamo
- Enviar
- 4c123b2
Quatro componentes esperaram que o fio principal ficasse quieto antes de fazer seu trabalho — o pacote torrado/consent, o cromado de rolagem, o toque varrer o alvo e o farol de referência – e cada um chamado requestIdleCallback em si. Cada um estava certo sozinho e errado. em conjunto: o navegador não distribui um período ocioso por pessoa que liga, ele drena todas as chamadas pendentes no mesmo. Medida na página inicial a 4x CPU, os quatro disparados a 2.359 / 2.361 / 2.413 / 2.444 ms. Esse cluster 85 ms é a tarefa longa que o relatório atribui ao roteador bloco em ~2.4 s. Eles agora passam por uma fila compartilhada que executa um trabalho por período ocioso e retorna ao loop do evento no meio. O trabalho total é idêntico; chega como várias tarefas curtas em vez de uma longa, que é o que Bloqueamento total O tempo realmente conta — apenas a parte de uma tarefa passado 50 ms está bloqueando, então quatro tarefas de 20 ms não custam nada onde uma tarefa de 80 ms custa 30 ms. onIdle retorna um cancelamento para que os dois sites de chamadas com verdadeira demolição semântica mantê-los: o farol não deve relatar uma página que o leitor tem já saiu, e a varredura de toque não deve correr após desmontar. check-idle-queue.mjs falha na compilação de um pedido diretoIdleCallback fora da fila, porque a próxima pessoa a adiar algo irá chegar para ele e ele vai olhar correto na revisão.