Join us for Firebase Summit on November 10, 2021. Tune in to learn how Firebase can help you accelerate app development, release with confidence, and scale with ease. Register

Gérer le comportement du cache

Firebase Hosting utilise un puissant CDN mondial pour rendre votre site aussi rapide que possible.

Tout contenu statique demandée est automatiquement mis en cache sur le CDN. Si vous redéployez le contenu de votre site, Firebase Hosting efface automatiquement tout votre contenu statique mis en cache sur le CDN jusqu'à la prochaine requête.

Cependant, étant donné que les services Cloud Functions et Cloud Run génèrent du contenu de manière dynamique, le contenu d'une URL donnée peut varier en fonction d'éléments tels que la saisie de l'utilisateur ou l'identité de l'utilisateur. Pour en tenir compte, les demandes qui sont gérées par le code back - end ne cache pas sur le CDN par défaut.

Vous pouvez, cependant, configurer le comportement de mise en cache pour le contenu dynamique. Par exemple, si une fonction ne génère du nouveau contenu que périodiquement, vous pouvez accélérer votre application en mettant en cache le contenu généré pendant au moins une courte période.

Vous pouvez également potentiellement réduire les coûts d'exécution des fonctions car le contenu est servi à partir du CDN plutôt que via une fonction déclenchée. En savoir plus sur l' optimisation de l' exécution des fonctions et des services dans les fonctions de Cloud et cloud Exécuter la documentation.

En savoir plus sur le comportement de mise en cache dans Google documentation développeur web .

Définir le contrôle du cache

Le principal outil que vous utilisez pour gérer le cache pour le contenu dynamique est le Cache-Control en- tête. En configurant cet en-tête, vous pouvez communiquer à la fois au navigateur et au CDN combien de temps votre contenu peut être mis en cache. Dans votre fonction, vous définissez Cache-Control comme ceci:

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

Dans cet exemple d'en-tête, les directives font trois choses :

  • public - marque le cache comme du public . Cela signifie que les deux le navigateur et les serveurs intermédiaires ( ce qui signifie le CDN pour Firebase Hosting) peut mettre en cache le contenu.

  • max-age - Indique le navigateur et le CDN combien de secondes ils peuvent mettre en cache le contenu. A l'expiration du délai défini, le navigateur et le CDN doivent revalider le contenu auprès du serveur d'origine. Dans l' en- tête par exemple, nous permettons le navigateur et le CDN pour mettre en cache le contenu de cinq minutes (voir s-maxage ci - dessous pour les contrôles spécifiques pour la mise en cache CDN).

  • s-maxage - Dépasse la max-age directive pour la mise en cache CDN seule; indique au CDN combien de secondes il peut mettre en cache le contenu. Lorsque le délai défini expire, le CDN doit revalider le contenu avec le serveur d'origine. Dans l' en- tête par exemple, nous surchargeons le réglage max-age pour le CDN seulement et permettant au CDN de mettre en cache le contenu pendant dix minutes.

Pour max-age et s-maxage , définir leurs valeurs à la plus longue période de temps que vous êtes à l' aise avec les utilisateurs recevant le contenu périmé. Si une page change toutes les quelques secondes, utilisez une petite valeur de temps. Cependant, d'autres types de contenu peuvent être mis en cache en toute sécurité pendant des heures, des jours, voire des mois.

Vous pouvez en savoir plus sur le Cache-Control en- tête sur le réseau Mozilla Developer et Google documentation développeur web .

Quand le contenu mis en cache est-il servi ?

Le navigateur et le CDN mettent en cache votre contenu en fonction de :

  • Le nom d'hôte
  • Le chemin
  • La chaîne de requête
  • Le contenu de l' en- tête de requête spécifiés dans la Vary en- tête

Varier les en-têtes

La Vary en- tête détermine que les en- têtes d' appel doit être utilisé pour fournir une réponse appropriée (si le contenu mis en cache est valide ou si le contenu doit être revalidé avec le serveur d'origine).

Firebase Hosting définit automatiquement un approprié Vary en- tête de votre réponse pour les situations communes. La plupart du temps, vous n'avez pas besoin de vous soucier du Vary - tête. Cependant, dans certains cas d'utilisation avancés, vous pouvez avoir d'autres en-têtes dont vous avez besoin pour affecter le cache. Lorsque tel est le cas, vous pouvez régler la Vary tête de votre réponse. Par exemple:

res.set('Vary', 'Accept-Encoding, X-My-Custom-Header');

Dans ce cas, la valeur de la Vary en- tête est la suivante :

vary: X-My-Custom-Header, x-fh-requested-host, accept-encoding, cookie, authorization

Avec ces paramètres, deux requêtes identiques par ailleurs avec différents X-My-Custom-Header en X-My-Custom-Header en- têtes sont mises en cache séparément. Notez que l' hébergement ajoute Cookie et Authorization à l' Vary - tête par défaut lorsqu'une demande est faite pour le contenu dynamique. Cela garantit que tout en-tête d'autorisation de session ou de cookie que vous utilisez fait partie de la clé de cache, ce qui empêche les fuites accidentelles de contenu.

A noter également :

  • Seul GET et HEAD demandes peuvent être mises en cache. Les requêtes HTTPS utilisant d'autres méthodes ne sont jamais mises en cache.

  • Soyez prudent lorsque vous ajoutez des paramètres à l' Vary - tête. Plus vous ajoutez de paramètres, moins il est probable que le CDN puisse servir du contenu mis en cache. Rappelez - vous aussi que Vary est basé sur les en- têtes de demande, pas les en- têtes de réponse.

Utilisation de cookies

Lorsque vous utilisez Firebase Hosting avec Cloud Functions ou Cloud Run, les cookies sont généralement supprimés des requêtes entrantes. Cela est nécessaire pour permettre CDN efficace le comportement du cache . Seul le nom spécialement __session cookie est autorisé à passer à travers l'exécution de votre application.

Quand il est présent, le __session cookie est automatiquement fait une partie de la clé du cache, ce qui signifie qu'il est impossible pour deux utilisateurs avec des cookies différents pour recevoir les autres de réponse mises en cache. Utilisez uniquement le __session cookie si votre application sert un contenu différent en fonction de l' autorisation de l' utilisateur.