setTimeout de cero y por qué es la peor forma de ceder

setTimeout(fn, 0) ha sido durante veinte años la forma de ceder el hilo en JavaScript, y funciona: la tarea actual termina, el navegador recupera el control, la continuación se ejecuta después. El problema es todo lo demás. Sufre un retardo mínimo impuesto por la especificación, pierde el turno frente a cualquier otro trabajo programado, y en un bucle de cien iteraciones ese coste acumulado convierte una operación de 400 milisegundos en una de varios segundos. Conviene entender exactamente por qué, porque es lo que justifica todo lo demás de este nivel.

El sujetado a cuatro milisegundos

La especificación de HTML establece que, cuando el nivel de anidamiento de temporizadores supera cinco, el retardo se eleva a un mínimo de cuatro milisegundos. «Anidamiento» significa un setTimeout programado desde dentro de la devolución de llamada de otro, que es exactamente lo que hace un bucle troceado.

// A partir de la sexta iteracion, cada vuelta cuesta al menos 4 ms de espera
function procesarConTimeout(items, i = 0) {
  if (i >= items.length) return;
  procesar(items[i]);
  setTimeout(() => procesarConTimeout(items, i + 1), 0);
}

Con mil elementos, ese bucle paga cerca de cuatro segundos solo en esperas, con el hilo principal ocioso. El trabajo real puede ser de trescientos milisegundos.

El origen de la regla es histórico y razonable: en los años en que se fijó, había páginas con bucles de temporizadores que consumían el cien por cien de una CPU y agotaban la batería de portátiles. El sujetado fue una medida de protección, se implementó en todos los navegadores y se acabó escribiendo en la especificación para que el comportamiento fuese consistente.

Un matiz que sorprende: el sujetado no aplica a un setTimeout no anidado. Un temporizador programado desde un manejador de evento o desde el nivel superior se ejecuta con retardo casi nulo. El problema aparece solo en el encadenamiento, que es justo el patrón del troceado.

Otro matiz importante para no diagnosticar mal: en pestañas en segundo plano el sujetado sube a un segundo o más, y tras unos minutos la pestaña puede congelarse por completo. Un trabajo troceado con temporizadores que el usuario deja en otra pestaña puede tardar horas.

La pérdida de prioridad

El segundo problema es peor en páginas reales y menos conocido.

setTimeout encola en la cola de tareas normales. Esa cola es compartida con todo lo demás: la analítica de terceros, el gestor de etiquetas, el chat de soporte, la biblioteca de pruebas A/B. Cada uno de ellos programa temporizadores.

En una página con cinco scripts de terceros, tu continuación no es la siguiente tarea: es la que llegue cuando le toque. Si esos terceros han programado veinte devoluciones de llamada y cada una tarda 15 milisegundos, tu siguiente trozo empieza 300 milisegundos después de haber cedido.

Y ese coste es invisible en desarrollo, donde no hay terceros cargados, y aparece en producción de forma variable según qué scripts hayan terminado de cargar. Es una de las razones de que el rendimiento en producción se parezca tan poco al local.

scheduler.yield() no tiene este problema porque su continuación va en una cola de prioridad superior. MessageChannel tampoco tiene el sujetado, aunque sí comparte la cola normal.

La comparación, medida

Este banco se puede pegar en la consola de cualquier navegador y da los cuatro números en unos segundos:

async function medirCesion(nombre, cederFn, vueltas = 200) {
  const t0 = performance.now();
  for (let i = 0; i < vueltas; i++) {
    // Trabajo minimo: lo que medimos es el coste de ceder
    let x = 0; for (let j = 0; j < 1000; j++) x += j;
    await cederFn();
  }
  const total = performance.now() - t0;
  console.log(`${nombre.padEnd(22)} ${total.toFixed(0)} ms total, ${(total / vueltas).toFixed(2)} ms por cesion`);
}

const canal = new MessageChannel();
const colaMC = [];
canal.port1.onmessage = () => colaMC.shift()?.();
const cederMC = () => new Promise((r) => { colaMC.push(r); canal.port2.postMessage(null); });

await medirCesion('setTimeout(0)', () => new Promise((r) => setTimeout(r, 0)));
await medirCesion('MessageChannel', cederMC);
if (globalThis.scheduler?.postTask) {
  await medirCesion('scheduler.postTask', () => scheduler.postTask(() => {}, { priority: 'user-visible' }));
}
if (globalThis.scheduler?.yield) {
  await medirCesion('scheduler.yield', () => scheduler.yield());
}

Los órdenes de magnitud que se obtienen en un navegador de escritorio sin carga, y que conviene reproducir en tu propio entorno porque varían:

La diferencia de un orden de magnitud es real y se nota en cuanto hay más de unas decenas de cesiones. Y en una página con terceros activos, la columna de setTimeout se degrada mucho más que las otras tres, porque a los cuatro milisegundos se suma la espera en cola.

Cuándo setTimeout sigue siendo correcto

No es una API mala; es una API para otra cosa. Los usos legítimos:

Retardo real. Cuando de verdad quieres esperar un tiempo: mostrar un mensaje durante tres segundos, reintentar tras una pausa, agrupar por tiempo. Es exactamente su propósito.

Ceder una sola vez, no en bucle. Un único setTimeout(fn, 0) para dejar que el navegador pinte antes de una operación pesada no está anidado, no sufre sujetado, y es perfectamente razonable.

// Correcto: una cesion, no un bucle. Deja pintar el indicador antes de bloquear.
mostrarIndicador();
setTimeout(() => {
  const resultado = trabajoPesadoAtomico();
  mostrarResultado(resultado);
}, 0);

Como último respaldo de una cadena de degradación, cuando ni scheduler ni MessageChannel estén disponibles, cosa que hoy no ocurre en ningún navegador con soporte.

Y el uso que hay que erradicar: el bucle troceado con temporizadores encadenados. Ese patrón, escrito en miles de bases de código, es el que esta lección existe para sustituir.

// Correcto: hacer el cambio visual, esperar a que se pinte, y despues trabajar
elemento.classList.add('activo');
requestAnimationFrame(() => {
  requestAnimationFrame(() => {
    // Aqui el fotograma con 'activo' ya se presento
    hacerTrabajoPesado();
  });
});