Resumen

  • El primer borrador público del W3C, de septiembre de 2015, permitió solicitar una función para un período que el navegador prevé libre. IdleDeadline comunica una estimación del tiempo restante.
  • Los textos de 2017 y 2025 mantienen el reparto: el navegador encuentra el hueco, la página escoge la tarea y la divide en porciones. Un plazo opcional puede llamar a la función aunque el hueco nunca aparezca.

Hay páginas que se comportan como ese vecino que, en cuanto ve el ascensor vacío, pretende subir un sofá. Antes de que la persona toque un botón, el sitio quiere procesar datos, guardar estados y preparar una pantalla que tal vez nadie visite. El navegador, sin embargo, tiene un oficio más visible: responder a los dedos, mover una animación y pintar el siguiente cuadro. El rato entre una obligación y otra es pequeño, irregular y muy codiciado.

Durante años, un autor podía recurrir a setTimeout para volver más tarde. El reloj fijaba un momento, sin saber si coincidiría con una pulsación o con el dibujo de la pantalla. El primer borrador público del W3C, fechado el 17 de septiembre de 2015, ofreció una salida más sensata: requestIdleCallback. El sitio solicita un turno y el navegador lo convoca cuando espera un período ocioso. La función recibe un IdleDeadline, que informa del tiempo que el navegador calcula disponible.

La herramienta decisiva es timeRemaining(). El código puede hacer una parte del trabajo, consultar cuánto queda y volver a pedir turno para el resto. El texto de 2015 limitaba cada período de inactividad a 50 milisegundos; un gesto inesperado podía acortarlo. El navegador conserva el calendario porque ve sus propias citas. La página conserva la lista de tareas porque conoce su producto. La fluidez depende de que ambos se crean esa división del trabajo.

El ejemplo de cálculo incremental del borrador parece humilde: avanzar un poco, comprobar el reloj, seguir en otra ocasión. Su lección es amplia. Una tarea enorme, escrita dentro de una función de «inactividad», seguirá ocupando el hilo mientras se ejecuta. El nombre de la función no corta un cálculo por la mitad. El autor tiene que separar las unidades de trabajo y dejar puntos donde sea posible devolver el control. Es menos glamuroso que inventar otra API y bastante más útil para quien intenta pulsar un enlace.

El texto de Candidata a Recomendación de enero de 2017 y la Propuesta de Recomendación de octubre de ese año recogieron también el problema inverso: una página muy ocupada puede dejar una tarea secundaria esperando sin fin. El autor puede añadir un timeout. Al vencer, la función queda lista para ejecutarse y didTimeout indica por qué fue convocada. Es una salida para una cola atascada, pero consume tiempo en un momento que quizá ya tiene dueño. Si cada script invoca esa salida, el ascensor vuelve a llenarse de sofás.

El historial de publicaciones del W3C sitúa el primer borrador en 2015 y registra las etapas posteriores. El borrador de trabajo del 21 de mayo de 2025 continúa describiendo períodos de inactividad definidos por el agente de usuario y funciones que reciben una estimación de plazo. El mecanismo sobrevivió porque la información que necesita sigue repartida: el navegador sabe cuándo está libre; el sitio sabe qué desea adelantar.

Para un editor de la web, la elección interesante es editorial en el sentido más doméstico de la palabra: qué trabajo se hace ahora y cuál espera. Preparar un contenido probable puede reducir una demora futura. Ejecutar todos los scripts que se autoproclaman imprescindibles puede arruinar el presente. Una página veloz no es la que nunca tiene tareas pendientes; es la que sabe dejar alguna pendiente cuando entra el lector. Nadie ve el contrato con IdleDeadline. Se nota cuando el botón responde y el sofá todavía no bloquea el ascensor.