【入門編】 GCP Cloud CDNの静的・動的コンテンツキャッシュ制御（Cache-Controlヘッダー、Varyヘッダー） – クラウドインフラと仮想化ネットワーク実践ガイド

皆さん、こんにちは！最前線のSRE兼クラウドアーキテクトとして、日々パケットと格闘している筆者がお届けする技術ブログへようこそ！

今回は、現代のウェブサービスに欠かせない高速化の切り札「CDN（Content Delivery Network）」、特にGCPのCloud CDNについて、その心臓部とも言える「キャッシュ制御」の仕組みを、初心者の方にもスッと腹落ちするよう、手取り足取り解説していきます。

「キャッシュ制御」と聞くと、なんだか難しそうな呪文のように感じるかもしれませんが、ご安心ください。郵便配達の流れや身の回りの現実世界の仕組みに例えながら、一歩ずつ、丁寧に紐解いていきますよ！

この記事を読み終える頃には、あなたのサービスでCloud CDNを賢く使いこなし、ユーザー体験を爆速にするためのヒントがきっと見つかるはずです。さあ、一緒にCDNの奥深い世界を覗いてみましょう！

—

CDNの基本をおさらいしよう！なぜCDNが必要なの？

まず、「CDNってなんだっけ？」という方もいらっしゃるかもしれませんね。ごく簡単に言うと、CDNはウェブサイトのコンテンツをユーザーに速く届けるための仕組みです。

例えるなら、皆さんが注文したオンラインストアの商品を考えてみてください。お店の倉庫（オリジンサーバー）が遠くにあって、そこから直接自宅（ユーザー）に商品が届くとしたら、時間がかかりますよね？

CDNは、このお店の倉庫の商品を、あらかじめ全国各地のコンビニや配送センター（CDNのエッジロケーション）に置いておくようなイメージです。

ユーザーが商品（ウェブコンテンツ）を要求したとき、一番近くのコンビニからパッと渡してくれるので、「速い！」「待たされない！」という体験ができるわけです。

なぜCDNがこれほど重要なのでしょう？

表示速度の向上: ユーザーの近くからコンテンツを配信するため、ウェブサイトやアプリケーションの表示が格段に速くなります。
オリジンサーバーの負荷軽減: CDNがコンテンツを代理配信してくれるため、元々のサーバー（オリジンサーバー）へのアクセス集中が緩和され、サーバーダウンのリスクが減ります。
耐障害性の向上: もしオリジンサーバーに何かトラブルがあっても、CDNがコンテンツのコピーを持っていれば、一時的にサービスを継続できることがあります。

GCPのCloud CDNも、もちろんこのCDNの一つ。Googleが持つ世界中の広大なネットワークとエッジロケーションを活用して、皆さんのコンテンツを世界中に高速配信してくれる、頼もしい存在なんです。

キャッシュって、どんな仕組み？

CDNのキモとなるのが「キャッシュ」という仕組みです。これも難しく考える必要はありません。

皆さんの家の冷蔵庫を想像してみてください。夕飯の残り物（コンテンツ）を冷蔵庫（キャッシュ）に入れておけば、翌日また一から料理を作る手間が省けますよね？それに、一度作った料理を何度も食べることで、食材を買いに行く手間（オリジンサーバーへのリクエスト）も省けます。

ウェブの世界でも同じで、一度アクセスしたコンテンツをCDNやブラウザが一時的に保存しておくことを「キャッシュする」と言います。

キャッシュのメリット:

高速化: 次回同じコンテンツが必要なときに、オリジンサーバーまで取りに行かずに、手元のキャッシュからすぐに表示できます。
負荷軽減: オリジンサーバーへのリクエストが減るので、サーバーの負担が軽くなります。

キャッシュのデメリット:

鮮度: キャッシュされたコンテンツが古くなると、ユーザーは最新の情報を見られなくなってしまいます。

この「鮮度」の問題をどう解決するかが、CDNのキャッシュ制御の腕の見せ所なんです。そして、その制御を担うのが、今回ご紹介するHTTPヘッダーたちというわけですね。

Cache-Controlヘッダーでキャッシュの寿命をコントロール！

HTTPヘッダーとは、ウェブの通信（HTTPリクエスト/レスポンス）において、コンテンツ本体だけでなく、そのコンテンツに関する様々な情報（メタデータ）を伝えるためのものです。

