私はchromeのrequestAnimationframeで遊んでいて、実際にどのように動作するのか疑問に思いました。
キャンバスをロードして描画すると、安定した60FPSが得られます。クリックのようにオフセットを使用してスクロールし、マップの周りをドラッグすると、FPSは（期待どおりに）ドロップします...マップの周りのドラッグを停止すると、FPSは再び期待どおりに安定した60fpsに戻ります。
これがrequestAnimationframeのために審議されているのかどうか疑問に思うところは、ここにあります。FPSが低下するまでマップをドラッグすると、長時間30を下回り、ドラッグを停止すると上昇しますが、今回は30FPSに達し、上昇しません。ブラウザが30FPSがおそらく最良のオプションであると判断したように見えます。
これはブラウザによって意図的に行われていますか？私はこれが当てはまるかどうかを調べようとしています。長時間30fpsを下回らないと、60fpsになります。
はい、それはブラウザが実行できることです。
「それがどのように機能するのか」は、ここでは誰もが答えることができるものではありません。
その理由は、内部的には100％ブラウザ固有であるということです。
しかし、そうだと言っても間違いありません。ブラウザは、60Hzの更新ではなく、30Hzの更新にロックするタイミングを決定できます。
これが当てはまる理由の説明：
requestAnimationFrame()ベンダーが望む場合は、Page Visibility APIにも関連付けられています（Chromeの場合は非常に当てはまります）。基本的に、ページが表示されていない場合は、更新を1秒あたり数回に
遅くしたり、完全に一時停止したりできます。requestAnimationFrame()
その知識を考えると、2つのことのいずれかが起こっていると信じることは完全にもっともらしいです：
平均化されたパフォーマンスデータに基づいて、そこでのエクスペリエンスがより安定すると感じているため、意図的に30fpsで制限しています。
彼らは意図的にあなたを抑制していますが、海岸がクリアされた後、そして彼らが平均化されたパフォーマンスデータを使用している場合、システムにいくつかのバグ（または寛大ではない数学）があり、60に戻ることができません。それは問題の一部かもしれません。
いずれにせよ、それは少なくともほとんど意図的なものであり、唯一の未回答の質問は、なぜそれが30fpsに固執するのかということです。事後20分または30分放置して、その後いつでも元に戻るかどうかを確認しましたか？
Chrome DevToolsからタイムフレーム分析を実行して、アニメーション時間を遅くしている異端のJSを探すことができます。
https://developers.google.com/chrome-developer-tools/docs/timeline
RAFは、最も近い変更ではなく、変更をペイントするのに最適な場所を見つけます。したがって、RAFコールバックのJSが2フレームに相当する時間（60hzハードウェアではフレームあたり約16ms）を費やしている場合、FPSは30に低下します。
ポール・アイリッシュからボリス経由
実際、「現在、上限は1000 /（16 + N）fpsです。ここで、Nはコールバックの実行にかかるミリ秒数です。コールバックの実行に1000ミリ秒かかる場合は、1fps未満に制限されます。コールバックの実行に1ミリ秒かかる場合、約60fpsになります。」（thx、Boris）
http://www.paulirish.com/2011/requestanimationframe-for-smart-animating/