フロントエンドのJavaScriptが重いので、
サーバサイドのNode.jsに逃したいとのことですが、
不特定多数へ公開する事が目的ならばオススメ出来ません。
逆に自分一人で行うならば良い案になるかもしれません。
特にブラウザを開いている端末がスマホやノートPCといった貧弱なマシンで、
母艦の高性能なサーバマシンに処理を移譲したいケースであれば最善となりうるでしょう。
(イメージとしてはクラウド実行したゲーム)
ただし、それに飛びつく前に本当のボトルネックが何なのかをしっかり調査する必要があります。
現状が分からないので何とも言えませんので、見るべき所を羅列という形で上げていきます。
カクツキを解消出来ないか
そもそも何故カクツキが発生しているのでしょうか?
JavaScriptとして一番考えられる原因がDOMツリー操作です。
ブラウザの画面描画はDOMツリーというオブジェクトをメモリ上に展開し、
JavaScriptはブラウザが用意したDOMツリーを書き換えるAPIにお願いして画面の更新を促します。
これのコスパが非情に悪いです。
もしうねうね動く物理演算を、裏で大量のdivタグ作ってstyle要素を編集して操っているのであれば、
もはや物理演算云々の話ではありません。
DOMツリーがクソなので画面がカクついています終わり。
そこがボトルネックなのであれば、
せっせとWebSocketを使ってサーバサイドに逃がしても無駄です。
結局画面更新の負荷でブラウザは固まり、カク付くことでしょう。
まず下記を試しましょう。
DOMツリーより出来る事は少ないので多少コスト減になるか?
- DOMにデータを持たせているならJSの変数にデータを持たせる
DOM APIでのやり取りを極力減らす事が目的
JS自体は数万レベルの配列操作ならば結構高速にやってくれる
差分だけ賢く更新してくれるので、下手なDOM操作のコードを自分で書くよりもマシになる可能性
あくまで可能性程度
以下はそのボトルネックが本当に物理演算だったという前提で考えていきます。
そもそも物理演算の計算をサーバーサイドに逃すと言うことは、
GPU(グラフィックカード)を利用した方が得意なジャンルの計算ではないでしょうか?
もしそうならサーバーサイドに逃がす選択肢自体は悪くないように思えます。
Node.jsはGPU扱えますしね。
参考記事: JavaScriptでGPUを簡単に扱えるライブラリ「GPU.js」レビュー、並列処理で多次元の演算が爆速に
ですがまぁWebアプリの利用者全ての物理演算を
Webサーバのマシンに代わりにやれという状況になります。
一人や二人しか使わないのであれば最善でしょうけど、
もしWeb上に公開して不特定多数のユーザー達に利用してもらうつもりなら
1ヶ月何十万・何百万円するようなWebサーバを
AWS等から借りて運用する事になるかもしれません。
人気が出たら会社を立ち上げる等マネタイズが急がれるでしょう。
Node.jsのWebSocketが同時に捌ける接続数という制約もあります。
調査した感じだと数千人で頭打ちになり、その辺でも利用者に応じてサーバーマシンを増やす対策をしなければなりません。
Node.jsを捨てる選択肢も必要かもしれません。
参考記事: WebSocket大合戦:Clojure、C++、Elixir、Go、NodeJS、Ruby
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。