Cache-Verhalten verwalten

Firebase Hosting verwendet ein leistungsstarkes globales CDN, um Ihre Website so schnell wie möglich zu machen.

Alle angeforderten statischen Inhalte werden automatisch im CDN-Cache gespeichert. Wenn Sie die Inhalte Ihrer Website neu bereitstellen, löscht Firebase Hosting automatisch alle Ihre im CDN zwischengespeicherten Inhalte bis zur nächsten Anfrage.

Da bei den Diensten Cloud Functions und Cloud Run Inhalte jedoch dynamisch generiert werden, können die Inhalte für eine bestimmte URL je nach Faktoren wie Nutzereingaben oder der Identität des Nutzers variieren. Aus diesem Grund werden Anfragen, die von Backend-Code verarbeitet werden, standardmäßig nicht im CDN-Cache gespeichert.

Sie können jedoch das Caching-Verhalten für dynamische Inhalte konfigurieren. Wenn eine Funktion beispielsweise nur in regelmäßigen Abständen neue Inhalte generiert, können Sie die Leistung Ihrer App verbessern, indem Sie die generierten Inhalte für mindestens kurze Zeit im Cache speichern.

Sie können das Caching-Verhalten auf ähnliche Weise konfigurieren, um die Kosten für die Funktionsausführung zu senken, da die Inhalte über das CDN und nicht über eine ausgelöste Funktion bereitgestellt werden. Weitere Informationen zum Optimieren der Funktionsausführung und der Dienste finden Sie in der Dokumentation zu Cloud Functions und Cloud Run.

Ausgenommen sind Anfragen, die 404-Fehler zurückgeben. Das CDN speichert die 404-Antwort Ihres Dienstes auf eine nicht vorhandene URL für 10 Minuten im Cache, sodass nachfolgende Anfragen für diese URL aus dem CDN bereitgestellt werden. Wenn Sie Ihren Dienst so ändern, dass Inhalte jetzt unter dieser URL verfügbar sind, werden alle im Cache gespeicherten 404-Fehler vom CDN weiterhin für maximal 10 Minuten bereitgestellt. Danach werden Inhalte von dieser URL normal bereitgestellt.

Wenn eine 404-Antwort bereits Caching-Header enthält, die von Ihrem Cloud Functions- oder Cloud Run-Dienst festgelegt wurden, überschreiben sie den Standardwert von 10 Minuten und bestimmen das Caching-Verhalten des CDN vollständig.

Weitere Informationen zum Caching-Verhalten finden Sie in der Webentwicklerdokumentation von Google.

Cachesteuerung festlegen

Das wichtigste Tool zum Verwalten des Caches für dynamische Inhalte ist der Header Cache-Control. Mit diesem Header können Sie sowohl dem Browser als auch dem CDN mitteilen, wie lange Ihre Inhalte im Cache gespeichert werden dürfen. In Ihrer Funktion legen Sie Cache-Control so fest:

res.set('Cache-Control', 'public, max-age=300, s-maxage=600');

In diesem Beispielheader werden durch die Direktiven drei Dinge erreicht:

  • public: Markiert die Antwort als public. Das bedeutet, dass sowohl der Browser als auch Zwischenspeicher (einschließlich des CDN für Firebase Hosting) die Inhalte im Cache speichern können.

  • max-age: Legt fest, wie alt eine Antwort sein darf, bevor sie beim Ursprungsserver neu validiert werden muss. Dies gilt für Browser. Wenn kein s-maxage-Header vorhanden ist, gilt es auch für alle anderen Caches (einschließlich des CDN).

  • s-maxage: Überschreibt die Anweisung max-age für freigegebene Caches (z. B. das CDN). Wenn das CDN eine Antwort findet, die älter als s-maxage Sekunden ist, wird sie vom CDN mit dem Ursprungsserver neu validiert. Im Beispielheader können Browser die Antwort 5 Minuten lang im Cache speichern, das CDN und alle anderen Zwischencaches jedoch 10 Minuten lang.

