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 . Настроив этот заголовок, вы можете сообщить браузеру и CDN, как долго ваш контент может кэшироваться. В вашей функции вы устанавливаете Cache-Control следующим образом:
res.set('Cache-Control', 'public, max-age=300, s-maxage=600');
В этом примере заголовка директивы выполняют три функции:
public— отмечает кэш какpublic. Это означает, что и браузер , и промежуточные серверы (то есть CDN для Firebase Hosting ) могут кэшировать контент.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 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основан на заголовках запроса , а не на заголовках ответа .
Использование куки-файлов
При использовании Firebase Hosting вместе с Cloud Functions или Cloud Run файлы cookie обычно удаляются из входящих запросов. Это необходимо для обеспечения эффективного поведения кэша CDN. Только специально названный файл cookie __session может передаваться для выполнения вашего приложения.
При наличии куки-файл __session автоматически становится частью ключа кэша, что означает, что два пользователя с разными куки-файлами не смогут получить кэшированный ответ друг друга. Используйте куки-файл __session только в том случае, если ваше приложение обслуживает разный контент в зависимости от авторизации пользователя.