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 demande.
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 d'éléments tels que les entrées de l'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 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 la même manière, vous pouvez configurer le comportement de mise en cache pour réduire potentiellement les coûts d'exécution des fonctions, car le contenu est servi à partir du CDN plutôt qu'à partir d'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 .
L'exception concerne les requêtes qui renvoient des erreurs 404. Le CDN met en cache la réponse 404 de votre service vers une URL inexistante pendant 10 minutes, afin que les demandes ultérieures pour cette URL soient traitées hors du CDN. Si vous modifiez votre service pour que le contenu existe désormais sur cette URL, le CDN continue de diffuser les 404 mis 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 service Cloud Functions ou Cloud Run, ils remplacent la valeur par défaut de 10 minutes et déterminent entièrement le comportement de mise en cache du CDN.
Apprenez-en davantage sur le comportement de la mise en cache dans la documentation destinée aux développeurs Web de Google .
Définir le contrôle du cache
Le principal outil 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 communiquer à la fois 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 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 commepublic
. Cela signifie que le navigateur et les serveurs intermédiaires (c'est-à-dire le CDN pour Firebase Hosting) peuvent mettre le contenu en cache.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 auprès du serveur d'origine. Dans l'en-tête de l'exemple, nous autorisons le navigateur et le CDN à mettre en cache le contenu pendant cinq minutes (voirs-maxage
ci-dessous pour les contrôles spécifiques à la mise en cache du CDN).s-maxage
— Remplace la directivemax-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 auprès du serveur d'origine. Dans l'en-tête de l'exemple, nous remplaçons le paramètre d'max-age
pour le CDN uniquement et autorisons le CDN à mettre le contenu en cache 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 le fait que les utilisateurs reçoivent du contenu obsolète. Si une page change toutes les quelques secondes, utilisez une petite valeur temporelle. 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 l'en-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 de :
- Le nom d'hôte
- Le chemin
- La chaîne de requête
- Le contenu des en-têtes de requête 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 requête 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é auprès du serveur d'origine).
Firebase Hosting définit automatiquement un en-tête Vary
approprié sur votre réponse pour les situations courantes. La plupart du temps, vous n'avez pas à vous soucier de l'en-tête Vary
. Cependant, dans certains cas d'utilisation avancés, vous pourriez avoir besoin d'autres en-têtes pour affecter le cache. Lorsque c'est le cas, vous pouvez définir l'en-tête Vary
sur votre réponse. Par exemple:
res.set('Vary', 'Accept-Encoding, X-My-Custom-Header');
Dans ce cas, la valeur de l'en-tête Vary
est :
vary: X-My-Custom-Header, x-fh-requested-host, accept-encoding, cookie, authorization
Avec ces paramètres, deux requêtes par ailleurs identiques avec des en-têtes X-My-Custom-Header
différents sont mises en cache séparément. Notez que l'hébergement ajoute Cookie
et Authorization
à l'en-tête Vary
par défaut lorsqu'une demande de contenu dynamique est effectuée. Cela garantit que tout en-tête de session ou d'autorisation de cookie que vous utilisez fait partie de la clé de cache, ce qui évite les fuites accidentelles de contenu.
A noter également :
Seules les requêtes
GET
etHEAD
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 le contenu mis en cache. N'oubliez pas non plus queVary
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 demandes entrantes. Ceci 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 en cache de l'autre. N'utilisez le cookie __session
que si votre application propose un contenu différent en fonction de l'autorisation de l'utilisateur.