App-Inhalte im Cache speichern

Cloud CDN ist ein wichtiger Bestandteil der Unterstützung von App Hosting für Ihre Webanwendung. Jede Anfrage an Ihr Back-End wird zuerst über Cloud CDN geleitet. Inhalte, die bereits im CDN im Cache gespeichert sind, werden sofort an den Nutzer zurückgegeben. So wird der Cloud Run-Dienst umgangen, auf dem der Servercode Ihrer Webanwendung ausgeführt wird. Weitere Informationen zu den allgemeinen Vorteilen von CDNs finden Sie unter web.dev.

Die grundlegende Cloud CDN-Konfiguration wird von App Hosting festgelegt und kann nicht geändert werden. Es gibt jedoch eine Reihe von Maßnahmen, mit denen Sie das Caching optimieren können, um die Seitenladezeiten zu verkürzen, die Kosten für nicht im Cache gespeicherte Inhalte zu senken und den Traffic zu Cloud Run zu minimieren.

Im Cache speicherbare Inhalte

Cloud CDN speichert Antworten im Cache, wenn ALLE der folgenden Bedingungen erfüllt sind:

Die Anfrage ist eine GET-Anfrage.
Die Antwort hat einen Statuscode von 200, 203, 204, 206, 300, 301, 302, 307, 308, 404, 405, 410, 421, 451 oder 501.
Die Antwort hat einen Cache-Control-Header mit einer max-age- oder s-maxage-Anweisung oder einen Expires-Header mit einem Zeitstempel in der Zukunft.
Die Antwort hat einen Age-Header oder einen Cache-Control-Header mit einer expliziten public-Anweisung.
Die Antwort ist maximal 10 MiB groß.

und KEINE der folgenden Bedingungen erfüllt sind:

Die Antwort hat einen Set-Cookie-Header.
Die Antwort hat einen Vary Header mit einem anderen Wert als 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, oder Next-Router-Segment-Prefetch.
Die Antwort hat einen Cache-Control-Header mit der Anweisung no-store oder private.
Die Anfrage hat einen Cache-Control-Header mit der Anweisung no-store.
Die Anfrage hat einen Authorization-Header, es sei denn, die Antwort hat eine explizite Cache-Control-Anweisung.

Verhalten mit Cache-Control-Anweisungen anpassen

Next.js

Next.js legt Cache-Control-Anweisungen implizit basierend auf einer Reihe von Faktoren fest. Sie können diese jedoch überschreiben, indem Sie den Header manuell in der Datei next.config.js festlegen. So verhindern Sie beispielsweise, dass eine Seite in Cloud CDN im Cache gespeichert wird:

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

Angular

Angular SSR legt keine expliziten Cache-Control-Anweisungen fest. Sie können eigene hinzufügen, indem Sie Cache-Control-Header in Ihren Server routen angeben. So erlauben Sie beispielsweise, dass Cloud CDN alle Seiten eine Stunde lang im Cache speichert:

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

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

Oder um zu verhindern, dass eine bestimmte Seite im Cache gespeichert wird:

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

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

Berücksichtigte Anweisungen

Die Cloud CDN-Instanz von Firebase App Hosting's berücksichtigt die folgenden Cache-Control Anweisungen:

Anweisung	Anfrage	Antwort
`no-store`	Wenn in einer Anfrage vorhanden, wird die Antwort nicht im Cache gespeichert.	Eine Antwort mit `no-store` wird nicht im Cache gespeichert.
`no-cache`	Die Anfrageanweisung `no-cache` wird ignoriert, um zu verhindern, dass Clients den Ursprung möglicherweise initiieren oder dessen nochmalige Validierung erzwingen.	Eine Antwort mit `no-cache` wird im Cache gespeichert, muss aber noch einmal mit dem Ursprung validiert werden, bevor sie bereitgestellt wird.
`public`	–	Diese Anweisung ist für die Cache-Fähigkeit nicht erforderlich. Es empfiehlt sich jedoch, sie für Inhalte aufzunehmen, die von Proxys im Cache gespeichert werden sollen.
`private`	–	Eine Antwort mit der Anweisung `private` wird von Cloud CDN nicht im Cache gespeichert, auch wenn die Antwort ansonsten als cachefähig gilt. Clients wie Browser können das Ergebnis jedoch weiterhin im Cache speichern. Verwenden Sie `no-store`, um das gesamte Caching der Antworten zu verhindern.
`max-age=SECONDS`	Die Anfrageanweisung `max-age` wird ignoriert. Eine im Cache gespeicherte Antwort wird zurückgegeben, als wäre dieser Header nicht in der Anfrage enthalten.	Eine Antwort mit der Anweisung `max-age` wird bis zur festgelegten Anzahl an Sekunden im Cache gespeichert.
`s-maxage=SECONDS`	–	Eine Antwort mit der Anweisung `s-maxage` wird bis zur festgelegten Anzahl an Sekunden im Cache gespeichert. Wenn sowohl `max-age` als auch `s-maxage` vorhanden sind, wird von Cloud CDN `s‑maxage` verwendet. Antworten mit dieser Anweisung werden nicht veraltet bereitgestellt. `s-max-age` (zwei Bindestriche) ist für das Caching nicht anwendbar.
`max-stale=SECONDS`	Die Anfrageanweisung `max-stale` gibt die maximale Veralterung in Sekunden an, die der Client akzeptiert. Cloud CDN berücksichtigt dies und gibt eine veraltete Cache-Antwort nur zurück, wenn die Veralterung der Antwort geringer als der Wert der Anweisung `max-stale` ist. Andernfalls wird die Anfrage noch einmal validiert, bevor die Anfrage bereitgestellt wird.	–
`stale-while-revalidate=SECONDS`	–	Eine Antwort mit `stale-while-revalidate` wird bis zur festgelegten Anzahl an Sekunden für einen Client bereitgestellt, während die nochmalige Validierung asynchron erfolgt.
`must-revalidate`	–	Eine Antwort mit `must-revalidate` wird nach dem Ablauf noch einmal mit dem Ursprungsserver validiert. Antworten mit dieser Anweisung werden nicht veraltet bereitgestellt.
`proxy-revalidate`		Eine Antwort mit `proxy-revalidate` wird nach dem Ablauf noch einmal mit dem Ursprungsserver validiert. Antworten mit dieser Anweisung werden nicht veraltet bereitgestellt.
`no-transform`	–	Cloud CDN wendet keine Transformationen an.

Im Cache gespeicherten und nicht im Cache gespeicherten Traffic messen

Auf dem Tab App Hosting > Nutzung in der Firebase Console zeigt das Diagramm „Cloud CDN – Ausgehende Bandbreite“ die Anzahl der bereitgestellten im Cache gespeicherten und nicht im Cache gespeicherten Byte an. Außerdem ist für jede Bereitstellung eine Markierung vorhanden. Mit diesem Diagramm können Sie die Effektivität Ihrer Cache-Optimierungsmaßnahmen messen.

Mit der routenbasierten Überwachung können Sie auch die Cache-Trefferrate für bestimmte Routen in Ihrer Webanwendung ansehen.