Legen Sie für max-age und s-maxage die Werte auf die längste Zeit fest, die Sie für die Anzeige veralteter Inhalte akzeptieren. Wenn sich eine Seite alle paar Sekunden ändert, verwenden Sie einen kleinen Zeitwert. Andere Arten von Inhalten können jedoch problemlos stunden-, tage- oder sogar monatelang im Cache gespeichert werden.

Wenn Sie das Caching vollständig verhindern möchten (z. B. um immer die neueste Version statischer Inhalte bereitzustellen), können Sie dies in firebase.json mit der Einstellung headers konfigurieren:

"hosting": {
  // ...

  // Disables caching for the /posts route
  "headers": [ {
    // Change source to match your dynamically-rendered routes
    "source": "/posts/**",
    "headers": [ {
      "key": "Cache-Control",
      "value": "no-cache, no-store"
    } ]
  } ]
}

Weitere Informationen zum Cache-Control-Header finden Sie im Mozilla Developer Network und in der Webentwicklerdokumentation von Google.

Wann werden Inhalte aus dem Cache bereitgestellt?

Der Browser und das CDN speichern Ihre Inhalte im Cache basierend auf:

  • Der Hostname
  • Der Pfad
  • Der Abfragestring
  • Der Inhalt der in Vary-Header angegebenen Anfrageheader

Vary-Header

Der Vary-Header bestimmt, welche Anfrageheader verwendet werden sollen, um eine geeignete Antwort zu liefern. Er gibt an, ob der Cache-Inhalt gültig ist oder ob der Inhalt mit dem Ursprungsserver neu validiert werden soll.

Firebase Hosting legt automatisch einen geeigneten Vary-Header in Ihrer Antwort für häufige Situationen fest. In den meisten Fällen müssen Sie sich keine Gedanken über den Vary-Header machen. In einigen erweiterten Anwendungsfällen sind jedoch möglicherweise andere Header erforderlich, um den Cache zu beeinflussen. In diesem Fall können Sie den Header Vary in Ihrer Antwort festlegen. Beispiel:

res.set('Vary', 'Accept-Encoding, X-My-Custom-Header');

In diesem Fall lautet der Wert des Headers Vary:

vary: X-My-Custom-Header, x-fh-requested-host, accept-encoding, cookie, authorization

Mit diesen Einstellungen werden zwei ansonsten identische Anfragen mit unterschiedlichen X-My-Custom-Header-Headern separat im Cache gespeichert. Mit Hosting werden standardmäßig Cookie und Authorization zum Vary-Header hinzugefügt, wenn eine Anfrage für dynamische Inhalte gestellt wird. So wird sichergestellt, dass alle von Ihnen verwendeten Autorisierungsheader für Sitzungen oder Cookies Teil des Cache-Schlüssels sind. Dadurch wird ein versehentliches Offenlegen von Inhalten verhindert.

Beachten Sie außerdem Folgendes:

  • Nur GET- und HEAD-Anfragen können im Cache gespeichert werden. HTTPS-Anfragen mit anderen Methoden werden nie im Cache gespeichert.

  • Seien Sie vorsichtig, wenn Sie dem Vary-Header Einstellungen hinzufügen. Je mehr Einstellungen Sie hinzufügen, desto unwahrscheinlicher ist es, dass das CDN Inhalte aus dem Cache bereitstellen kann. Vary basiert auf Anfrage-Headern, nicht auf Antwort-Headern.

Verwendung von Cookies

Wenn Sie Firebase Hosting zusammen mit Cloud Functions oder Cloud Run verwenden, werden Cookies in der Regel aus eingehenden Anfragen entfernt. Dies ist erforderlich, um ein effizientes CDN-Cacheverhalten zu ermöglichen. Nur das speziell benannte __session-Cookie darf an die Ausführung Ihrer App weitergegeben werden.

Wenn das __session-Cookie vorhanden ist, wird es automatisch in den Cache-Schlüssel aufgenommen. Das bedeutet, dass zwei Nutzer mit unterschiedlichen Cookies nicht die zwischengespeicherte Antwort des jeweils anderen erhalten können. Verwenden Sie das __session-Cookie nur, wenn Ihre App je nach Nutzerautorisierung unterschiedliche Inhalte bereitstellt.