Priorités scheduler.postTask pour les tâches web

L’API Prioritized Task Scheduling permet à une page contrôlée d’étiqueter son travail user-blocking, user-visible ou background. BotBrowser permet de rejouer un fixture autorisé et d’enregistrer les états visibles de fin, d’ordre et de repli ; il ne peut pas contrôler le planificateur du système d’exploitation ni garantir qu’un site tiers observe un ordre de file précis. Associez ce guide à la mesure des performances et à l’optimisation des performances lorsque le résultat doit soutenir une décision visible de l’application.

TL;DR

• Réservez user-blocking au travail qui maintient l’interaction courante utilisable, pas à toute action supposée rapide.
• Utilisez user-visible pour le prochain état affiché et background pour la maintenance différable.
• Gardez un AbortSignal, un repli borné et un résultat explicite pour chaque tâche publiée.
• Comparez l’état de la tâche et le résultat visible ; une priorité est une indication de planification, pas une garantie de latence.

Contents

• Choisir une priorité
• Publier et annuler le travail
• Construire un repli
• Vérifier l’ordre sans le surestimer
• Conclusion pratique

Choisir une priorité

La proposition WICG Scheduling APIs définit scheduler.postTask() pour placer un callback dans une file avec une priorité et un signal facultatifs. user-blocking est l’indication la plus forte et convient à une action brève qui garde la saisie ou le retour visuel réactif. user-visible est la valeur par défaut pour un travail nécessaire au prochain état affiché. background convient à la maintenance qui peut attendre, comme le nettoyage du cache ou la préparation d’un aperçu périmé.

Une priorité ne promet ni délai d’exécution, ni équité, ni ordre de peinture. Le navigateur peut céder, suspendre un document, regrouper le travail ou rejeter une tâche avant son exécution. Reliez chaque choix à un résultat visible : un filtre peut être user-visible, tandis qu’un lot analytique relève de background. Ne marquez pas toute une chaîne de rendu user-blocking parce qu’un bouton l’a déclenchée.

La référence MDN de Scheduler.postTask() décrit les valeurs acceptées et l’intégration de TaskController. Détectez l’API au moment de l’exécution et notez la version du navigateur lorsqu’une décision de compatibilité est nécessaire. Une méthode disponible ne rend pas un callback long inoffensif ; découpez le travail coûteux et cédez entre les fragments.

Publier et annuler le travail

Créez un petit enregistrement de propriétaire avant de publier chaque tâche. Il doit contenir taskId, priority, fixtureId, startedAt, finishedAt, outcome et cancelReason ; il ne doit pas contenir le texte de la page, des identifiants de compte ou une URL complète. Cet identifiant relie un résultat visible à une décision de file sans devenir un profil durable.

const controller = new TaskController({ priority: 'user-visible' });
const record = { taskId: 'results-17', priority: 'user-visible', outcome: 'queued' };

const task = scheduler.postTask(
  () => {
    record.outcome = 'rendered';
    renderResults();
  },
  { signal: controller.signal }
);

cancelButton.addEventListener('click', () => {
  controller.abort('superseded');
  record.outcome = 'cancelled';
  record.cancelReason = 'superseded';
});

task.catch(error => {
  record.outcome = error.name === 'AbortError' ? 'cancelled' : 'failed';
});

{
  "fixtureId": "queue-01",
  "taskId": "results-17",
  "priority": "user-visible",
  "implementation": "native-postTask",
  "outcome": "rendered",
  "cancelReason": null,
  "visibleState": "results-ready",
  "browserVersion": "155.0",
  "viewport": "1280x800"
}

TaskController possède uniquement l’annulation de cette tâche. Une annulation avant l’exécution doit produire cancelled, et non un succès lent. Un callback qui lève une exception devient failed après conservation d’un état d’erreur utilisable. Gardez le chemin catch attaché, car une promesse rejetée sans traitement peut masquer l’action initiale.

Le contrôleur n’interrompt pas le JavaScript déjà en cours. Un callback long bloque encore le thread principal jusqu’à son retour ou son abandon. Pour un rendu de nombreux éléments, traitez une tranche bornée, programmez la suivante et vérifiez que l’exécution reste actuelle. L’article de Chrome sur le Task Scheduling priorisé décrit ce modèle coopératif ; postTask ne devient pas un thread préemptif.

Construire un repli

Détectez globalThis.scheduler?.postTask avant de choisir le chemin préféré. Le repli doit conserver le même résultat visible et la même règle d’annulation avec un callback différé, setTimeout ou le planificateur déjà utilisé par l’application. Il ne doit pas transformer discrètement une tâche de fond en action bloquante.

