- Se descapó
- 20 de agosto de 2026 a las 22:18 UTC
- Autor
- Kamo
- Compromit
- 4c123b2
Cuatro componentes esperaron a que el hilo principal se quedara tranquilo antes de hacerlo su trabajo - el paquete de tostadas/consentimiento, el cromo de desplazamiento, el toque barrido de destino y la baliza de referencia y cada uno llamado requestIdleCallback. Cada uno tenía razón por sí mismo y equivocado. juntos: el navegador no reparte un período ocioso por llamante, drena cada llamada pendiente en la misma. Medido en la página de inicio a 4x CPU acelerado, los cuatro dispararon a 2.359 / 2.361 / 2.413 / 2.444 ms. Ese clúster de 85 ms es la larga tarea que el informe atribuyó al router trozos a los 2,4 s. Ahora pasan por una cola compartida que dirige un trabajo por período de ocioso y rinde al bucle de evento en el medio. El trabajo total es idéntico; llega como varias tareas cortas en lugar de una larga, que es lo que El tiempo de bloqueo total cuenta en realidad sólo la parte de una tarea pasada 50 ms es bloquear, por lo que cuatro tareas de 20 ms no cuestan nada donde una tarea de 80 ms cuesta 30 ms. onIdle devuelve un cancelador por lo que los dos sitios de llamadas con derribo real Semántica los mantened: la baliza no debe reportar una página que el lector tiene ya se fue, y el barrido de toque no debe correr después de desmontar. check-idle-queue.mjs falla la construcción en una solicitud directaIdleCallback fuera de la cola, porque la siguiente persona para aplazar algo llegará para ello y se verá correcto en revisión.