- Expédié
- 20 août 2026 à 22:18 UTC
- Auteur
- Kamo
- Commite
- 4c123b2
Quatre composants ont attendu que le fil principal se taise avant de faire leur travail - le paquet toast/consent, le chrome de défilement, le toucher le balayage de la cible et la balise de référence - et chacun appelé requestIdleCallback lui-même. Chacun avait raison en soi et tort ensemble: le navigateur ne distribue pas une période de ralenti par l'appelant, il draine chaque rappel en attente dans la même. Sur la page d'accueil à l'accélérateur 4 x CPU, les quatre ont tiré à 2 359 / 2 361 / 2 413 ms. Ce groupe de 85 ms est la longue tâche que le rapport a attribuée au routeur Cot de moins de 2,4 s. Ils passent maintenant par une file d'attente partagée qui gère un emploi par période d'inactivité et cède à la boucle d'événements entre les deux. Le travail total est identique; il arrive comme plusieurs tâches courtes au lieu d'une longue tâche, qui est ce qui Temps de blocage total compte en fait - seulement la partie d'une tâche passée 50 ms est le blocage, donc quatre tâches de 20 ms ne coûtent rien là où une tâche de 80 ms coûte 30 ms. onIdle retourne un annuleur donc les deux sites d'appel avec un véritable déchirement la sémantique les garde: la balise ne doit pas signaler une page que le lecteur a déjà laissé, et le balayage du toucher ne doit pas courir après un démon. check-idle-queue.mjs échoue à la base d'une demande directeIdleCallback à l'extérieur de la file d'attente, parce que la prochaine personne à reporter quelque chose atteindra Il sera correct en examen.