Résumé

  • Le premier projet public du W3C, daté de septembre 2015, donnait aux pages requestIdleCallback : le navigateur choisit une période de repos probable et remet à la fonction un IdleDeadline qui estime le temps encore disponible.
  • Les textes de 2017 et de 2025 conservent ce partage. Le site découpe ses travaux et peut demander un délai maximal ; si le délai expire, didTimeout signale que la tâche a été rappelée sans véritable repos.

Un site moderne possède toujours une liste de choses « à faire quand il y aura cinq minutes ». Calculer une vue secondaire. Ranger des données locales. Préparer ce que la personne pourrait ouvrir ensuite. La liste a cette propriété commune à tous les bureaux : elle ne diminue jamais. Le navigateur, lui, doit répondre au doigt qui touche l’écran et dessiner la prochaine image sans demander au public de patienter pendant l’inventaire des trombones.

En 2015, les auteurs pouvaient déjà programmer une tâche avec setTimeout. Ce minuteur savait quand sonner, mais ignorait si le navigateur était sur le point de peindre une image ou de traiter un geste. Le premier projet public du W3C, le 17 septembre 2015, proposait de confier le choix du moment à celui qui connaissait l’agenda : l’agent utilisateur. La page demandait un rappel pendant une période libre. Le navigateur indiquait, dans l’objet IdleDeadline, combien de temps il pensait pouvoir lui laisser.

Cette estimation a un nom très concret, timeRemaining(). Elle oblige l’auteur à penser en portions. Faire une opération, regarder le temps qui reste, s’arrêter si la fenêtre se ferme, demander un nouveau passage pour la suite. Le projet de 2015 plafonnait la période de repos à 50 millisecondes ; une entrée de l’utilisateur pouvait rétrécir encore le créneau. Voilà un contrat plus précis qu’une vague promesse de « travail en arrière-plan » : l’occasion appartient au navigateur, le contenu du travail appartient au site.

Les exemples du projet initial montrent même un calcul que l’on affine petit à petit. Le choix est presque théâtral. La page arrive avec son boulier, fait quelques comptes et remet les meubles en place avant l’entrée du prochain visiteur. Mais le théâtre révèle une contrainte de fabrication. Une tâche monolithique qui prend deux secondes ne devient pas courtoise parce qu’on la lance depuis une fonction appelée « idle ». Il faut pouvoir l’interrompre entre deux morceaux utiles.

Le texte de candidature du 31 janvier 2017 et la proposition du 10 octobre 2017 ont gardé cette logique coopérative. Ils traitent aussi le cas de la salle qui ne se libère jamais. L’auteur peut préciser un timeout. Quand l’attente atteint cette limite, le rappel devient exécutable et didTimeout le signale. C’est une manière de sauver une tâche de l’oubli, avec une facture évidente : elle peut alors prendre du temps dans un moment déjà occupé. Le mot « urgent » reste facile à écrire dans un programme ; l’œil humain juge le résultat sur la fluidité de la page.

L’historique officiel du W3C fait suivre les textes de 2015 et 2017 par des versions ultérieures. Le projet de travail du 21 mai 2025 décrit toujours une période libre déterminée par le navigateur et un délai transmis au rappel. Dix années de rédaction n’ont pas déplacé le point décisif : la page présente des travaux candidats, mais le navigateur sait quand l’écran a besoin de son attention.

Pour un éditeur, la bonne question devient embarrassante : quelles tâches méritent vraiment de prendre ce répit ? Préparer une rubrique que la lectrice pourrait consulter bientôt a du sens. Remplir le moindre silence avec une corvée imposée par chaque script fabrique un embouteillage dans une ruelle. Le site doit mesurer la durée de ses morceaux de travail et accepter que certains attendent. Le lecteur, lui, ne voit aucun IdleDeadline. Il sent simplement que la page lui répond pendant que les petites affaires avancent en coulisses. C’est une réussite qui ressemble à une absence de spectacle.