Firebase Summit で発表されたすべての情報をご覧ください。Firebase を使用してアプリ開発を加速し、自信を持ってアプリを実行する方法を紹介しています。詳細

キャッシュの動作を管理する

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

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

要求された静的コンテンツはすべて、CDN に自動的にキャッシュされます。サイトのコンテンツを再デプロイすると、Firebase Hosting は次のリクエストまで、キャッシュされたすべての静的コンテンツを CDN 全体で自動的に消去します。

ただし、Cloud Functions および Cloud Run サービスはコンテンツを動的に生成するため、特定の URL のコンテンツは、ユーザー入力やユーザー ID などに基づいて異なる場合があります。これを考慮して、404 エラーを返すリクエストを除いて、バックエンド コードによって処理されるリクエストはデフォルトで CDN にキャッシュされませ。キャッシュされた 404 の結果をクリアするには、Firebase Hosting を再デプロイします。 Cloud Functions と Cloud Run を再デプロイしても、キャッシュは自動的に無効になりませ

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

また、トリガーされた関数ではなく CDN からコンテンツが提供されるため、関数の実行コストを削減できる可能性もあります。関数の実行とサービスの最適化について詳しくは、 Cloud FunctionsCloud Runのドキュメントをご覧ください。

Google のWeb 開発者向けドキュメントでキャッシュ動作の詳細を確認してください。

キャッシュ制御の設定

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

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

この例のヘッダーでは、ディレクティブは次の 3 つのことを行います。

  • 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 のWeb 開発者向けドキュメントを参照してください。

キャッシュされたコンテンツはいつ提供されますか?

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

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

ヘッダーを変更する

Varyヘッダーは、適切な応答を提供するためにどの要求ヘッダーを使用する必要があるかを決定します (キャッシュされたコンテンツが有効かどうか、またはオリジン サーバーでコンテンツを再検証する必要があるかどうか)。

Firebase Hosting は、一般的な状況に対して、応答に適切なVaryヘッダーを自動的に設定します。ほとんどの場合、 Varyヘッダーについて心配する必要はありません。ただし、一部の高度なユース ケースでは、キャッシュに影響を与える必要がある他のヘッダーが存在する場合があります。その場合は、応答にVaryヘッダーを設定できます。例えば:

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

この場合、 Varyヘッダーの値は次のとおりです。

vary: X-My-Custom-Header, x-fh-requested-host, accept-encoding, cookie, authorization

これらの設定では、 X-My-Custom-Headerヘッダーが異なる 2 つの同一の要求が別々にキャッシュされます。 Hosting は、動的コンテンツに対してリクエストが行われると、デフォルトでCookieAuthorizationVaryヘッダーに追加することに注意してください。これにより、使用するすべてのセッションまたは Cookie 認証ヘッダーがキャッシュ キーの一部になり、偶発的なコンテンツの漏洩を防ぐことができます。

また、次の点に注意してください。

  • キャッシュできるのはGETおよびHEADリクエストのみです。他の方法を使用する HTTPS リクエストはキャッシュされません。

  • Varyヘッダーに設定を追加するときは注意してください。追加する設定が多いほど、CDN がキャッシュされたコンテンツを提供できる可能性が低くなります。また、 Vary応答ヘッダーではなく、要求ヘッダーに基づいていることに注意してください。

クッキーの使用

Firebase Hosting を Cloud Functions または Cloud Run と一緒に使用する場合、通常、Cookie は受信リクエストから削除されます。これは、効率的な CDNキャッシュの動作を可能にするために必要です。特別な名前の__session Cookie のみが、アプリの実行に渡されることが許可されています。

存在する場合、 __session Cookie は自動的にキャッシュ キーの一部になります。つまり、異なる Cookie を持つ 2 人のユーザーがキャッシュされた相手の応答を受信することは不可能です。アプリがユーザー認証に応じて異なるコンテンツを提供する場合にのみ、 __session Cookie を使用してください。