Управление поведением кэша

Firebase Hosting использует мощную глобальную CDN-сеть, чтобы сделать ваш сайт максимально быстрым.

Любой запрошенный статический контент автоматически кэшируется в CDN . Если вы повторно развертываете контент своего сайта, Firebase Hosting автоматически очищает весь кэшированный контент в CDN до следующего запроса.

Однако, поскольку сервисы Cloud Functions и Cloud Run генерируют контент динамически, содержимое для данного URL-адреса может меняться в зависимости от таких факторов, как ввод данных пользователем или его идентификация. Чтобы учесть это, запросы, обрабатываемые бэкэнд-кодом, по умолчанию не кэшируются в CDN.

Однако вы можете настроить поведение кэширования для динамического контента . Например, если функция генерирует новый контент только периодически, вы можете ускорить работу приложения, кэшируя сгенерированный контент хотя бы на короткий период времени.

Аналогичным образом можно настроить поведение кэширования, что потенциально позволит снизить затраты на выполнение функций, поскольку контент будет предоставляться из CDN, а не из запущенной функции. Подробнее об оптимизации выполнения функций и сервисов можно прочитать в документации по Cloud Functions и Cloud Run .

Исключение составляют запросы, возвращающие ошибки 404. CDN кэширует ответ вашего сервиса с ошибкой 404 на несуществующий URL-адрес на 10 минут, так что последующие запросы к этому URL-адресу будут обрабатываться CDN. Если вы измените свой сервис так, что контент теперь будет доступен по этому URL-адресу, CDN продолжит обрабатывать все кэшированные ошибки 404 в течение 10 минут (максимум), а затем будет обрабатывать контент с этого URL-адреса в обычном режиме.

Если ответ с ошибкой 404 уже содержит заголовки кэширования, установленные вашей службой Cloud Functions или Cloud Run , они переопределяют значение по умолчанию в 10 минут и полностью определяют поведение кэширования CDN.

Подробнее о принципах кэширования можно узнать в документации Google для веб-разработчиков .

Установить управление кэшем

The main tool that you use to manage cache for dynamic content is the Cache-Control header. By configuring this header, you can communicate both to the browser and the CDN how long your content can be cached. In your function, you set Cache-Control like so:

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

В этом примере заголовка директивы выполняют три действия:

  • public — Помечает ответ как public . Это означает, что контент может кэшироваться как браузером , так и промежуточными кэшами (включая CDN для Firebase Hosting ).

  • max-age — Задает, сколько секунд может пройти с момента получения ответа, прежде чем он будет повторно проверен на исходном сервере. Это относится к браузерам; если заголовок s-maxage отсутствует, это также относится ко всем остальным кэшам (включая CDN).

  • s-maxage — Переопределяет директиву max-age для общих кэшей (таких как CDN). Когда CDN обнаруживает ответ старше s-maxage секунд, он повторно проверяет его на исходном сервере. В приведенном примере заголовка браузеры могут кэшировать ответ в течение 5 минут, а CDN и любые другие промежуточные кэши — в течение 10 минут.

Для max-age и s-maxage установите их значения на максимально допустимый период времени, в течение которого пользователи могут спокойно получать устаревший контент. Если страница меняется каждые несколько секунд, используйте небольшое значение времени. Однако другие типы контента можно безопасно кэшировать в течение часов, дней или даже месяцев.

Если вы хотите полностью исключить кэширование (например, чтобы всегда отображать самую актуальную версию статического контента), вы можете настроить это в firebase.json с помощью параметра headers :

"hosting": {
  // ...

  // Disables caching for the /posts route
  "headers": [ {
    // Change source to match your dynamically-rendered routes
    "source": "/posts/**",
    "headers": [ {
      "key": "Cache-Control",
      "value": "no-cache, no-store"
    } ]
  } ]
}

Более подробную информацию о заголовке Cache-Control можно найти в сети разработчиков Mozilla и в документации Google для веб-разработчиков .

Когда предоставляется кэшированный контент?

Браузер и 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 кэшируются отдельно. Обратите внимание, что Hosting по умолчанию добавляет Cookie и Authorization в заголовок Vary при запросе динамического контента. Это гарантирует, что любой используемый вами заголовок авторизации сессии или cookie станет частью ключа кэша, что предотвращает случайные утечки контента.

Также обратите внимание:

  • Кэшированию подлежат только запросы GET и HEAD . Запросы HTTPS, использующие другие методы, никогда не кэшируются.

  • Будьте осторожны при добавлении настроек в заголовок Vary . Чем больше настроек вы добавите, тем меньше вероятность того, что CDN сможет предоставлять кэшированный контент. Также помните, что Vary основан на заголовках запроса , а не на заголовках ответа .

Использование файлов cookie

При использовании Firebase Hosting совместно с Cloud Functions или Cloud Run файлы cookie обычно удаляются из входящих запросов. Это необходимо для обеспечения эффективной работы кэша CDN. Для выполнения вашего приложения разрешен только специально названный файл cookie __session .

Если cookie-файл __session присутствует, он автоматически становится частью ключа кэша, что означает невозможность получения кэшированного ответа от другого пользователя двумя пользователями с разными cookie-файлами. Используйте cookie-файл __session только в том случае, если ваше приложение предоставляет разный контент в зависимости от авторизации пользователя.