CDNとキャッシュ設計：Webの速さは「作り方」より「配り方」で決まる

コードを削るより、配信を見直すほうが速いことは多い

表示速度の相談を受けると、多くの人はまず「JavaScriptを削る」「画像を圧縮する」といったアプリ側の最適化を思い浮かべる。もちろん大事だが、私たちの経験では、配信（デリバリー）の設計を見直すほうが、少ない手間で大きく効くケースが少なくない。同じHTMLでも、どこから・どうやって届けるかで体感速度はまるで変わる。

CDNは「距離」と「混雑」を同時に解く

CDN（コンテンツデリバリネットワーク）は、世界中に配置されたサーバーの中からユーザーに最も近い拠点でコンテンツを返す仕組みだ。効果は主に二つ。ひとつは物理的な距離を縮めて往復時間（レイテンシ）を減らすこと。もうひとつは、オリジンサーバー（本体）にアクセスを集中させず、混雑を肩代わりさせること。アクセスが増えても本体が落ちにくくなる、という耐障害性の側面も見逃せない。

キャッシュは「何を・どれくらい」持たせるかがすべて

CDNを入れただけでは速くならない。鍵はキャッシュ設定だ。画像・CSS・JSといった変化しない静的アセットは長期間キャッシュし、ファイル名にハッシュを付けて更新時だけ別物として扱う（キャッシュバスティング）。一方、価格や在庫のように頻繁に変わる情報を長くキャッシュすると、古い内容が表示される事故になる。「めったに変わらないものは長く、変わるものは短く（あるいは持たせない）」——この切り分けを最初に決めておく。

Cache-Control を曖昧にしない

キャッシュ事故の大半は、Cache-Control ヘッダーの設定が曖昧なまま本番に出たことが原因だ。「public / private」「max-age」「s-maxage」「stale-while-revalidate」——このあたりを、コンテンツの種類ごとに明示的に決める。なんとなくのデフォルト任せが一番危ない。

動的なページこそ、キャッシュの工夫が効く

「うちは動的サイトだからキャッシュは無理」と諦める必要はない。ログイン後の個人向け画面はキャッシュできなくても、トップページや記事ページのような大多数に同じ内容を返す部分は、短時間でもエッジでキャッシュすれば効果は大きい。JAMStack や ISR（増分静的再生成）のように、動的な更新と静的な速さを両立させる作り方も一般的になっている。

まずは「何がキャッシュされていないか」を見る

改善の第一歩は計測だ。ブラウザの開発者ツールやCDNの管理画面で、各リソースがキャッシュに当たっているか（HIT / MISS）を確認する。MISSばかりの静的ファイルが見つかれば、そこが伸びしろだ。速さは気合いではなく設計で決まる。配り方を整えるだけで、コードに手を入れずとも一段速くなることは珍しくない。