例えるなら、郵便物が手紙の本体だとすると、封筒に書かれた「宛先」「差出人」「速達」「書留」といった情報がヘッダーにあたります。これがあるから、郵便局員さんは適切に郵便物を届けることができるわけですよね。

Cache-Controlヘッダーは、この郵便物のヘッダーの中でも特に「この手紙はどれくらいの期間、郵便局に保管していいか」「誰が保管していいか」といった、キャッシュに関するルールをオリジンサーバーがCDNやブラウザに指示するための重要なヘッダーです。

冷蔵庫の例で言えば、食材に貼られた「賞味期限」や「開封後はお早めに」といったラベルに相当します。

主要なCache-Controlディレクティブを優しく解説

Cache-Controlにはいくつか指示（ディレクティブ）がありますが、CDNで特に重要になるものをピックアップして見ていきましょう。

max-age=<秒数>：クライアントや共有キャッシュの「賞味期限」

これは最も基本的なキャッシュの賞味期限です。「このコンテンツは、この秒数の間は新鮮だから、キャッシュして使っていいよ」という指示になります。
例えば、Cache-Control: max-age=3600 と設定されていれば、コンテンツが取得されてから3600秒（1時間）は、ブラウザもCDNもそのキャッシュを使ってもOK、ということです。

s-maxage=<秒数>：CDNなどの「共有キャッシュ」専用の賞味期限

これは、CDNのような共有キャッシュ（複数のユーザーで共有するキャッシュ）に特化した賞味期限です。もし max-age と s-maxage の両方が設定されていた場合、CDNは s-maxage の方を優先します。

例えば、ウェブサイトのアイコン画像など、すべてのユーザーに共通して表示されるコンテンツは、CDNで長くキャッシュしたいですよね。でも、ユーザーのブラウザにはそこまで長くキャッシュさせたくない（例えば、サイトデザイン変更時にすぐに反映させたい）というケースがあります。

そんな時に s-maxage が活躍します。

Cache-Control: max-age=60, s-maxage=86400
この場合、ユーザーのブラウザはコンテンツを60秒間キャッシュしますが、Cloud CDNは86400秒（24時間）キャッシュします。
Cloud CDNは、ユーザーからのリクエストに対して24時間の間はオリジンサーバーに問い合わせることなく、キャッシュからコンテンツを高速配信し続けることができます。

CDNを最大限に活用し、オリジンサーバーの負荷を劇的に減らすためには、この s-maxage を賢く設定することが非常に重要になります。

public と private：誰がキャッシュしていいの？

public: 「このコンテンツはみんなで共有していいよ！」という指示です。CDNのような共有キャッシュも、ブラウザのような個人用のキャッシュも、どちらもキャッシュしてOKという意味になります。静的な画像やCSSファイルなど、誰が見ても同じコンテンツによく使われます。
private: 「このコンテンツは個人情報を含んでいるかもしれないから、ブラウザだけがキャッシュしていいよ。CDNのような共有キャッシュはダメ！」という指示です。ログイン後のユーザー固有のページなど、パーソナライズされたコンテンツに使われます。Cloud CDNは private が指定されたコンテンツは基本的にキャッシュしません。

no-cache と no-store：キャッシュさせない！または再検証を強制！

no-cache: 「キャッシュしてもいいけど、次使うときは必ずオリジンサーバーに『本当にこれで最新？』って確認してね！」という指示です。コンテンツの鮮度を常に保ちたいけど、毎回ダウンロードし直すのは避けたい場合に利用します。
no-store: 「このコンテンツは絶対キャッシュしちゃダメ！」という最も強力な指示です。機密情報など、一切保存させたくない場合に利用します。

オリジンサーバーでのCache-Controlヘッダー設定例

それでは、実際にオリジンサーバー（ここではWebサーバーとしてよく使われるNginxを例に）でCache-Controlヘッダーを設定する例を見てみましょう。

Nginxの設定ファイル (nginx.conf や各サイトの設定ファイル) に以下のように記述します。

server {
    listen 80;
    server_name example.com;

    location /static/ {
        # 静的ファイル（画像、CSS、JSなど）の場合
        # ブラウザは1時間キャッシュ、Cloud CDNは24時間キャッシュ
        add_header Cache-Control "public, max-age=3600, s-maxage=86400";
        expires 1d; # ブラウザキャッシュのExpiresヘッダーも設定（max-ageと併用可）
    }

    location / {
        # それ以外のコンテンツ（HTMLなど）の場合
        # ブラウザは60秒キャッシュ、Cloud CDNは5分キャッシュ
        # 新着情報が多いサイトなどで、CDNでのキャッシュ期間を短くしたい場合
        add_header Cache-Control "public, max-age=60, s-maxage=300";
        expires 0; # キャッシュさせたくない場合はexpiresを0に
    }

    location /private-data/ {
        # ユーザー固有のデータなど、共有キャッシュに保存させたくない場合
        add_header Cache-Control "private, no-store";
    }

    # ...その他の設定
}

