Gérer le comportement du cache

Firebase Hosting utilise un puissant CDN mondial pour rendre votre site aussi rapide 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 tous vos le contenu mis en cache sur le CDN jusqu'à la prochaine requête.

Toutefois, comme 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 les entrées utilisateur ou l'identité de l'utilisateur. Pour tenir compte de cela, les demandes gérés par le code backend ne sont pas mis en cache sur le CDN par défaut.

Vous pouvez toutefois configurer le comportement de mise en cache du contenu dynamique. Pour Par exemple, si une fonction ne génère de 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. En savoir plus sur l'optimisation de l'exécution des fonctions et des services dans les Cloud Functions et Cloud Run dans la documentation Google Cloud.

Les requêtes qui renvoient des erreurs 404 font exception à cette règle. Le CDN met en cache votre à une URL inexistante pendant 10 minutes, de sorte que les opérations suivantes pour cette URL sont diffusées depuis le CDN. Si vous changez de service afin que le contenu existe désormais à cette URL, le CDN continue de diffuser les contenus mis en cache 404 pendant 10 minutes au maximum, puis affiche 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, elles remplacent les (10 minutes par défaut) et déterminent entièrement le comportement de mise en cache le CDN.

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

Définir Cache-Control

Le principal outil que vous utilisez pour gérer le cache du contenu dynamique est 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 directives remplissent trois fonctions :

  • 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 le contenu.

  • max-age : indique au navigateur et au CDN le nombre de secondes qu'ils peuvent mettre en cache le contenu. Lorsque le délai défini expire, le navigateur et le CDN doivent valider à nouveau le contenu auprès du serveur d'origine. Dans l'exemple d'en-tête, nous permettant au navigateur et au CDN de mettre en cache le contenu pendant cinq minutes (voir s-maxage ci-dessous pour des commandes spécifiques à la mise en cache CDN).

  • s-maxage : remplace la directive max-age pour la mise en cache CDN uniquement. raconte au CDN, en secondes, pendant lequel le contenu peut être mis en cache. Lorsque l'heure définie expire, le CDN doit revalider le contenu auprès du serveur d'origine. Dans exemple d'en-tête, nous remplaçons le paramètre de max-age pour le CDN uniquement et laisser le CDN mettre en cache le contenu pendant 10 minutes.

Pour max-age et s-maxage, définissez leurs valeurs sur la durée la plus longue. que vous acceptez que les utilisateurs accèdent à du contenu obsolète. Si une page change toutes les quelques secondes, utilisez une petite valeur temporelle. Toutefois, d'autres types de contenus être mis en cache pendant des heures, des jours, voire des mois.

Pour en savoir plus sur l'en-tête Cache-Control, consultez le Mozilla Developer Network et la documentation destinée aux 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:

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

En-têtes Vary

La En-tête Vary détermine quels en-têtes de requête doivent être utilisés pour fournir un de réponse (si le contenu mis en cache est valide ou s'il doit être revalidée avec le serveur d'origine).

Firebase Hosting définit automatiquement un en-tête Vary approprié sur votre pour les situations courantes. La plupart du temps, vous n'avez pas à vous inquiéter sur l'en-tête Vary. Toutefois, dans certains cas d'utilisation avancés, autres en-têtes dont vous avez besoin pour affecter le cache. Lorsque c’est le cas, vous pouvez définir l'en-tête Vary sur 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 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 conçues pour le contenu dynamique. Ainsi, toute autorisation de session ou de cookie que vous utilisez est intégré à la clé de cache, ce qui évite 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 il est probable que le CDN puisse diffuser du contenu mis en cache. Rappelez-vous également que Vary est basé sur les en-têtes de requête, et non sur les en-têtes de réponse. en-têtes.

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 spécialement désigné peut être transmis à la de votre application.

S'il est présent, le cookie __session est automatiquement intégré au cache ce qui signifie qu'il est impossible pour deux utilisateurs ayant des cookies différents de reçoivent 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.