Prioridades de scheduler.postTask para tareas web

La API Prioritized Task Scheduling permite etiquetar el trabajo de una página propia como user-blocking, user-visible o background. BotBrowser permite repetir un fixture autorizado y registrar estados visibles de finalización, orden y alternativa; no puede controlar el planificador del sistema operativo ni garantizar que un sitio de terceros observe un orden de cola concreto. Combina esta guía con medición del rendimiento y optimización del rendimiento cuando el resultado de la tarea deba vincularse a una decisión visible de la aplicación.

TL;DR

• Usa user-blocking solo para trabajo que mantiene utilizable la interacción actual, no como interruptor universal de velocidad.
• Usa user-visible para el trabajo necesario en el siguiente render y background para mantenimiento aplazable.
• Conserva un AbortSignal, una alternativa acotada y un resultado explícito para cada tarea publicada.
• Compara el estado de la tarea y el resultado visible; una prioridad es una sugerencia de planificación, no una garantía de latencia.

Contents

• Elegir una prioridad
• Publicar y cancelar trabajo
• Construir una alternativa
• Verificar el orden sin exagerar
• Conclusión práctica

Elegir una prioridad

La propuesta WICG Scheduling APIs define scheduler.postTask() para poner una función en cola con prioridad y señal opcionales. user-blocking es la sugerencia más fuerte y encaja con una acción corta que mantiene responsiva la entrada o la confirmación. user-visible es el valor predeterminado para el trabajo que sostiene el siguiente estado visible. background sirve para mantenimiento que puede esperar, como limpiar una caché o preparar una vista previa obsoleta.

La prioridad no promete tiempo de ejecución, justicia ni orden de pintura. El navegador puede ceder, pausar el documento, agrupar trabajo o rechazar una tarea antes de ejecutarla. Vincula cada decisión con un resultado visible: un resultado de filtro puede ser user-visible, mientras que un lote de analítica pertenece a background. No marques toda una tubería de render como user-blocking solo porque la inició un botón.

La referencia de MDN Scheduler.postTask() documenta los valores aceptados y la integración con TaskController. Comprueba la API en tiempo de ejecución y registra la versión del navegador cuando importe decidir compatibilidad. Un método disponible tampoco vuelve inocua una función larga; divide el trabajo costoso y cede entre fragmentos.

Publicar y cancelar trabajo

Crea un registro pequeño del propietario antes de publicar cada tarea. Debe contener taskId, priority, fixtureId, startedAt, finishedAt, outcome y cancelReason; no debe contener texto de página, identificadores de cuenta ni una URL completa. El identificador une un resultado visible con una decisión de cola sin convertirse en un perfil de larga duración.

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 posee la cancelación solo de esta tarea. Abortar antes de ejecutarla debe producir cancelled; no debe contarse como un éxito lento. Una función que lanza una excepción debe convertirse en failed después de conservar un estado de error utilizable. Mantén conectado el camino catch, porque una promesa rechazada sin tratar puede ocultar la acción original.

El controlador no interrumpe JavaScript que ya está ejecutándose. Una función larga sigue bloqueando el hilo principal hasta que cede o retorna. Para renderizar muchos elementos, procesa un lote limitado, programa el siguiente lote y vuelve a comprobar que la ejecución siga vigente. El artículo de Chrome sobre tareas priorizadas describe este modelo cooperativo; postTask no se convierte en un hilo preventivo.

Construir una alternativa

Detecta globalThis.scheduler?.postTask antes de elegir el camino preferido. La alternativa debe conservar el mismo resultado visible y regla de cancelación con una devolución en cola, setTimeout o el planificador existente de la aplicación. No debe elevar silenciosamente el trabajo de fondo a una acción bloqueante.

