SSRでEdge Runtimeが注目される理由

Edge Runtimeは「速いサーバ」ではなく「距離をなくす仕組み」です

最近のSSR（Server Side Rendering）では、Vercel Edge Functions や Cloudflare Workers のような Edge Runtime が注目されています。
よく「高速なサーバだからSSRに向いている」と説明されますが、それは半分しか正しくありません。

結論を先に言うと、Edge Runtimeの本質は処理能力の向上ではなく、ネットワーク距離の削減です。

SSRの遅延の多くはレンダリング時間ではありません。
最大のボトルネックは「往復時間（RTT）」です。

SSRが遅く感じる本当の原因

SSRのリクエストは単純なHTML取得ではありません。
実際には次の通信が連続します。

• ブラウザ → サーバ
• サーバ → API
• サーバ → 認証サーバ
• サーバ → キャッシュ
• サーバ → ブラウザ

このとき重要なのは処理時間より移動時間です。

例えば：

• 東京のユーザ
• 米国リージョンのサーバ

往復だけで200ms以上かかります。
SSRは1回のリクエストに複数の通信が含まれるため、遅延が積み上がります。

CDNでは解決できなかった理由

CDNは静的ファイルをキャッシュします。

• 画像
• CSS
• JS

しかしSSRのHTMLはユーザごとに変わる可能性があります。

• ログイン状態
• 地域表示
• A/Bテスト
• パーソナライズ

そのため従来はCDNに載せられませんでした。
結果として、HTMLだけは遠いサーバから取得していました。

ここにEdge Runtimeが登場します。

Edge Runtimeの動作

Edge Runtimeは、CDNのサーバ上でJavaScriptを実行します。
つまり配信地点でSSRを行います。

構成は次のようになります。

従来：
ブラウザ → 米国サーバ → ブラウザ

Edge：
ブラウザ → 東京エッジサーバ → ブラウザ

物理距離が消えます。

export default async function handler(req) {
  const data = await fetch('https://api.example.com/posts')
  return new Response(render(data))
}

このコードはユーザに最も近いエッジノードで実行されます。

Node.jsサーバとの違い

Edge RuntimeはNode.jsではありません。
V8 Isolateという軽量コンテナで動きます。

そのため特徴が変わります。

項目	Node.js	Edge Runtime
起動	数百ms	数ms
常駐	あり	なし
メモリ	大	小
同時実行	プロセス依存	大量可能

Edgeはサーバというより「実行可能なCDN」です。

なぜSSRと相性が良いのか

SSRで重要なのはCPU性能ではありません。
重要なのはTTFB（最初の1バイトまでの時間）です。

Edge Runtimeでは次が起きます。

• TCP接続が近い
• TLS確立が速い
• HTML返却が速い

レンダリングが同じでも体感速度が改善します。

特にモバイル回線では差が大きくなります。

ただし万能ではない

Edge Runtimeには制約があります。

ファイルシステムが使えない

fs.readFileSync()

これは動きません。

TCP接続が制限される

DBへ直接接続できない場合があります。

長時間処理が不可

数秒以上の処理はタイムアウトします。

つまり重いSSRには向きません。
Edgeは「軽いレンダリング」に最適です。

向いている処理

• 認証チェック
• ABテスト
• 地域分岐
• ヘッダ変換
• 軽量SSR

向いていない処理：

• 大量DBクエリ
• 画像生成
• 重い計算

SSRの構造が変わり始めている

以前のSSRは「1つの巨大サーバ」で動いていました。
現在は分解されつつあります。

• 認証：Edge
• HTML生成：Edge/Server
• データ取得：API
• 静的配信：CDN

つまりSSRは1台のサーバ機能ではなく、分散システムへ変化しています。

Edge RuntimeはSSRを高速化する技術ではありません。
SSRの配置場所を変える技術です。

サーバを速くするのではなく、ユーザの隣に移動させる。
これがEdge Runtimeが注目されている理由です。