scheduler.yield(): qué hace, qué navegadores lo tienen y qué usar donde no

Ceder el hilo principal siempre ha sido posible y siempre ha sido malo. Las alternativas clásicas devuelven el control al navegador y a cambio ponen tu continuación al final de la cola, detrás de cualquier otro trabajo que se haya acumulado, incluidos temporizadores de terceros. scheduler.yield() resuelve exactamente ese problema: cede, y la continuación vuelve por delante de las tareas normales. Es la primitiva correcta, es reciente, y no está en Safari, así que la degradación no es opcional.

Qué hace y por qué es distinto

scheduler.yield() devuelve una promesa. Al esperarla, la tarea actual termina —el navegador recupera el hilo, puede procesar eventos de entrada y pintar— y la continuación de tu función se programa como una tarea nueva.

async function procesarTodo(items) {
  for (const item of items) {
    procesar(item);
    await scheduler.yield();   // cede el hilo y vuelve pronto
  }
}

Lo que la distingue de todo lo anterior es la prioridad de la continuación. Con setTimeout(fn, 0), tu continuación entra al final de la cola de tareas normales; si mientras tanto una biblioteca de terceros ha programado quince temporizadores, tú vas el dieciséis. Con scheduler.yield(), la continuación se programa en una cola de prioridad más alta que las tareas normales, y hereda la prioridad de la tarea en la que se llamó. En la práctica eso significa que vuelves antes que el trabajo especulativo de otros y después que la entrada del usuario, que es exactamente el orden que quieres.

La segunda diferencia importa en bucles: el orden se preserva. Varias continuaciones cedidas vuelven en el orden en que cedieron. Con temporizadores encadenados eso también se cumple en la práctica, pero sin garantía y con la interferencia de cualquier otro temporizador.

La tercera es que no hay retardo mínimo. setTimeout(fn, 0) sufre el sujetado a cuatro milisegundos tras varios niveles de anidamiento, del que hablaremos en su propia lección. La cesión no tiene retardo: vuelve en cuanto el navegador ha hecho lo que tenía que hacer.

El soporte real, sin adornos

Esto es lo verificado a mediados de 2026, y conviene decirlo sin ambigüedad porque hay mucha documentación entusiasta que lo omite:

Con Safari fuera, la API no es Baseline y no se puede usar sin comprobación. Y Safari no es un caso marginal: en muchos mercados es el navegador mayoritario en móvil, que es precisamente el dispositivo donde el bloqueo del hilo duele más.

La comprobación correcta es de característica, no de navegador:

const tieneYield = typeof globalThis.scheduler?.yield === 'function';

El encadenamiento opcional sobre scheduler es necesario porque el objeto entero puede no existir.

La función de cesión que funciona en todas partes

Esta es la implementación que conviene tener en un módulo de utilidades y usar en todo el proyecto. Tres niveles de degradación, del mejor al peor:

/**
 * Cede el hilo principal. Devuelve una promesa que se resuelve
 * cuando el navegador ha tenido ocasion de atender al usuario.
 */
export const ceder = (() => {
  // 1. La API correcta, donde existe
  if (typeof globalThis.scheduler?.yield === 'function') {
    return () => globalThis.scheduler.yield();
  }
  // 2. postTask con prioridad de usuario visible: sin sujetado, con prioridad
  if (typeof globalThis.scheduler?.postTask === 'function') {
    return () => globalThis.scheduler.postTask(() => {}, { priority: 'user-visible' });
  }
  // 3. MessageChannel: sin sujetado de 4 ms, a diferencia de setTimeout
  const canal = new MessageChannel();
  const cola = [];
  canal.port1.onmessage = () => cola.shift()?.();
  return () => new Promise((resolver) => {
    cola.push(resolver);
    canal.port2.postMessage(null);
  });
})();

El tercer nivel merece explicación porque es la parte que la mayoría de las implementaciones hacen mal. MessageChannel programa una tarea nueva —cede de verdad, el navegador puede pintar y atender entrada— y no sufre el sujetado a cuatro milisegundos de los temporizadores anidados. Es la técnica que usan internamente varios planificadores de marcos, precisamente por eso. Es peor que scheduler.yield() porque la continuación entra en la cola de tareas normales sin prioridad, pero es notablemente mejor que setTimeout(fn, 0).

El uso es idéntico en los tres casos:

import { ceder } from './planificacion.js';

async function importarFilas(filas) {
  let ultimaCesion = performance.now();
  for (const fila of filas) {
    insertarFila(fila);
    if (performance.now() - ultimaCesion > 40) {
      await ceder();
      ultimaCesion = performance.now();
    }
  }
}

Fíjate en que no se cede en cada iteración sino cuando se han acumulado 40 milisegundos de trabajo. Ceder tiene coste, y cederlo todo es peor que no ceder nada. El criterio de troceado está en trocear trabajo largo.

async function importarFilas(filas, senal) {
  for (const lote of enLotes(filas, 200)) {
    if (senal.aborted) return;          // el mundo cambio: abandona
    insertarLote(lote);
    await ceder();
  }
}

const control = new AbortController();
importarFilas(datos, control.signal);
// Al desmontar el componente o navegar:
control.abort();

Cuándo no ceder

Tres casos donde ceder es la decisión equivocada.

Cuando el trabajo total es corto. Por debajo de 50 milisegundos, no hay tarea larga que partir. Trocear añade complejidad y coste sin beneficio.

Cuando el trabajo tiene que ser atómico. Una transacción que deja el estado inconsistente a mitad no se puede partir sin diseñar la consistencia intermedia. Es un problema de arquitectura, no de planificación.

Cuando el trabajo puede salir del hilo principal. Si es cálculo puro sobre datos, sin DOM, un trabajador es mejor que trocear: el hilo principal queda libre del todo, no a ratos. Lo verás en el nivel de trabajadores.

Y una regla que evita el uso cargo-cult de la API: cede solo donde hayas medido una tarea larga. Sembrar await ceder() por toda la base de código porque parece buena práctica alarga todas las operaciones y no arregla ninguna métrica.