Condition	Chemin préféré	Repli et résultat attendu
API disponible	postTask(callback, { priority: 'user-visible' })	Enregistrer queued, puis obtenir le même résultat visible
API absente	L’objet scheduler n’existe pas	Planifier un callback borné et garder l’action utilisable
Signal annulé	AbortError avant le callback	Marquer cancelled et ne pas afficher de données périmées
Callback en erreur	Promesse de tâche rejetée	Marquer failed et afficher l’action de nouvelle tentative
Travail périmé	Le taskId courant ne correspond plus	Ignorer le résultat et conserver l’état récent

Le repli est un contrat applicatif, pas la preuve que deux navigateurs partagent le même timing de l’event loop. Conservez la priorité comme métadonnée même si l’implémentation ne peut pas l’honorer. Une comparaison peut ainsi dire priority: background et implementation: timeout sans suggérer une planification native.

Évitez un repli qui exécute toutes les fonctions en attente dans une boucle illimitée. Les grands lots recréent le problème des longues tâches que l’API cherche à réduire. Le guide web.dev sur les longues tâches recommande de fractionner le travail et de mesurer l’effet visible. Une tranche bornée et une condition d’arrêt sont plus faciles à annuler et à expliquer au support.

Vérifier l’ordre sans le surestimer

Utilisez un fixture synthétique avec trois tâches et une annulation contrôlée. Publiez input-feedback en user-blocking, results-render en user-visible et cache-refresh en background, puis enregistrez le premier état visible et le résultat final de chacune. L’assertion utile est que l’interaction courante reste utilisable et que le travail périmé ne l’écrase pas. N’affirmez pas un ordre universel lorsque le navigateur peut céder ou masquer le document.

Répétez le fixture avec l’API disponible, avec l’API retirée et avec AbortController annulé avant l’exécution. Conservez browserVersion, viewport, fixtureId et implementation avec le résultat. Comparez le premier champ différent au lieu de recueillir une trace illimitée. Si implementation change, examinez la détection ; si outcome change, examinez l’annulation et la propriété ; si une image visible change, examinez la taille du callback.

Lorsque le callback crée du travail de worker, planifier les workers avec hardware concurrency rappelle que navigator.hardwareConcurrency est un indice de capacité et non une garantie de file ; gardez cette décision d’hôte distincte de priority.

Utilisez la mesure des performances du navigateur avec User Timing pour l’intervalle possédé par le fixture, puis séparez sa durée du résultat de priorité du scheduler.

BotBrowser peut charger ce fixture déclaré dans un contexte autorisé et enregistrer les étiquettes d’état visibles. Il ne peut pas forcer l’event loop d’un tiers, prouver qu’une tâche s’est exécutée avant une peinture ou garantir qu’une version implémente la proposition. Un rejeu contrôlé documente le fixture et son environnement, pas tous les appareils ni tous les sites.

Gardez la télémétrie de file minimale. Un enregistrement utile contient fixtureId, taskId, priority, implementation, outcome et un intervalle de durée borné. Supprimez les identifiants temporaires après la fenêtre de revue et n’exportez ni les arguments de callback ni le contenu de page. Une expérience de priorité doit améliorer une interaction possédée sans justifier la collecte de données de navigateur étrangères.

Lors d’une nouvelle tentative, créez un taskId distinct et marquez l’ancien superseded. Lors d’une navigation ou d’un démontage, annulez les contrôleurs possédés et libérez les références. Une tâche terminée après la disparition de son propriétaire ne doit pas modifier une nouvelle route. Ce contrôle du cycle de vie révèle davantage de défauts de production qu’une capture du chemin rapide.

Les guides opérationnels voisins traitent d’autres limites : la mesure des performances du navigateur explique un intervalle possédé, tandis que la montée en charge des contextes traite les leases et la capacité hors de l’event loop de la page. Ce texte reste centré sur la file de tâches et les limites d’une priorité considérée comme preuve.

Public sources

• WICG Scheduling APIs
• MDN: Scheduler.postTask()
• Chrome for Developers: Prioritized Task Scheduling
• web.dev: Optimize long tasks
• BotBrowser: Automation consistency

Conclusion pratique

Choisissez la priorité la plus basse qui préserve le contrat visible actuel, attachez un AbortSignal propre à la tâche et gardez un repli borné pour les navigateurs sans scheduler.postTask. Enregistrez queued, rendered, cancelled, failed et superseded au lieu de traiter la priorité comme une promesse de latence. Rejouez le même fixture après une mise à jour du navigateur et limitez le résultat à ce fixture et à cet environnement.