Mettre en cache le contenu de l'application

Cloud CDN est un élément essentiel de la prise en charge de votre application Web par App Hosting. Chaque requête adressée à votre backend passe d'abord par Cloud CDN. Le contenu déjà mis en cache dans le CDN est immédiatement renvoyé à l'utilisateur, sans passer par le service Cloud Run qui exécute le code du serveur de votre application Web. Pour en savoir plus sur les avantages généraux des CDN, consultez web.dev.

Bien que la configuration de base de Cloud CDN soit définie par App Hosting et ne puisse pas être modifiée, vous pouvez optimiser la mise en cache pour augmenter la vitesse de chargement des pages, réduire le contenu non mis en cache facturé et minimiser le trafic vers Cloud Run.

Contenu pouvant être mis en cache

Cloud CDN stocke les réponses dans le cache si TOUTES les conditions suivantes sont remplies :

1. La requête est de type GET.

2. La réponse comporte un code d'état 200, 203, 204, 206, 300, 301, 302, 307, 308, 404, 405, 410, 421, 451 ou 501.

3. La réponse comporte un en-tête Cache-Control avec une directive max-age ou s-maxage, ou un en-tête Expires avec un code temporel situé dans le futur.

4. La réponse comporte un en-tête Age ou un en-tête Cache-Control avec une directive public explicite.

5. La taille de la réponse est inférieure ou égale à 10 Mio.

et AUCUNE des conditions suivantes n'est remplie :

1. La réponse comporte un en-tête Set-Cookie.

2. La réponse comporte un en-tête Vary avec une valeur autre que Accept, Accept-Encoding, Access-Control-Request-Headers, Access-Control-Request-Method, Origin, Sec-Fetch-Dest, Sec-Fetch-Mode, Sec-Fetch-Site, X-Goog-Allowed-Resources, X-Origin, RSC, Next-Router-State-Tree, Next-Router-Prefetch, Next-Router-Segment-Prefetch ou Next-Url.

3. La réponse comporte un en-tête Cache-Control avec une directive no-store ou private.

4. La requête comporte un en-tête Cache-Control avec une directive no-store.

5. La requête comporte un en-tête Authorization, sauf si la réponse comporte une directive de contrôle du cache explicite.

Remarque : Next.js ajoute automatiquement les en-têtes que vous lisez dans vos composants à Vary. Utilisez next/headers avec précaution.

Remarque : Les routes affectées par le middleware Next.js ne sont pas mises en cache.

Remarque : Next.js met également en cache le contenu sur le serveur, qui est écrit par défaut dans le système de fichiers en mémoire de l'instance. Consultez Configurer la mise en cache du serveur sur Next.js.

Personnaliser le comportement avec des directives de contrôle du cache

Next.js

Next.js définit implicitement les directives de contrôle du cache en fonction d'un certain nombre de facteurs. Toutefois, vous pouvez les remplacer en définissant manuellement l'en-tête dans votre fichier next.config.js. Par exemple, pour vous assurer qu'une page n'est pas mise en cache dans Cloud CDN :

  /** @type {import('next').NextConfig} */
  const nextConfig = {
      headers: async () => [{
          source: "/YOUR_PRIVATE_PAGE",
          headers: [{
              key: "Cache-Control",
              value: "private"
          }],
      }],
  };

Angular

Le SSR Angular ne définit pas de directives cache-control explicites par défaut. Vous pouvez ajouter les vôtres en spécifiant des en-têtes de contrôle du cache dans vos routes de serveur. Par exemple, pour autoriser Cloud CDN à mettre en cache toutes les pages pendant une heure :

import { RenderMode, ServerRoute } from '@angular/ssr';

export const serverRoutes: ServerRoute[] = [
  {
    path: '**',
    renderMode: RenderMode.Prerender,
    headers: {
      'Cache-Control': 'public, max-age=3600',
    }
  }
];

Pour vous assurer qu'une page spécifique ne sera pas mise en cache :

import { RenderMode, ServerRoute } from '@angular/ssr';

export const serverRoutes: ServerRoute[] = [
  // ... other routes
  {
    path: 'YOUR_PRIVATE_PAGE',
    renderMode: RenderMode.Server,
    headers: {
      'Cache-Control': 'private',
    }
  }
];

Directives respectées

L'instance Cloud CDN de Firebase App Hosting respecte les directives de contrôle du cache suivantes :

Directive	Requête	Réponse
no-store	Lorsqu'elle est présente dans une requête, la réponse n'est pas mise en cache.	Une réponse avec no-store n'est pas mise en cache.
no-cache	La directive de requête no-cache est ignorée pour empêcher les clients de lancer ou de forcer la revalidation dans l'origine.	Une réponse avec no-cache est mise en cache, mais doit être revalidée avec l'origine avant d'être diffusée.
public	N/A	Cette directive n'est pas obligatoire pour la mise en cache, mais il est recommandé de l'inclure pour le contenu qui doit être mis en cache par les proxys.
private	N/A	Une réponse avec la directive private n'est pas mise en cache par Cloud CDN, même si elle est considérée comme pouvant être mise en cache. Il est toujours possible que les clients (tels que les navigateurs) mette en cache le résultat. Utilisez no-store pour empêcher toute mise en cache des réponses.
max-age=SECONDS	L'instruction de requête max-age est ignorée. Une réponse mise en cache est renvoyée comme si cet en-tête n'était pas inclus dans la requête.	Une réponse avec la directive max-age est mise en cache jusqu'à la valeur SECONDS définie.
s-maxage=SECONDS	N/A	Une réponse avec la directive s-maxage est mise en cache jusqu'à la valeur SECONDS définie. Si max-age et s-maxage sont présents, s‑maxage est utilisé par Cloud CDN. Les réponses comportant cette instruction ne sont pas diffusées lorsqu'elles sont obsolètes. La valeur s-max-age (deux traits d'union) n'est pas valide pour la mise en cache.
max-stale=SECONDS	La directive de requête max-stale définit l'obsolescence maximale (en secondes) que le client est prêt à accepter. Cloud CDN respecte ce principe et ne renvoie une réponse mise en cache obsolète que si l'obsolescence de la réponse est inférieure à la directive max-stale. Sinon, il revalide avant de diffuser la requête.	N/A
stale-while-revalidate=SECONDS	N/A	Une réponse avec stale-while-revalidate est diffusée à un client pendant une durée maximale de SECONDS, tandis que la revalidation a lieu de manière asynchrone.
must-revalidate	N/A	Une réponse avec must-revalidate est revalidée avec le serveur d'origine après son expiration. Les réponses comportant cette instruction ne sont pas diffusées lorsqu'elles sont obsolètes.
proxy-revalidate		Une réponse avec proxy-revalidate est revalidée avec le serveur d'origine après son expiration. Les réponses comportant cette instruction ne sont pas diffusées lorsqu'elles sont obsolètes.
no-transform	N/A	Aucune transformation n'est appliquée par Cloud CDN.

Mesurer le trafic mis en cache et non mis en cache

Dans l'onglet App Hosting > Utilisation de la console Firebase, le graphique "Cloud CDN – Bande passante sortante" affiche les octets mis en cache et non mis en cache diffusés, et comporte une marque pour chaque déploiement. Vous pouvez utiliser ce graphique pour mesurer l'efficacité de vos efforts d'optimisation du cache.

Vous pouvez également afficher le taux de succès de cache pour des routes spécifiques de votre application Web avec la surveillance basée sur les routes.