コメント:

location ディレクティブで、特定のパス（例えば /static/ 以下）に対するキャッシュルールを定義しています。
add_header Cache-Control で Cache-Control ヘッダーを追加しています。
public, max-age=3600, s-maxage=86400 は、静的ファイルをCDNで長くキャッシュさせつつ、ブラウザには適度な期間で再検証を促すための典型的な設定です。
private, no-store は、機密性の高いコンテンツを絶対にキャッシュさせないための設定です。

このように、コンテンツの種類や更新頻度に合わせて適切な Cache-Control ヘッダーを設定することが、CDNを効果的に利用する上で非常に重要になります。

Varyヘッダーでキャッシュのバリエーションを切り替えよう！

次に紹介するVaryヘッダーは、Cache-Controlほど頻繁に使うわけではありませんが、多様なユーザー環境に対応するサイトでは非常に重要な役割を果たします。

Varyヘッダーの役割を例えるなら、レストランのメニューを想像してみてください。
あるお客さんが「日本語メニュー」、別のお客さんが「英語メニュー」を頼んだとします。お店の店員さん（CDN）は、どちらのお客さんにも同じ「メニュー」という名のコンテンツを提供しますが、中身は言語によって異なりますよね？

もし店員さんが「メニュー」という情報だけを覚えて、言語の違いを考慮せずに前のお客さんと同じメニューを出してしまったら、トラブルになります。

Varyヘッダーは、この「メニューの中身（コンテンツ）は同じだけど、特定の条件によって表示を変える必要があるよ」という指示をCDNに伝えるためのものです。

なぜVaryヘッダーが必要なの？

Webサイトは、ユーザーのデバイス（PC、スマートフォン）、使用言語、ブラウザの種類などによって、表示するコンテンツを変えることがあります。

例えば：

多言語サイト: Accept-Language ヘッダーに基づいて、日本語、英語、中国語など、ユーザーの好みに合わせた言語のコンテンツを提供する場合。
レスポンシブデザインではないサイト: User-Agent ヘッダー（ブラウザやOSの情報）に基づいて、PC用とスマートフォン用で全く異なるHTMLを返す場合。
圧縮コンテンツ: Accept-Encoding ヘッダーに基づいて、Gzip圧縮されたコンテンツと圧縮されていないコンテンツを切り替える場合。

このような場合、CDNは「このコンテンツは Accept-Language ヘッダーの値によって内容が変わるんだな」と認識し、Accept-Language の値ごとに異なるキャッシュを保存します。

つまり、

Accept-Language: ja でリクエストされたコンテンツは「日本語版キャッシュ」として保存。
Accept-Language: en でリクエストされたコンテンツは「英語版キャッシュ」として保存。

これにより、ユーザーは常に自分の環境に合った適切なコンテンツを受け取ることができるのです。

よく使われるVaryヘッダーの値

Vary: User-Agent: ユーザーエージェント（デバイスやブラウザの種類）によってコンテンツが変わる場合。
Vary: Accept-Language: ユーザーの言語設定によってコンテンツが変わる場合。
Vary: Accept-Encoding: 圧縮形式（gzipなど）によってコンテンツが変わる場合。

複数の条件でコンテンツが変化する場合は、カンマ区切りで指定できます。
例: Vary: User-Agent, Accept-Language

Varyヘッダーの注意点

Varyヘッダーは非常に便利ですが、一つ注意が必要です。
Varyヘッダーを指定すると、CDNは指定されたヘッダーの値ごとにキャッシュを保存するため、キャッシュのバリエーションが増え、結果としてキャッシュヒット率が低下する可能性があります。

例えば、Vary: User-Agent を指定した場合、世の中には無数の User-Agent 文字列が存在するため、CDNはその一つ一つに対してキャッシュを保持しようとし、キャッシュの効率が悪くなることがあります。

