Mettre en cache le contenu de l'application

Cloud CDN est un élément essentiel de la compatibilité de App Hosting's avec votre application Web. 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, ce qui évite un aller-retour au service Cloud Run exécutant le code 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 de plusieurs façons afin d'accélérer le chargement des pages, de réduire le contenu non mis en cache facturé et de 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 une requête GET.

2. Le code d'état de la réponse est 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 instruction max-age ou s-maxage, ou un en-tête Expires avec un horodatage futur.

4. La réponse comporte un en-tête Age ou un en-tête Cache-Control avec une instruction 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, ou Next-Router-Segment-Prefetch.

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

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

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

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

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

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

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

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

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

Instructions respectées

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

Mesurer le trafic mis en cache et non mis en cache

Dans l'onglet App Hosting > Usage (Utilisation) de la console Firebase, le "Cloud CDN - Outgoing Bandwidth" (Cloud CDN – Bande passante sortante) graphique affiche les octets mis en cache et non mis en cache, 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 réussite du cache pour des routes spécifiques de votre application Web grâce à la surveillance basée sur les routes avec Route-based Monitoring.