Google s'est engagé à promouvoir l'équité raciale pour les communautés noires. Regarde comment.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

Gérer le comportement du cache

Firebase Hosting utilise un puissant CDN global 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 statique mis en cache sur le CDN jusqu'à la prochaine demande.

Cependant, étant donné que Cloud Functions et les services 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 l'entrée de l'utilisateur ou l'identité de l'utilisateur. Pour en tenir compte, les requêtes gérées par le code backend ne sont pas mises en cache 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 génère du nouveau contenu uniquement 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 de temps.

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 la documentation Cloud Functions et Cloud Run .

En savoir plus sur le comportement de la mise en cache dans la documentation des développeurs Web de Google.

Définir le contrôle du cache

L'outil principal que vous utilisez pour gérer le cache du contenu dynamique est l'en Cache-Control tête Cache-Control . En configurant cet en-tête, vous pouvez communiquer à la fois au navigateur et au CDN pendant 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 public . Cela signifie que le navigateur et les serveurs intermédiaires (c'est-à-dire le CDN pour Firebase Hosting) peuvent mettre en cache le contenu.

  • max-age - Indique au navigateur et au CDN combien de secondes ils peuvent mettre en cache le contenu. Lorsque le délai défini expire, le navigateur et le CDN doivent revalider le contenu avec le serveur d'origine. Dans l'exemple d'en-tête, nous autorisons le navigateur et le CDN à mettre en cache le contenu pendant cinq minutes (voir s-maxage ci s-maxage dessous pour des contrôles spécifiques pour la mise en cache CDN).

  • s-maxage - Remplace la directive max-age pour la mise en cache CDN uniquement; 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'exemple d'en-tête, nous remplaçons le paramètre de max-age pour le CDN uniquement et autorisons le CDN à mettre en cache le contenu pendant dix minutes.

Pour max-age et s-maxage , définissez leurs valeurs sur la durée la plus longue pendant laquelle vous êtes à l'aise avec les utilisateurs recevant du contenu obsolète. 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 ou même des mois.

Vous pouvez en savoir plus sur l'en Cache-Control tête Cache-Control sur le Mozilla Developer Network et dans la documentation des 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:

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

Varier les en-têtes

L'en- tête Vary détermine quels en-têtes de demande doivent être utilisés 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).

La plupart du temps, vous n'avez pas à vous soucier de l'en-tête Vary . Firebase Hosting définit automatiquement un en-tête Vary approprié sur votre réponse pour les situations courantes. Cela inclut de vous assurer que tout cookie de session ou en-tête d'autorisation que vous utilisez fait partie de la clé de cache, ce qui empêche les fuites accidentelles de contenu.

Dans certains cas d'utilisation avancés, vous pouvez avoir d'autres en-têtes dont vous avez besoin pour affecter le cache. Lorsque c'est le cas, vous pouvez simplement définir l'en-tête Vary sur votre réponse:

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

Avec ces paramètres, deux demandes par ailleurs identiques avec des en X-My-Custom-Header têtes X-My-Custom-Header sont mises en cache séparément.

Utilisation des cookies

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

Lorsqu'il est présent, le cookie __session fait automatiquement partie de 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. __session cookie __session si votre application __session un contenu différent en fonction de l'autorisation de l'utilisateur.