そのため、本当に必要な場合にのみ、慎重に設定することが推奨されます。最近のレスポンシブデザインのウェブサイトでは、デバイスごとに異なるHTMLを返すのではなく、CSSで表示を調整することが多いため、Vary: User-Agent の必要性は減ってきていますね。

オリジンサーバーでのVaryヘッダー設定例

NginxでVaryヘッダーを設定する例を見てみましょう。

server {
    listen 80;
    server_name multi-lang.example.com;

    location / {
        # 言語によってコンテンツを出し分ける場合
        # Cloud CDNはAccept-Languageヘッダーの値ごとにキャッシュを生成する
        add_header Vary "Accept-Language";
        add_header Cache-Control "public, max-age=3600, s-maxage=86400";

        # ... ここでAccept-Languageに基づいてコンテンツを返すロジック（例: PHPやPythonアプリケーション）
        # 例:
        # if ($http_accept_language ~* "(ja|ja-jp)") {
        #     root /var/www/html/ja/;
        # } else if ($http_accept_language ~* "(en|en-us)") {
        #     root /var/www/html/en/;
        # } else {
        #     root /var/www/html/en/; # デフォルトは英語
        # }
    }

    # ...その他の設定
}

コメント:

add_header Vary "Accept-Language"; で、Accept-Language ヘッダーの値によってコンテンツが異なることをCDNに伝えています。
これにより、Cloud CDNは例えば「Accept-Language: ja でリクエストされた / のコンテンツ」と「Accept-Language: en でリクエストされた / のコンテンツ」を別々にキャッシュするようになります。

GCP Cloud CDNでのキャッシュ制御の実際

ここまでCache-ControlとVaryヘッダーについて解説してきましたが、GCP Cloud CDNはこれらのヘッダーをどのように解釈し、キャッシュを管理しているのでしょうか。

基本的には、Cloud CDNはオリジンサーバーから返されるこれらのHTTPレスポンスヘッダーを尊重し、指示に従ってキャッシュを運用します。

Cache-Controlヘッダーがない場合のCloud CDNのデフォルト挙動

もしオリジンサーバーが Cache-Control ヘッダーを一切返さなかった場合、Cloud CDNはどのように振る舞うと思いますか？

実は、GCP Cloud CDNは、HTTPステータスコードが 200 OK のレスポンスに対して、デフォルトで5分間キャッシュします。これは、明示的なキャッシュ指示がない場合でも、ある程度のキャッシュによる高速化と負荷軽減を図るための賢い挙動と言えます。

しかし、より細かく、より長くキャッシュしたい場合は、やはり先ほど紹介した Cache-Control: s-maxage を適切に設定することが重要です。

Cloud CDNのバックエンドサービス設定でキャッシュをオーバーライド

さらに、Cloud CDNは、バックエンドサービスの設定でキャッシュの挙動を細かく制御できるようになっています。これにより、オリジンサーバーが返すヘッダーに加えて、またはヘッダーを上書きする形で、CDN側のキャッシュルールを定義できます。

例えば、オリジンサーバーのアプリケーションコードを修正せずに、Cloud CDN側で特定のパスのコンテンツのキャッシュ期間を制御したい場合に便利です。

Cloud CDNのバックエンドサービス設定で、以下のようなキャッシュモードを選択できます。

USE_ORIGIN_HEADERS (デフォルト): オリジンサーバーの Cache-Control ヘッダーに従います。これが最も一般的な使い方で、推奨される方法です。
CACHE_ALL_STATIC: すべての静的コンテンツ（拡張子やMIMEタイプで判別）をキャッシュします。
FORCE_CACHE_ALL: すべてのコンテンツを強制的にキャッシュします（リスクがあるため注意）。
BYPASS_CACHE: キャッシュを完全にバイパスします。

また、USE_ORIGIN_HEADERS を選択した場合でも、Cloud CDNのバックエンドサービスで最小TTL (clientTtl)、最大TTL (defaultTtl)、そして s-maxage に相当する共有キャッシュの最大TTL (maxTtl) をオーバーライドできます。

優先順位の考え方:
1. オリジンサーバーの Cache-Control ヘッダー: 特に s-maxage はCDNのキャッシュ期間を決定する上で最優先されます。
2. Cloud CDNバックエンドサービスの maxTtl: オリジンヘッダーがない場合や、s-maxage が設定されていない場合に適用される、Cloud CDNがキャッシュを保持する最大期間です。
3. Cloud CDNバックエンドサービスの defaultTtl: オリジンヘッダーがなく、maxTtl も設定されていない場合に適用される、デフォルトのキャッシュ期間です。
4. Cloud CDNのデフォルト動作 (5分): 上記のいずれも設定されていない場合の最終的なフォールバックです。

