Firebase Hosting 使用遍布全球的强大 CDN，可最大限度提高您的网站的速度。
所请求的任何静态内容都会自动缓存在 CDN 中。如果您重新部署网站的内容，Firebase Hosting 会在下次请求之前自动清除整个 CDN 中所有缓存的静态内容。
但是，由于 Cloud Functions 和 Cloud Run 服务会动态生成内容，因此给定网址的内容可能会因用户输入或用户身份等而异。考虑到这一点，默认情况下，后端代码处理的请求不会缓存在 CDN 中，但返回 404 错误的请求除外。如需清除缓存的 404 结果，请重新部署 Firebase Hosting；请注意，重新部署 Cloud Functions 和 Cloud Run 不会自动使缓存失效。
不过，您可以为动态内容配置缓存行为。例如，如果某个函数只是定期生成新内容，您可以通过将生成的内容至少缓存一小段时间来加快您应用的速度。
您还可以降低函数执行费用，因为内容是通过 CDN 提供的，而不是通过触发的函数提供的。如需详细了解如何优化函数的执行和服务，请参阅 Cloud Functions 和 Cloud Run 文档。
如需详细了解缓存行为，请参阅 Google 的 Web 开发者文档。
设置 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 将内容缓存五分钟（有关 CDN 缓存的特定控制措施，请参阅下文的s-maxage）。s-maxage- 仅替换 CDN 缓存的max-age指令；告知 CDN 可以缓存内容的秒数。当达到设置的时间时，CDN 必须与源服务器重新验证内容。在示例标头中，我们仅替换 CDN 的max-age设置，并允许 CDN 将内容缓存十分钟。
对于 max-age 和 s-maxage，请将其值设置为允许用户收到过期内容的最长时间。如果页面每几秒更改一次，请使用较小的时间值。但是，其他类型的内容可以安全地缓存数小时、数天甚至数月。
您可以参阅 Mozilla 开发者网络以及 Google 的 Web 开发者文档，以详细了解 Cache-Control 标头。
何时提供缓存的内容？
浏览器和 CDN 会根据以下各项缓存您的内容：
- 主机名
- 路径
- 查询字符串
Vary标头中指定的请求标头的内容
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 标头的相同请求会分别被缓存。请注意，当请求获取动态内容时，Hosting 默认会将 Cookie 和 Authorization 添加到 Vary 标头中。这样可以确保您使用的任何会话或 Cookie 授权标头均为缓存键的一部分，从而防止意外泄露内容。
另外还需注意以下事项：
只能缓存
GET和HEAD请求。使用其他方法的 HTTPS 请求永远不会被缓存。向
Vary标头添加设置时要小心。您添加的设置越多，CDN 提供缓存内容的可能性越小。 另请注意，Vary基于请求标头，而不是响应标头。
使用 Cookie
将 Firebase Hosting 与 Cloud Functions 或 Cloud Run 搭配使用时，Cookie 通常会从传入的请求中剥离出来。要实现高效的 CDN 缓存行为，就必须如此。
只有特别指定的 __session Cookie 可以传入应用执行过程。
__session Cookie（如果存在）会自动成为缓存键的一部分，也就是说，使用不同 Cookie 的两个用户绝不会收到对方的已缓存响应。仅当您的应用需要根据用户授权提供不同的内容时，才应使用 __session Cookie。