App-Inhalte im Cache speichern

Cloud CDN ist ein wichtiger Bestandteil der Unterstützung Ihrer Webanwendung durch App Hosting. Jede Anfrage an Ihr Backend wird zuerst über Cloud CDN geleitet. Inhalte, die bereits im CDN im Cache gespeichert sind, werden sofort an den Nutzer zurückgegeben. Ein Aufruf des Cloud Run-Dienstes, auf dem der Servercode Ihrer Webanwendung ausgeführt wird, ist nicht erforderlich. Weitere Informationen zu den allgemeinen Vorteilen von CDNs finden Sie auf web.dev.

Die grundlegende Cloud CDN-Konfiguration wird zwar von App Hosting festgelegt und kann nicht geändert werden, aber Sie können einiges tun, um das Caching zu optimieren, die Seitenaufbaugeschwindigkeit zu erhöhen, die Menge an abgerechneten nicht im Cache gespeicherten Inhalten zu reduzieren und den Traffic zu Cloud Run zu minimieren.

Cache-fähige Inhalte

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

1. Die Anfrage ist ein GET-Request.

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 kleiner oder gleich 10 MiB.

und KEINE der folgenden Bedingungen ist erfüllt:

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, Next-Router-Segment-Prefetch oder Next-Url.

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 Cache-Steuerungsanweisung.

Hinweis: Next.js hängt Header, die Sie in Ihren Komponenten lesen, automatisch an Vary an. Verwenden Sie next/headers mit Vorsicht.

Hinweis: Routen, die von der Next.js-Middleware betroffen sind, werden nicht im Cache gespeichert.

Hinweis: Next.js speichert auch Inhalte auf dem Server im Cache, die standardmäßig in das speicherinterne Dateisystem der Instanz geschrieben werden. Weitere Informationen finden Sie unter Server-Caching in Next.js konfigurieren.

Verhalten mit Cache-Control-Anweisungen anpassen

Next.js

Next.js legt Cache-Control-Anweisungen implizit auf Grundlage einer Reihe von Faktoren fest. Sie können diese jedoch überschreiben, indem Sie den Header manuell in der Datei next.config.js festlegen. So können Sie beispielsweise dafür sorgen, dass eine Seite nicht 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 standardmäßig keine expliziten Cache-Control-Anweisungen fest. Sie können eigene hinzufügen, indem Sie in Ihren Serverrouten Cache-Control-Header angeben. Beispiel: So erlauben Sie Cloud CDN, alle Seiten eine Stunde lang im Cache zu speichern:

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

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

Oder um sicherzustellen, 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 Cache-Steuerungsanweisungen:

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

In der Firebase-Konsole auf dem Tab App Hosting > Nutzung zeigt das Diagramm „Cloud CDN – Ausgehende Bandbreite“ die bereitgestellten im Cache gespeicherten und nicht im Cache gespeicherten Bytes an. Für jeden Roll-out gibt es eine Markierung. Mit diesem Diagramm können Sie die Effektivität Ihrer Cache-Optimierungsmaßnahmen messen.

Mit dem routenbasierten Monitoring können Sie auch die Cache-Trefferquote für bestimmte Routen in Ihrer Webanwendung aufrufen.