获取我们在 Firebase 峰会上发布的所有信息,了解 Firebase 可如何帮助您加快应用开发速度并满怀信心地运行应用。了解详情

管理缓存行为

使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

Firebase 托管使用强大的全球 CDN 来让您的网站尽可能快地运行。

任何请求静态内容都会自动缓存在 CDN 上。如果您重新部署网站的内容,Firebase 托管会自动清除 CDN 中所有缓存的静态内容,直到下一次请求。

但是,由于 Cloud Functions 和 Cloud Run 服务会动态生成内容,因此给定 URL 的内容可能会根据用户输入或用户身份等因素而有所不同。考虑到这一点,由后端代码处理的请求默认情况下不会缓存在 CDN 上。

不过,您可以为动态内容配置缓存行为。例如,如果一个函数只定期生成新内容,您可以通过至少在短时间内缓存生成的内容来加速您的应用程序。

您还可以潜在地降低函数执行成本,因为内容是从 CDN 提供的,而不是通过触发函数提供的。在Cloud FunctionsCloud Run文档中阅读有关优化函数执行和服务的更多信息。

在 Google 的Web 开发人员文档中了解有关缓存行为的更多信息。

设置缓存控制

用于管理动态内容缓存的主要工具是Cache-Control标头。通过配置此标头,您可以向浏览器和 CDN 传达您的内容可以缓存多长时间。在您的函数中,您像这样设置Cache-Control

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

在这个示例头文件中,指令做了三件事:

  • public — 将缓存标记为public 。这意味着浏览器中间服务器(即 Firebase 托管的 CDN)都可以缓存内容。

  • max-age — 告诉浏览器和 CDN 可以缓存内容的秒数。当设置的时间到期时,浏览器和 CDN 必须与源服务器重新验证内容。在示例标头中,我们允许浏览器和 CDN 将内容缓存五分钟(有关 CDN 缓存的特定控件,请参见下面的s-maxage )。

  • s-maxage — 仅覆盖 CDN 缓存的max-age指令;告诉 CDN 可以缓存内容的秒数。当设置的时间到期时,CDN 必须与源服务器重新验证内容。在示例标头中,我们仅覆盖 CDNmax-age设置,并允许 CDN 将内容缓存十分钟。

对于max-ages-maxage ,将它们的值设置为您对用户接收陈旧内容感到满意的最长时间。如果页面每隔几秒更改一次,请使用较小的时间值。但是,其他类型的内容可以安全地缓存数小时、数天甚至数月。

您可以在Mozilla 开发人员网络和 Google 的Web 开发人员文档中了解有关Cache-Control标头的更多信息。

何时提供缓存内容?

浏览器和 CDN 缓存您的内容基于:

  • 主机名
  • 路径
  • 查询字符串
  • Vary头中指定的请求标头的内容

改变标题

Vary标头确定应使用哪些请求标头来提供适当的响应(缓存的内容是否有效,或者是否应使用源服务器重新验证内容)。

Firebase 托管会针对常见情况自动在您的响应中设置适当的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标头的相同请求将分别缓存。请注意,当请求动态内容时,Hosting 默认将CookieAuthorization添加到Vary标头。这可确保您使用的任何会话或 cookie 授权标头都成为缓存键的一部分,从而防止内容意外泄漏。

另请注意:

  • 只能缓存GETHEAD请求。使用其他方法的 HTTPS 请求永远不会被缓存。

  • Vary标头添加设置时要小心。您添加的设置越多,CDN 提供缓存内容的可能性就越小。还要记住Vary基于请求标头,而不是响应标头。

使用 cookie

将 Firebase 托管与 Cloud Functions 或 Cloud Run 一起使用时,通常会从传入请求中删除 cookie。这对于允许高效的 CDN缓存行为是必要的。只有特别命名的__session cookie 被允许传递给您的应用程序的执行。

如果存在, __session cookie 会自动成为缓存键的一部分,这意味着具有不同 cookie 的两个用户不可能接收到对方的缓存响应。仅当您的应用根据用户授权提供不同的内容时,才使用__session cookie。