Condición	Camino preferido	Alternativa y resultado esperado
API disponible	postTask(callback, { priority: 'user-visible' })	Registra queued; termina con el mismo resultado visible
API ausente	No existe el objeto scheduler	Programa un callback limitado y mantiene utilizable la acción
Señal abortada	AbortError antes del callback	Marca cancelled; no renderiza datos obsoletos
Callback lanza	Promesa de tarea rechazada	Marca failed y muestra la acción de reintento existente
Trabajo obsoleto	taskId actual ya no coincide	Descarta el resultado y conserva el estado nuevo

La alternativa es un contrato de aplicación, no una prueba de que dos navegadores compartan el mismo tiempo del event loop. Conserva la prioridad como metadato aunque la implementación no pueda respetarla. Así una comparación posterior puede decir priority: background e implementation: timeout sin insinuar planificación nativa.

Evita una alternativa que ejecute todos los callbacks en un bucle sin límite. Los lotes grandes recrean el problema de las tareas largas que la API intenta aliviar. La guía de web.dev sobre tareas largas recomienda dividir el trabajo y medir el efecto visible. Un lote limitado con condición de parada se cancela y se explica mejor en soporte.

Verificar el orden sin exagerar

Usa un fixture sintético con tres tareas y una cancelación controlada. Publica input-feedback en user-blocking, results-render en user-visible y cache-refresh en background; después registra el primer estado visible y el resultado final de cada una. La afirmación útil es que la interacción actual sigue utilizable y que el trabajo obsoleto no la sobrescribe. No afirmes un orden universal cuando el navegador puede ceder o el documento puede quedar oculto.

Repite el fixture con la API disponible, con la API eliminada y con AbortController cancelado antes de ejecutar. Conserva browserVersion, viewport, fixtureId e implementation junto al resultado. Compara el primer campo que cambia en vez de recoger una traza ilimitada. Si cambia implementation, revisa la detección; si cambia outcome, revisa cancelación y propiedad; si cambia un frame visible, revisa el tamaño del callback.

Cuando el callback crea trabajo de workers, planificar workers con hardware concurrency explica por qué navigator.hardwareConcurrency es una pista de capacidad y no una garantía de cola; separa esa decisión del host de priority.

Usa medición del rendimiento del navegador con User Timing para el intervalo propio del fixture y mantén su duración separada del resultado de prioridad del scheduler.

BotBrowser puede cargar este fixture declarado en un contexto autorizado y registrar las etiquetas de estado visibles. No puede forzar el event loop de terceros, demostrar que una tarea se ejecutó antes de pintar ni garantizar que una compilación implemente la propuesta. Una repetición controlada aporta evidencia del fixture y de su entorno, no de todos los dispositivos o sitios.

Mantén mínima la telemetría de la cola. Un registro útil contiene fixtureId, taskId, priority, implementation, outcome y un intervalo de duración acotado. Elimina identificadores temporales tras la ventana de revisión y no exportes argumentos de callbacks ni contenido de páginas. Un experimento de prioridad debe mejorar una interacción propia sin justificar la recolección de datos de navegador no relacionados.

Al reintentar una tarea, crea un taskId nuevo y marca el anterior como superseded. Durante una navegación o desmontaje, aborta los controladores propios y libera referencias. Una tarea que termina después de desaparecer su propietario no debe actualizar una ruta nueva. Esta comprobación del ciclo de vida encuentra más defectos de producción que una captura del camino rápido.

Las guías operativas cercanas cubren límites distintos: medición del rendimiento del navegador explica cómo medir un intervalo propio, mientras escalar contextos del navegador trata leases y capacidad fuera del event loop de la página. Este artículo se centra en la cola de tareas del navegador y en los límites de interpretar la prioridad como evidencia.

Public sources

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

Conclusión práctica

Elige la prioridad más baja que conserve el contrato visible actual, adjunta un AbortSignal propio y conserva una alternativa limitada para navegadores sin scheduler.postTask. Registra queued, rendered, cancelled, failed y superseded en lugar de tratar la prioridad como una promesa de latencia. Repite el mismo fixture tras una actualización del navegador y limita el resultado a ese fixture y entorno.