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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы можете узнать больше о Cache-Control заголовка на Mozilla Developer Network и в Google, документации веб - разработчиков .

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

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

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

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

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

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

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

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