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

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

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

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

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

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

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

Установить контроль кэша

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

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

В заголовке этого примера директивы делают три вещи:

• public — помечает кеш как 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 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 кэшируются отдельно. Обратите внимание, что хостинг по умолчанию добавляет 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 только в том случае, если ваше приложение обслуживает другой контент в зависимости от авторизации пользователя.