つまり、最も柔軟かつ詳細にキャッシュを制御したいのであれば、オリジンサーバーで Cache-Control: s-maxage を含めて適切に設定するのがベストプラクティスと言えるでしょう。

実践！Cloud CDNの有効化とオリジンサーバーの設定例

それでは、実際にGCP Cloud CDNを有効化し、オリジンサーバーでヘッダーを設定する流れを見ていきましょう。

1. Cloud CDNの有効化（GCP CLIコマンド）

GCPでCloud CDNを有効化するには、まずロードバランサー（外部HTTP(S)ロードバランサー）とバックエンドサービスが必要です。既存のロードバランサーとバックエンドサービスにCloud CDNを有効化するコマンドは以下のようになります。

# ロードバランサーのバックエンドサービス名とリージョンを指定
BACKEND_SERVICE_NAME="my-web-backend-service"
REGION="asia-northeast1" # 例: 東京リージョン

# バックエンドサービスにCloud CDNを有効化
gcloud compute backend-services update ${BACKEND_SERVICE_NAME} \
    --region=${REGION} \
    --enable-cdn \
    --cdn-policy="default-ttl=3600s,client-ttl=300s,max-ttl=86400s,cache-mode=USE_ORIGIN_HEADERS"

# コメント:
# --enable-cdn: Cloud CDNを有効にします。
# --cdn-policy: キャッシュポリシーを設定します。
#   - default-ttl: オリジンサーバーがCache-Controlヘッダーを返さない場合のデフォルトキャッシュ期間 (秒)。
#                  ここでは1時間 (3600秒) に設定。
#   - client-ttl: クライアント（ブラウザ）に推奨するキャッシュ期間 (秒)。
#                 ここでは5分 (300秒) に設定。
#   - max-ttl: Cloud CDNがキャッシュを保持する最大期間 (秒)。
#              ここでは24時間 (86400秒) に設定。
#              オリジンのs-maxageがこれより大きい場合、このmax-ttlが優先されます。
#   - cache-mode: キャッシュの動作モード。USE_ORIGIN_HEADERSはオリジンサーバーのヘッダーを尊重します。

このコマンドで、Cloud CDNが有効になり、Cache-Controlヘッダーに従いつつ、デフォルトや最大期間のルールも設定されました。

2. オリジンサーバー（Nginx）でのヘッダー設定

次に、先ほどのNginxの設定例を再度確認し、実際のコンテンツの配信に合わせて調整します。

# /etc/nginx/nginx.conf または /etc/nginx/sites-available/your_site.conf
server {
    listen 80;
    server_name www.example.com;

    root /var/www/html; # ウェブサイトのルートディレクトリ

    # 静的ファイル（画像、CSS、JavaScriptなど）に対するキャッシュ設定
    location ~* \.(jpg|jpeg|gif|png|webp|ico|css|js)$ {
        # Cloud CDNには24時間キャッシュさせ、ブラウザには1時間キャッシュを推奨
        add_header Cache-Control "public, max-age=3600, s-maxage=86400";
        expires 1d; # ブラウザキャッシュのExpiresヘッダーも設定（max-ageと併用可）
        access_log off; # 静的ファイルへのアクセスログは不要な場合
    }

    # HTMLファイルなど、動的または頻繁に更新されるコンテンツに対するキャッシュ設定
    location ~* \.html$ {
        # Cloud CDNには5分間キャッシュさせ、ブラウザには1分間キャッシュを推奨
        # 更新頻度が高いコンテンツだが、一定期間はCDNにキャッシュさせたい場合
        add_header Cache-Control "public, max-age=60, s-maxage=300";
        expires 0; # ブラウザにはキャッシュしないか、常に再検証を促す
    }

    # APIなど、常に最新情報を表示すべきコンテンツに対するキャッシュ設定
    location /api/ {
        # キャッシュさせない、または常にオリジンサーバーに確認を強制
        add_header Cache-Control "no-cache, no-store, must-revalidate";
        expires off; # Expiresヘッダーも無効化
    }

    # 多言語サイトなど、Varyヘッダーが必要なコンテンツに対する設定例
    location /localized/ {
        add_header Vary "Accept-Language"; # 言語ごとにキャッシュを分ける
        add_header Cache-Control "public, max-age=3600, s-maxage=86400";
        # ここでAccept-Languageに基づいてコンテンツを返すロジック
    }

    # ...その他のNginx設定
}

