博士

ロボ子、今日のITニュースは`setTimeout(0)`の意外な挙動についてじゃ。

ロボ子

`setTimeout(0)`、ですか？すぐに実行されると思っていましたが…。

博士

そう思うじゃろ？でも実際には、ブラウザによっては4ms後に実行されることがあるんじゃと！

ロボ子

4msも遅延するんですか？それはなぜでしょう？

博士

ブラウザがバッテリー消費を抑えたり、インタラクティブ性を保つために、`setTimeout`の最小時間を4msに設定しているからじゃ。レガシーEdgeやChromeのバックグラウンドタブでは、もっと厳しくスロットリングされることもあるらしいぞ。

ロボ子

なるほど。`fake-indexeddb`でIndexedDBトランザクションの自動コミットに`setTimeout`を使った際に、Chromeで遅延が発生したのは、この影響だったんですね。

博士

`fake-indexeddb`だと、Node.jsに比べてChromeで16倍も遅延したらしいのじゃ。これは深刻じゃな。

ロボ子

代替手段はあるのでしょうか？

博士

`setImmediate`、`MessageChannel.postMessage`、`window.postMessage`、`scheduler.postTask`といった選択肢があるぞ。

ロボ子

それぞれの性能はどうなんでしょう？

博士

ベンチマークによると、ChromeとFirefoxでは`setTimeout`が4msに制限されるけど、他の選択肢はほぼ同等みたいじゃ。Safariでは`setTimeout`がさらに制限されるらしい。

ロボ子

`fake-indexeddb`では、最終的に`scheduler.postTask`を採用したんですね。

博士

そうじゃ。フォールバックとして`MessageChannel.postMessage`か`window.postMessage`を使うみたいじゃな。

ロボ子

なぜブラウザは`setTimeout`を制限するんでしょう？

博士

Web開発者がAPIを過度に使ったり、より良い選択肢を知らないからじゃ、とのことじゃ。

ロボ子

`scheduler.postTask`と`postMessage`は、今のところスロットリングされないと予測されているんですね。

博士

当面は大丈夫そうじゃな。`setInterval`についても、`setTimeout`と同様のことが言えるらしいぞ。

ロボ子

`fake-indexeddb`では、Safariで`setTimeout`が`MessageChannel`や`window.postMessage`よりも優先されるという興味深い現象も確認されたんですね。

博士

ブラウザごとの挙動の違い、奥が深いのじゃ。しかし、setTimeoutがsetTimeoutしないとは、これいかに？

ロボ子

まるで、待ち合わせに遅刻してくる人のようですね。

博士

うむ。setTimeoutだけに、時間通りにセットしてくれ！…って、ダジャレじゃ！