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 кэшировать контент в течение пяти минут (см.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основан на заголовках запроса , а не на заголовках ответа .
Использование файлов cookie
При использовании Firebase Hosting совместно с Cloud Functions или Cloud Run файлы cookie обычно удаляются из входящих запросов. Это необходимо для обеспечения эффективного кэширования CDN. Только специально именованные файлы cookie __session могут быть переданы в приложение.
При наличии cookie-файла __session он автоматически становится частью ключа кэша, что означает, что два пользователя с разными cookie-файлами не смогут получить кэшированный ответ друг друга. Используйте cookie-файл __session только в том случае, если ваше приложение предоставляет разный контент в зависимости от авторизации пользователя.