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. Der Cloud Run-Dienst, auf dem der Servercode Ihrer Web-App ausgeführt wird, wird dabei übersprungen. Weitere Informationen zu den allgemeinen Vorteilen von CDNs finden Sie auf web.dev.

Die grundlegende Cloud CDN-Konfiguration wird durch App Hosting festgelegt und kann nicht geändert werden. Es gibt jedoch eine Reihe von Maßnahmen, die Sie ergreifen können, um das Caching zu optimieren und so die Seitenladezeiten zu verkürzen, die Abrechnung von nicht im Cache gespeicherten Inhalten zu reduzieren 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:

  1. Die Anfrage ist ein GET

  2. Die Antwort hat den Statuscode 200, 203, 204, 206, 300, 301, 302, 307, 308, 404, 405, 410, 421, 451 oder 501.

  3. 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.

  4. Die Antwort hat einen Age-Header oder einen Cache-Control-Header mit einer expliziten public-Anweisung.

  5. Die Antwort ist höchstens 10 MiB groß.

KEINE der folgenden Aussagen ist richtig:

  1. Die Antwort hat einen Set-Cookie-Header

  2. 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.

  3. Die Antwort hat einen Cache-Control-Header mit der Anweisung no-store oder private.

  4. Die Anfrage hat einen Cache-Control-Header mit einer no-store-Anweisung.

  5. Die Anfrage hat einen Authorization-Header, es sei denn, die Antwort hat eine explizite Cachesteuerungsanweisung.

Verhalten mit Cache-Control-Anweisungen anpassen

Next.js

Next.js legt Cache-Control-Anweisungen implizit anhand einer Reihe von Faktoren fest. Sie können diese jedoch überschreiben, indem Sie den Header manuell in Ihrer next.config.js-Datei 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

Bei Angular SSR werden standardmäßig keine expliziten Cache-Control-Anweisungen festgelegt. Sie können eigene hinzufügen, indem Sie Cache-Control-Header in Ihren Serverrouten angeben. Beispiel: So erlauben Sie Cloud CDN, alle Seiten für eine Stunde zu cachen:

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

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

So sorgen Sie dafür, dass eine bestimmte Seite nicht 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 berücksichtigt die folgenden Cachesteuerungsanweisungen:

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 SECONDS im Cache gespeichert.
s-maxage=SECONDS – Eine Antwort mit der Anweisung s-maxage wird bis zur festgelegten Anzahl an SECONDS im Cache gespeichert. Wenn sowohl max-age als auch s-maxage vorhanden sind, wird s‑maxage von Cloud CDN 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 zu SECONDS 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.

Zwischengespeicherten und nicht zwischengespeicherten Traffic messen

Im Diagramm „Cloud CDN – Ausgehende Bandbreite“ auf dem Tab Nutzung der App Hosting-Konsole werden die bereitgestellten zwischengespeicherten und nicht zwischengespeicherten Byte angezeigt. Außerdem ist für jeden Roll-out eine Markierung vorhanden. Anhand dieses Diagramms können Sie die Wirksamkeit Ihrer Cache-Optimierungsmaßnahmen messen.

Mit routenbasiertem Monitoring können Sie auch die Cache-Trefferrate für bestimmte Routen in Ihrer Web-App ansehen.