SSRがサーバ負荷を増やす理由 ― CPU使用率との関係

SSRは「通信が重い」のではなく「計算が増える」

SSR（Server Side Rendering）を導入すると、しばしば発生するのが「サーバが急に重くなった」という現象です。
回線帯域を増やしたのに改善しない、DBを高速化してもCPUが張り付く。このとき疑われがちなのはネットワークやデータベースですが、原因はそこではないことが多いです。

SSRは通信処理ではなく、計算処理をサーバへ移動させる技術です。
そのためボトルネックはI/OではなくCPUに現れます。

SPAとSSRでサーバの役割はどう変わるか

SPAとSSRのリクエスト処理の違いを整理します。

SPAの場合、サーバは主に次の仕事をします。

• APIのJSONを返す
• 静的ファイルを配信

返すデータは構造化されたテキストです。ブラウザが受け取り、画面の描画はクライアント側で行われます。

一方SSRでは、サーバがブラウザの代わりに描画処理を行います。

• データ取得
• テンプレート処理
• コンポーネント実行
• HTML生成

つまりサーバは「APIサーバ」から「レンダリングエンジン」に変わります。

なぜCPU使用率が上がるのか

HTML生成は軽い文字列処理に見えますが、実際にはJavaScript実行です。
React/VueのSSRでは、全コンポーネントのレンダリング関数が実行されます。

処理内容：

• 仮想DOM生成
• 差分計算
• 文字列化
• エスケープ処理

これらはすべてCPU計算です。
特にNode.jsはシングルスレッドで動作するため、1リクエストがCPUを占有すると他のリクエストが待ちます。

結果として、CPU使用率100%と同時にレスポンス遅延が発生します。

具体的な比較

同じページを表示する場合の処理量は次のようになります。

方式	サーバの仕事
SPA	JSON生成のみ
SSR	HTML生成（描画処理込み）

JSON生成は単なるデータ整形です。
しかしHTML生成はUIの組み立て処理です。
つまりSSRは「API処理＋フロントエンド実行」をサーバで行っています。

同時接続数との関係

CPU負荷はアクセス数に比例します。

例：

1ページ生成に50msのCPU時間が必要
→ 1秒で処理できる最大リクエストは約20件

もし毎秒100リクエスト来ると、80件は待機します。
この待機がレスポンスタイム増加として現れます。

ネットワークは帯域が余っていても、CPUが詰まるとサイトは遅くなります。

よくある誤解：キャッシュすれば解決？

キャッシュは有効ですが万能ではありません。

キャッシュが効く条件：

• 同一URL
• 同一レスポンス

しかし次のページでは効きません。

• マイページ
• 検索結果
• 個別最適化表示

これらは毎回レンダリングが必要です。
つまりトラフィックの質によって負荷は大きく変わります。

Node.js特有の問題

SSRで負荷が顕著になる理由の一つが、Node.jsのイベントループです。

Node.jsは並列処理が得意ですが、それはI/O待ちがある場合です。
SSRはCPU計算中心のため、イベントループがブロックされます。

結果：

• 新規接続受付が遅れる
• タイムアウト増加
• スパイクに弱い

これはAPIサーバでは起きにくい現象です。

対策として行われること

一般的な対策は次の通りです。

• CDNキャッシュ
• HTMLキャッシュ
• ISR（再生成）
• レンダリング分離（BFF構成）
• ワーカープロセス増加

つまり「速く描画する」より「描画回数を減らす」方向の最適化が行われます。

注意点：サーバ増強だけでは解決しない

CPUコア数を増やしても、必ずしも比例して改善しません。
理由は1リクエストが長時間CPUを占有するためです。

また、GC（ガベージコレクション）も影響します。
SSRでは大量のオブジェクトが生成され、GC停止時間がレスポンス遅延として現れることがあります。

結局、何が起きているのか

SPA
ブラウザが描画する（クライアントCPU）

SSR
サーバが描画する（サーバCPU）

つまり処理が消えたわけではなく、場所が移動しただけです。
ユーザー体験は改善しますが、インフラコストは増えやすくなります。

SSRの導入は表示速度の最適化であると同時に、計算資源の再配置でもあります。
パフォーマンス改善を考える際は、ネットワークではなくCPUの消費先を意識する方が実態に近い評価になります。