SPAとSSRでHTTPキャッシュが変わる理由 - Web開発における知見共有系ページ

SPAとSSRの違いは描画方法やSEOだけではありません。実務で最も影響が大きいのはHTTPキャッシュ戦略です。ここを理解せずにCDNを導入すると、「キャッシュしているのに速くならない」「ログインが壊れる」「古いデータが表示される」といった問題が発生します。

結論から言うと、SPAとSSRは「何を成果物として配布しているか」が違います。SPAはアプリケーションコードを配布し、SSRはページそのものを配布します。この違いがキャッシュ設計を完全に変えます。

HTTPキャッシュはレスポンス単位で保存されます。ブラウザやCDNは、次のヘッダに従って再利用します。

Cache-Control: max-age=3600
ETag: "abc123"

つまり、キャッシュの単位は「ファイル」です。問題は、SPAとSSRではキャッシュすべきファイルが異なる点です。

SPAの最も重要な配布物はJavaScriptです。

これらはユーザごとに内容が変わりません。そのため長期間キャッシュが可能です。

Cache-Control: public, max-age=31536000, immutable

ここで重要なのは、SPAのHTMLはキャッシュ対象ではない点です。index.htmlはアプリケーションの起動スクリプトに過ぎず、内容が更新される可能性があります。長期キャッシュすると新バージョンが反映されません。

そのためSPAでは次のような設定になります。

つまりSPAのキャッシュ戦略はアプリ配布最適化です。

SSRではHTML自体が成果物です。

<h1>商品ページ</h1>
<p>価格: 3000円</p>

このHTMLはページごとに異なります。しかし内容が頻繁に変わらない場合、CDNにキャッシュできます。ここがSPAとの最大の違いです。

Cache-Control: public, s-maxage=600

CDNはこのHTMLを保存し、次回リクエストに即返します。サーバ処理をスキップできるため、TTFBが大幅に改善します。

つまりSSRのキャッシュ戦略はページ配信最適化です。

SPAの設定をSSRに適用すると、ログイン状態が混ざる事故が起きます。

例：
ユーザAのマイページHTMLがCDNに保存 → ユーザBへ配信

これはキャッシュ境界を誤ったためです。SSRでは「ユーザごとに変わるページ」をキャッシュしてはいけません。

逆にSSRの設定をSPAに適用すると、毎回JSが再ダウンロードされます。結果として初回表示が極端に遅くなります。

SPAではAPIが主役です。画面表示はAPIレスポンスに依存します。そのためAPIキャッシュが重要になります。

Cache-Control: private, max-age=60

ブラウザキャッシュを活用し、再取得を減らします。

一方SSRでは、API結果はサーバ内処理の一部です。ユーザはAPIを直接取得しません。したがって、APIキャッシュよりHTMLキャッシュの方が効果的になります。

これらの原因はほぼキャッシュ戦略の不一致です。

SPA：
「同じアプリを多人数に配布」

SSR：
「異なるページを高速配信」

この前提を混同すると設計が破綻します。

SSRではキャッシュキーが重要になります。

これらを考慮しないと、別ユーザの内容が表示される可能性があります。

またSPAでは、バージョン管理（ハッシュ付きファイル名）が必須です。

app.3f2a9c.js

これにより長期キャッシュしても安全に更新できます。

SPAとSSRの違いはUI技術ではなく配布戦略です。SPAは「アプリケーションの配布」、SSRは「ページの配信」です。HTTPキャッシュは配布物に合わせて設計しなければなりません。

高速化のためにCDNを入れる前に、何をキャッシュしたいのかを決める必要があります。キャッシュは設定項目ではなく、アーキテクチャの一部です。ここを最初に設計すると、パフォーマンス問題の多くは未然に防げます。