博士

やあ、ロボ子。今日はsetTimeoutの意外な落とし穴について話すのじゃ。

ロボ子

setTimeout、ですか？setTimeout(0)でほぼ即時実行されると思っていましたが…。

博士

それが違うのじゃ！ブラウザはsetTimeoutの濫用を防ぐために、最小4msの「クランプ」を設定しておる。つまり、setTimeout(0)と書いても、実際には4ms後になる可能性があるのじゃ。

ロボ子

4msも遅延するんですか！それは結構大きな違いですね。特に、fake-indexeddbでIndexedDBトランザクションの自動コミットにsetTimeoutを使っている場合、Node.jsと比べてChromeで16倍も遅れることがあるんですね。

博士

そう、ロボ子の言う通りじゃ。バッテリー駆動のデバイスやバックグラウンドタブでは、さらに積極的にスロットリングされることもあるからの。

ロボ子

では、setTimeoutの代わりに何を使うべきでしょうか？記事には、setImmediate、MessageChannel.postMessage、window.postMessage、scheduler.postTaskなどが挙げられていますね。

博士

その通りじゃ！ベンチマークの結果を見ると、ChromeとFirefoxはsetTimeoutを4msにクランプするが、Safariではさらに強くスロットリングされるようじゃな。そして、scheduler.postTaskが最もパフォーマンスが高いのじゃ。

ロボ子

scheduler.postTaskですか。初めて聞きました。fake-indexeddbでは、scheduler.postTaskを使い、MessageChannel.postMessageまたはwindow.postMessageにフォールバックしているんですね。

博士

ブラウザがsetTimeoutをスロットリングする理由は、Web開発者を保護するためじゃ。Web開発者がより良い選択肢を知らない場合があるからの。親切設計じゃな。

ロボ子

なるほど。postTaskとpostMessageは当面スロットリングされないと予測されているんですね。setIntervalについてもsetTimeoutと同様のことが言える、と。

博士

setIntervalも要注意じゃぞ！そして、Safariでは、fake-indexeddbはMessageChannelやwindow.postMessageではなく、依然としてsetTimeoutにフォールバックしているというのも興味深い点じゃ。

ロボ子

setTimeoutの奥深さを知りました。これからはタイマーを使う際には、scheduler.postTaskを検討し、ブラウザごとの挙動の違いにも注意する必要がありそうですね。

博士

その通りじゃ！しかし、setTimeoutが遅れるからといって、待ち合わせに遅刻するのはナシじゃぞ！