コンソールへ移動

キャッシュ動作の管理

Firebase Hosting は、強力なグローバル CDN を使用してサイトを高速化します。

リクエストされた静的コンテンツは CDN で自動的にキャッシュに保存されます。サイトのコンテンツを再デプロイすると、キャッシュに保存された静的コンテンツは、次のリクエストまでに CDN 全体から自動的にクリアされます。

ただし、Cloud Functions サービスと Cloud Run サービスはコンテンツを動的に生成するため、特定の URL に対応するコンテンツは、ユーザーが入力した情報やユーザー ID などに応じて変わります。これを考慮するため、バックエンド コードによって処理されるリクエストは、デフォルトでは CDN でキャッシュに保存されません

ただし、動的コンテンツのキャッシュの動作はユーザーが構成できます。たとえば、ある関数が新しいコンテンツを定期的に生成する場合は、生成されたコンテンツを少なくとも短期間キャッシュに保存することでアプリを高速化できます。

また、そのコンテンツはトリガーされた関数からではなく CDN から配信されるため、場合によっては関数実行コストも削減できます。関数の実行やサービスの最適化の詳細については、Cloud FunctionsCloud Run のドキュメントをご覧ください。

キャッシュの動作の詳細については、Google のウェブ デベロッパー向けドキュメントをご覧ください。

Cache-Control を設定する

動的コンテンツのキャッシュ管理に使用する主なツールは、Cache-Control ヘッダーです。このヘッダーを設定することで、コンテンツのキャッシュ可能期間をブラウザと CDN の両方に伝えることができます。関数内で、Cache-Control を次のように設定します。

res.set('Cache-Control', 'public, max-age=300, s-maxage=600');

このサンプル ヘッダーの各ディレクティブは、以下のことを行います。

  • public - キャッシュを public としてマークします。つまり、ブラウザと中間サーバー(Firebase Hosting では CDN を意味します)の両方がコンテンツをキャッシュに保存できます。

  • max-age - コンテンツをキャッシュに保存できる秒数をブラウザと CDN に伝えます。設定された時間が経過すると、ブラウザと CDN はオリジン サーバーでコンテンツを再検証する必要があります。上記のサンプル ヘッダーでは、ブラウザと CDN がコンテンツを 5 分間キャッシュに保存できるようしています(CDN キャッシュの制御については、下記の s-maxage をご覧ください)。

  • s-maxage - CDN キャッシュの動作のみについて max-age ディレクティブをオーバーライドします。この値は CDN でコンテンツをキャッシュに保存できる秒数を指定します。設定された時間が経過すると、CDN はオリジン サーバーでコンテンツを再検証する必要があります。上記のサンプル ヘッダーでは、CDN のみについて max-age の設定をオーバーライドし、CDN がコンテンツを 10 分間キャッシュに保存できるようにしています。

max-ages-maxage の値は、ユーザーが古くなったコンテンツを受け取っても問題ないと考えられる最も長い時間に設定します。数秒ごとにページが変わる場合は、短い時間に設定してください。コンテンツがそれほど頻繁に変更されない場合は、キャッシュ可能期間を数時間、数日、または数か月にすることもできます。

Cache-Control ヘッダーの詳細については、Mozilla Developer Network のドキュメントまたは Google のウェブ デベロッパー向けドキュメントをご覧ください。

キャッシュに保存されたコンテンツが配信されるタイミング

ブラウザと CDN は、以下に基づいてコンテンツをキャッシュに保存します。

  • ホスト名
  • パス
  • クエリ文字列
  • Vary ヘッダーで指定されたリクエスト ヘッダーの内容

Vary ヘッダー

Vary ヘッダーは、適切なレスポンスを提供するためにどのリクエスト ヘッダーを使用すればよいかを決定します(キャッシュに保存されたコンテンツが有効か、またはコンテンツをオリジン サーバーで再検証する必要があるか)。

ほとんどの場合、Vary ヘッダーについて気にする必要はありません。Firebase Hosting では、一般的な状況のレスポンスについては適切な Vary ヘッダーが自動的に設定されます。その際、使用中のセッション Cookie または認証ヘッダーがキャッシュキーの一部になっていることも確認されるため、誤ってコンテンツが漏洩することはありません。

高度なユースケースでは、キャッシュを制御するために他のヘッダーが必要になる場合があります。その場合は、レスポンスに Vary ヘッダーを設定するだけです。

res.set('Vary', 'Accept-Encoding, X-My-Custom-Header');

これらの設定を使用すると、X-My-Custom-Header ヘッダーが異なる以外は同一である 2 つのリクエストが別々にキャッシュされます。

Cookie の使用

Firebase Hosting と Cloud Functions または Cloud Run を併用すると、通常は受信リクエストから Cookie が削除されます。この処理は、CDN キャッシュの動作を効率化するために必要になります。__session という特別な名前の Cookie だけがアプリに到達できます。

__session Cookie が存在する場合、その Cookie はキャッシュキーの一部に自動的に組み込まれます。そのため、異なる Cookie を持つ 2 人のユーザーが、キャッシュに保存された相手のレスポンスを受信することはできません。__session Cookie は、ユーザー承認に応じてアプリから異なるコンテンツが配信される場合にのみ使用してください。