コメント:

location ~* \.(jpg|jpeg|gif|png|webp|ico|css|js)$ のように、正規表現を使ってファイルの種類ごとに異なるキャッシュポリシーを適用しています。
max-age と s-maxage を使い分け、ブラウザとCDNのキャッシュ期間を最適化しています。
no-cache, no-store を使って、APIなどの頻繁に更新される（または常に最新であるべき）コンテンツがキャッシュされないようにしています。
Vary: Accept-Language を設定することで、多言語コンテンツの適切な配信を可能にしています。

これらの設定を適用したら、Nginxを再起動することを忘れないでくださいね。

sudo systemctl restart nginx

これで、あなたのウェブサイトはCloud CDNの恩恵を最大限に受けつつ、コンテンツの鮮度も適切に保たれるようになります。

—

まとめ：CDNとキャッシュ制御はサイト高速化の要！

皆さん、長丁場お疲れ様でした！

今回は、GCP Cloud CDNを例に挙げながら、ウェブサイトの高速化に欠かせない「キャッシュ制御」の肝となるHTTPヘッダー、Cache-ControlとVaryについて、その役割と設定方法をじっくりと見てきました。

Cache-Controlヘッダー: コンテンツの「賞味期限」と「誰がキャッシュしていいか」を指示する、キャッシュ制御の最も重要な司令塔です。特にCDNの共有キャッシュ期間を制御する s-maxage は、CDN活用において絶大な力を発揮します。
Varyヘッダー: ユーザーの環境（言語、デバイスなど）によってコンテンツ内容が変わる場合に、「この条件ごとにキャッシュを分けてね」とCDNに指示するためのヘッダーです。適切に使えばユーザー体験を向上させますが、乱用するとキャッシュ効率が落ちる諸刃の剣でもあります。

これらのヘッダーをオリジンサーバーで適切に設定し、GCP Cloud CDNのバックエンドサービス設定と組み合わせることで、あなたのウェブサイトは驚くほど速く、そして安定してコンテンツを配信できるようになります。

最初は少し複雑に感じるかもしれませんが、これらのヘッダーがパケットに乗ってネットワークを駆け巡り、CDNのエッジロケーションで賢く判断されている様子を想像すると、きっと面白く感じてくるはずです。

サイトの高速化は、ユーザー満足度だけでなく、検索エンジン最適化（SEO）にも直結する重要な要素です。ぜひ今日学んだ知識を活かして、皆さんのサービスをさらに素晴らしいものにしてください！

もし「うちのサイトではどう設定すればいいんだろう？」といった疑問や、実際に設定してみて困ったことがあれば、ぜひコメントで教えてくださいね。SREの仲間として、いつでも相談に乗りますよ！

それでは、また次回の記事でお会いしましょう！

CDNの基本をおさらいしよう！ なぜCDNが必要なの？

なぜCDNがこれほど重要なのでしょう？

キャッシュって、どんな仕組み？

Cache-Controlヘッダーでキャッシュの寿命をコントロール！

主要なCache-Controlディレクティブを優しく解説

max-age=<秒数>：クライアントや共有キャッシュの「賞味期限」

s-maxage=<秒数>：CDNなどの「共有キャッシュ」専用の賞味期限

public と private：誰がキャッシュしていいの？

no-cache と no-store：キャッシュさせない！ または再検証を強制！

オリジンサーバーでのCache-Controlヘッダー設定例

Varyヘッダーでキャッシュのバリエーションを切り替えよう！

なぜVaryヘッダーが必要なの？

よく使われるVaryヘッダーの値

Varyヘッダーの注意点

オリジンサーバーでのVaryヘッダー設定例

GCP Cloud CDNでのキャッシュ制御の実際

Cache-Controlヘッダーがない場合のCloud CDNのデフォルト挙動

Cloud CDNのバックエンドサービス設定でキャッシュをオーバーライド

実践！Cloud CDNの有効化とオリジンサーバーの設定例

1. Cloud CDNの有効化（GCP CLIコマンド）

2. オリジンサーバー（Nginx）でのヘッダー設定

まとめ：CDNとキャッシュ制御はサイト高速化の要！

コメント

CDNの基本をおさらいしよう！なぜCDNが必要なの？

no-cache と no-store：キャッシュさせない！または再検証を強制！