If you are building server-rendered Angular or Next.js apps, check out next-generation Firebase App Hosting, a full-stack solution for modern web frameworks.

Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

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é est automatiquement mis en cache sur le CDN. Si vous redéployez le contenu de votre site, Firebase Hosting efface automatiquement tout votre contenu mis en cache sur le CDN jusqu'à la prochaine requête.

Toutefois, é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 de facteurs tels que l'entrée utilisateur ou son identité. Pour tenir compte de cela, les requêtes gérées par le code backend ne sont pas mises en cache sur le CDN par défaut.

Vous pouvez toutefois 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 configurer le comportement de mise en cache pour réduire potentiellement les coûts d'exécution des fonctions, car le contenu est diffusé à partir du CDN plutôt que d'une fonction déclenchée. Pour en savoir plus sur l'optimisation de l'exécution des fonctions et des services dans la Cloud Functions et Cloud Run documentation.

Les requêtes qui renvoient des erreurs 404 font exception. Le CDN met en cache la réponse 404 de votre service à une URL inexistante pendant 10 minutes, de sorte que les requêtes ultérieures pour cette URL sont diffusées à partir du CDN. Si vous modifiez votre service afin que du contenu existe désormais à cette URL, le CDN continue de diffuser les erreurs 404 mises en cache pendant 10 minutes (au maximum), puis diffuse normalement le contenu de cette URL.

Si une réponse 404 contient déjà des en-têtes de mise en cache définis par votre Cloud Functions ou Cloud Run service, ils remplacent la valeur par défaut de 10 minutes et déterminent entièrement le comportement de mise en cache du CDN.

Pour en savoir plus sur le comportement de mise en cache, consultez la documentation pour les développeurs Web de Google .

Définir Cache-Control

L'outil principal que vous utilisez pour gérer le cache du contenu dynamique est l'en-tête Cache-Control. En configurant cet en-tête, vous pouvez indiquer au navigateur et au CDN la durée pendant laquelle votre contenu peut être mis en cache. Dans votre fonction, vous définissez Cache-Control comme suit :

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

Dans cet exemple d'en-tête, les instructions effectuent trois actions :

public : marque la réponse comme public. Cela signifie que le navigateur et les caches intermédiaires (y compris le CDN pour Firebase Hosting) peuvent mettre en cache le contenu.

Remarque : Par défaut, Firebase Hosting définit Cache-Control sur private pour le contenu dynamique. Cela signifie que si vous ne définissez pas explicitement Cache-Control sur public, seul le navigateur de l'utilisateur demandeur est autorisé à mettre en cache le contenu.
max-age : définit l'ancienneté maximale d'une réponse avant qu'elle ne soit revalidée auprès du serveur d'origine. Cela s'applique aux navigateurs. S'il n'y a pas d'en-tête s-maxage, cela s'applique également à tous les autres caches (y compris le CDN).
s-maxage : remplace l'instruction max-age pour les caches partagés (tels que le CDN). Lorsque le CDN trouve une réponse plus ancienne que s-maxage secondes, il la revalide auprès du serveur d'origine. Dans l'exemple d'en-tête, les navigateurs peuvent mettre en cache la réponse pendant cinq minutes, mais le CDN et tous les autres caches intermédiaires peuvent la mettre en cache pendant 10 minutes.

Pour max-age et s-maxage, définissez leurs valeurs sur la durée maximale pendant laquelle vous acceptez que les utilisateurs reçoivent du contenu obsolète. Si une page change toutes les quelques secondes, utilisez une petite valeur de temps. Toutefois, d'autres types de contenu peuvent être mis en cache en toute sécurité pendant des heures, des jours, voire des mois.

Si vous souhaitez empêcher complètement la mise en cache (par exemple, pour toujours diffuser la version la plus récente du contenu statique), vous pouvez configurer cela dans firebase.json à l'aide du headers paramètre :

"hosting": {
  // ...

  // Disables caching for the /posts route
  "headers": [ {
    // Change source to match your dynamically-rendered routes
    "source": "/posts/**",
    "headers": [ {
      "key": "Cache-Control",
      "value": "no-cache, no-store"
    } ]
  } ]
}

Pour en savoir plus sur l'en-tête Cache-Control, consultez le Mozilla Developer Network et la documentation pour les développeurs Web de Google.

Quand le contenu mis en cache est-il diffusé ?

Le navigateur et le CDN mettent en cache votre contenu en fonction des éléments suivants :

Nom d'hôte
Chemin
Chaîne de requête
Contenu des en-têtes de requête spécifiés dans l'en-tête Vary

En-têtes Vary

L' en-têteVary détermine les en-têtes de requête à utiliser pour fournir une réponse appropriée (si le contenu mis en cache est valide ou si le contenu doit être revalidé auprès du serveur d'origine).

Firebase Hosting définit automatiquement un en-tête Vary approprié dans votre réponse pour les situations courantes. La plupart du temps, vous n'avez pas à vous soucier de l'en-tête Vary. Toutefois, dans certains cas d'utilisation avancés, vous pouvez avoir d'autres en-têtes qui doivent affecter le cache. Dans ce cas, vous pouvez définir l'en-tête Vary dans votre réponse. Exemple :

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

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

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

Avec ces paramètres, deux requêtes identiques, mais avec des en-têtes X-My-Custom-Header différents, sont mises en cache séparément. Notez que Hosting ajoute Cookie et Authorization à l'en-tête Vary par défaut lorsqu'une requête est effectuée pour du 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.

Sachez également que :

Seules les requêtes GET et HEAD 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'en-tête Vary. Plus vous ajoutez de paramètres, moins le CDN est susceptible de diffuser du contenu mis en cache. N'oubliez pas non plus que Vary est basé sur les en-têtes de requête, et non sur les en-têtes de réponse.

Utiliser des 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 un comportement de cache CDN efficace. Seul le cookie __session portant un nom spécial est autorisé à être transmis à l'exécution de votre application.

Lorsqu'il est présent, le cookie __session est automatiquement intégré à la clé de cache, ce qui signifie qu'il est impossible pour deux utilisateurs avec des cookies différents de recevoir la réponse mise en cache de l'autre. N'utilisez le cookie __session que si votre application diffuse un contenu différent en fonction de l'autorisation de l'utilisateur.