Resumo

  • O primeiro rascunho público do W3C, em setembro de 2015, apresentou requestIdleCallback: a página pede para trabalhar quando o navegador prevê um período ocioso e recebe um IdleDeadline com a estimativa do tempo restante.
  • Os textos de 2017 e 2025 mantiveram a escolha do horário com o navegador e a escolha da tarefa com a página. Um prazo opcional pode chamar o trabalho mesmo quando a calmaria não chega.

Toda página moderna guarda uma gaveta de pequenos serviços. Processar dados em partes, preparar algo que o leitor talvez abra, acertar registros locais. Isolados, parecem inofensivos. Juntos, conseguem deixar um botão tão ágil quanto uma repartição na hora do almoço. O navegador tem compromissos que o leitor percebe imediatamente: mostrar a próxima imagem e responder ao dedo. Para esses compromissos, o tempo livre da página precisa ser realmente livre.

A solução antiga era marcar um horário com setTimeout. O alarme disparava sem saber se o navegador estaria naquele segundo desenhando a interface. O primeiro rascunho público do W3C, de 17 de setembro de 2015, deixou o convite nas mãos de quem conhece a agenda. A página chama requestIdleCallback; o navegador espera por um período em que acredita poder ceder o controle. Ao chamar a função, entrega um IdleDeadline. O método timeRemaining() mostra quanto tempo, segundo a estimativa naquele instante, ainda cabe no intervalo.

É uma informação pequena com grandes consequências. O autor pode fazer uma parte do trabalho, olhar o relógio, parar e pedir outra oportunidade. O texto de 2015 limitava a duração de um período ocioso a 50 milissegundos. Uma interação nova pode apertar ainda mais essa janela. Por isso a tarefa tem de aceitar cortes. Chamar uma rotina longa de “trabalho ocioso” muda apenas a placa na porta. Se a rotina toma o espaço inteiro, o clique do leitor continua do lado de fora esperando.

O exemplo do primeiro documento usa um cálculo que melhora aos poucos. A página roda algumas etapas, consulta o tempo disponível e retoma depois. Não há heroísmo nessa técnica; há educação. É a diferença entre lavar alguns pratos enquanto a cozinha está vazia e desmontar o encanamento porque o cozinheiro saiu por meio minuto. O navegador oferece a pausa. O site precisa saber quais etapas cabem nela e onde interrompê-las sem perder o fio.

A Candidata a Recomendação de 31 de janeiro de 2017 e a Proposta de Recomendação de 10 de outubro de 2017 também lidaram com a espera prolongada. Se o navegador nunca encontra sossego, uma tarefa pode ficar esquecida. O autor pode especificar timeout. Quando o prazo vence, a função ganha chance de rodar; didTimeout informa por que ela foi chamada. É uma saída para a fila, mas pode colocar o serviço em horário de movimento. Cada site pode escrever que sua própria tarefa é urgente. A interface paga a conta quando todos fazem isso ao mesmo tempo.

O histórico de publicações do W3C acompanha a ideia do primeiro texto até as revisões seguintes. O rascunho de trabalho de 21 de maio de 2025 continua a descrever períodos ociosos definidos pelo navegador e uma função que recebe um prazo. A divisão atravessou uma década porque resolve uma assimetria concreta: o navegador conhece a fila de entradas e desenhos; cada página conhece a utilidade dos próprios serviços.

Quem mantém um site precisa decidir o que merece entrar nessa janela. Preparar a próxima seção pode poupar uma espera real. Encher todo intervalo com tarefas que cada módulo declarou indispensáveis produz uma página ocupada consigo mesma. O leitor não quer saber quem recebeu um IdleDeadline. Quer tocar, rolar e obter resposta. Quando isso acontece enquanto a arrumação avança, o acordo funcionou sem precisar aparecer no palco.