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

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 для веб-разработчиков .

Установите Cache-Control

Основным инструментом, который вы используете для управления кешем динамического контента, является заголовок Cache-Control . Настроив этот заголовок, вы можете сообщить браузеру и CDN, как долго ваш контент может быть кэширован. В вашей функции вы устанавливаете Cache-Control следующим образом:

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

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

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

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

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

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

Вы можете узнать больше о заголовке 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 только в том случае, если ваше приложение предоставляет другой контент в зависимости от авторизации пользователя.