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 im Cache gespeichert. Wenn Sie die Inhalte Ihrer Website noch einmal bereitstellen, löscht Firebase Hosting automatisch alle Ihre im CDN im Cache gespeicherten Inhalte bis zur nächsten Anfrage.

Da Cloud Functions und Cloud Run Dienste Inhalte dynamisch generieren, können sich die Inhalte für eine bestimmte URL je nach Faktoren wie Nutzereingaben oder der Identität des Nutzers unterscheiden. Aus diesem Grund werden Anfragen, die von Back-End-Code verarbeitet werden, standardmäßig nicht im CDN im 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 Ihre App beschleunigen, indem Sie die generierten Inhalte für einen kurzen Zeitraum im Cache speichern.

Sie können das Caching-Verhalten auch so konfigurieren, dass die Kosten für die Funktionsausführung möglicherweise gesenkt werden, da die Inhalte vom CDN und nicht von einer ausgelösten Funktion bereitgestellt werden. Weitere Informationen zum Optimieren der Funktionsausführung und -dienste finden Sie in der Cloud Functions und Cloud Run Dokumentation.

Eine Ausnahme bilden 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 vorhanden sind, stellt das CDN weiterhin alle im Cache gespeicherten 404-Antworten für maximal 10 Minuten bereit und stellt dann Inhalte von dieser URL normal bereit.

Wenn eine 404-Antwort bereits Caching-Header enthält, die von Ihrem Cloud Functions oder Cloud Run Dienst festgelegt wurden, werden die Standardeinstellung von 10 Minuten überschrieben und das Caching-Verhalten des CDN vollständig bestimmt.

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

Cache-Control festlegen

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

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

In diesem Beispielheader bewirken die Anweisungen Folgendes:

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

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

  • s-maxage : Überschreibt die max-age-Anweisung 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 Zwischen-Caches jedoch 10 Minuten lang.

Legen Sie für max-age und s-maxage die längste Zeit fest, in der Nutzer veraltete Inhalte erhalten dürfen. 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 headers Einstellung 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:

  • Dem Hostnamen
  • Dem Pfad
  • Dem Abfragestring
  • Dem Inhalt der Anfrageheader, die im Vary Header angegeben sind

Vary-Header

Der Vary Header bestimmt, welche Anfrageheader verwendet werden sollen, um eine geeignete Antwort zu geben (ob die Inhalte im Cache gültig sind oder ob die Inhalte mit dem Ursprungsserver neu validiert werden sollen).

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 nicht um den Vary Header kümmern. In einigen erweiterten Anwendungsfällen haben Sie jedoch möglicherweise andere Header, die sich auf den Cache auswirken müssen. In diesem Fall können Sie den Vary-Header in Ihrer Antwort festlegen. Beispiel:

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

In diesem Fall ist der Wert des Vary-Headers:

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. Beachten Sie, dass Hosting standardmäßig Cookie und Authorization zum Vary-Header hinzufügt, wenn eine Anfrage für dynamische Inhalte gestellt wird. Dadurch wird sichergestellt, dass alle von Ihnen verwendeten Autorisierungsheader für Sitzungen oder Cookies Teil des Cacheschlüssels sind, wodurch versehentliche Datenlecks verhindert werden.

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. Denken Sie auch daran, dass Vary auf Anfrageheadern und nicht auf Antwortheadern basiert.

Cookies verwenden

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 Caching-Verhalten 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 Teil des Cacheschlüssels. So kann verhindert werden, dass zwei Nutzer mit unterschiedlichen Cookies die im Cache gespeicherte Antwort des anderen erhalten. Verwenden Sie das __session-Cookie nur, wenn Ihre App je nach Nutzerautorisierung unterschiedliche Inhalte bereitstellt.