要約

  • W3C が2015年9月に公開した最初の草案は、ブラウザーが空くと予想する時間に処理を依頼する requestIdleCallback を示した。渡される IdleDeadline の timeRemaining() で残り時間を確かめられる。
  • 2017年と2025年の文書も、時間の判断はブラウザー、仕事の選択と分割はページという役割を保つ。期限を指定すれば、空き時間を待ち続けた処理を呼び出す道もある。

ウェブページには、来客が帰っても終わらない店の片づけに似た仕事がある。次に開くかもしれない画面を準備する。データを少し計算する。ローカルの記録を整える。どれも今すぐ目には入らない。それでも画面を動かすのと同じ場所で長々と作業すれば、読者がボタンを押したときに列ができる。裏方の仕事は、名前どおり裏にいてほしい。

かつての手軽な方法は setTimeout で後の時刻を予約することだった。だが時計は、予約した瞬間にブラウザーが次の絵を描いているか、指の動きを処理しているかを知らない。W3C の2015年9月17日の最初の公開草案は、予定表を持つ側に判断を任せた。ページが requestIdleCallback を呼ぶ。ブラウザーが空き時間を見込んだら処理を呼び、その時点での期限を IdleDeadline として渡す。

timeRemaining() は、その期限まであとどれほどあるかを見積もるための目盛りだ。ページは仕事を少し進め、目盛りを見て、残りが尽きる前に次回へ持ち越す。2015年の草案は一度の空き時間に50ミリ秒の上限を置いた。実際には入力などでさらに短くなる。50ミリ秒と書いてあるから50ミリ秒使い切ってよい、という職場の有給休暇ではない。時計は一緒に進み、急ぎの用事も割り込む。

草案の例は、計算を少しずつ進める。最初から最後まで走り切る処理を「空き時間用」と命名しても、走り始めた仕事は自分で止まらない。ここで必要なのは、処理を途中で手放せる形に切ることだ。一皿ずつ洗うなら客が来たときに手を拭ける。台所そのものを解体し始めたら、客は玄関で待つしかない。API が配るのは時間を読む手掛かりで、仕事の切り分けはサイト作者の腕に残った。

2017年1月の候補勧告と同年10月の勧告案には、逆向きの悩みもある。忙しいページでは、いつまでも空き時間が来ず、後回しの仕事が腐る。作者は timeout を指定できる。期限に達すると処理が呼ばれ、didTimeout がその経緯を知らせる。便利な非常口だが、そこから出てくる仕事は混雑した時間帯にも居場所を求める。すべての裏方が非常ベルを押せば、表の通路はたちまち仕事場になる。

W3C の公開履歴には2015年の初稿から2017年の段階、その後の改訂まで並ぶ。2025年5月21日の作業草案も、空き時間をブラウザーが定め、コールバックに期限を渡す構図を続けている。長い改訂のあいだ残ったのは、どちらが何を知っているかという素朴な分担だ。ブラウザーは描画と入力の予定を知る。サイトは自分の仕事の優先順と、その切りどころを知る。

読者には、この協議の名前は見えない。押したボタンがすぐ反応し、その合間に次の画面も用意されていれば十分だ。反対に、画面が引っかかるなら、まず「空き時間」に入れた処理の長さを疑うべきだ。小さな休憩時間を見つけたからといって、事務所の引っ越しを始める理由にはならない。