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 zwischengespeichert . Wenn Sie den Inhalt Ihrer Website erneut bereitstellen, löscht Firebase Hosting automatisch alle Ihre zwischengespeicherten statischen Inhalte über das CDN bis zur nächsten Anfrage.

Da Inhalte von Cloud Functions- und Cloud Run-Diensten jedoch dynamisch generiert werden, kann der Inhalt für eine bestimmte URL je nach Benutzereingabe oder Identität des Benutzers variieren. Aus diesem Grund werden Anforderungen, die vom Backend-Code verarbeitet werden, standardmäßig nicht im CDN zwischengespeichert, mit Ausnahme von Anforderungen, die 404-Fehler zurückgeben. Um zwischengespeicherte 404-Ergebnisse zu löschen, stellen Sie Firebase Hosting erneut bereit. Durch die erneute Bereitstellung von Cloud Functions und Cloud Run wird der Cache nicht automatisch ungültig.

Sie können jedoch das Caching-Verhalten für dynamische Inhalte konfigurieren . Wenn eine Funktion beispielsweise nur periodisch neue Inhalte generiert, können Sie Ihre App beschleunigen, indem Sie die generierten Inhalte für mindestens einen kurzen Zeitraum zwischenspeichern.

Sie können möglicherweise auch die Kosten für die Funktionsausführung reduzieren, da der Inhalt vom CDN statt über eine ausgelöste Funktion bereitgestellt wird. Weitere Informationen zum Optimieren der Funktionsausführung und von Diensten finden Sie in der Dokumentation zu Cloud Functions und Cloud Run .

Weitere Informationen zum Caching-Verhalten finden Sie in der Google- Dokumentation für Webentwickler .

Cache-Kontrolle einstellen

Das Haupttool, mit dem Sie den Cache für dynamische Inhalte verwalten, ist der Cache-Control Header. Indem Sie diesen Header konfigurieren, können Sie sowohl dem Browser als auch dem CDN mitteilen, wie lange Ihre Inhalte zwischengespeichert werden können. In Ihrer Funktion stellen Sie Cache-Control wie folgt ein:

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

In diesem Beispiel-Header machen die Direktiven drei Dinge:

• public — Markiert den Cache als public . Das bedeutet, dass sowohl der Browser als auch die Zwischenserver (also das CDN für Firebase Hosting) den Inhalt zwischenspeichern können.

• max-age — Teilt dem Browser und dem CDN mit, wie viele Sekunden sie den Inhalt zwischenspeichern können. Wenn die festgelegte Zeit abgelaufen ist, müssen der Browser und das CDN den Inhalt beim Ursprungsserver erneut validieren. Im Beispiel-Header erlauben wir dem Browser und dem CDN, den Inhalt fünf Minuten lang zwischenzuspeichern (siehe s-maxage unten für spezifische Steuerelemente für das CDN-Caching).

• s-maxage — Überschreibt die max-age Direktive nur für das CDN-Caching; teilt dem CDN mit, wie viele Sekunden es den Inhalt zwischenspeichern kann. Wenn die festgelegte Zeit abgelaufen ist, muss das CDN den Inhalt beim Ursprungsserver erneut validieren. Im Beispiel-Header überschreiben wir die Einstellung für max-age nur für das CDN und erlauben dem CDN, den Inhalt zehn Minuten lang zwischenzuspeichern.

Legen Sie für max-age und s-maxage ihre Werte auf den längsten Zeitraum fest, den Sie damit zulassen, dass Benutzer veraltete Inhalte erhalten. Wenn sich eine Seite alle paar Sekunden ändert, verwenden Sie einen kleinen Zeitwert. Andere Arten von Inhalten können jedoch stunden-, tage- oder sogar monatelang sicher zwischengespeichert werden.

Weitere Informationen zum Cache-Control Header finden Sie im Mozilla Developer Network und in der Dokumentation für Webentwickler von Google .

Wann werden zwischengespeicherte Inhalte bereitgestellt?

Der Browser und das CDN cachen Ihre Inhalte basierend auf:

• Der Hostname
• Der Weg
• Die Abfragezeichenfolge
• Der Inhalt der im Vary Header angegebenen Anforderungsheader

Überschriften variieren

Der Vary Header bestimmt, welche Anforderungsheader verwendet werden sollen, um eine angemessene Antwort bereitzustellen (ob der zwischengespeicherte Inhalt gültig ist oder ob der Inhalt mit dem Ursprungsserver erneut validiert werden sollte).

Firebase Hosting legt für häufige Situationen automatisch einen geeigneten Vary Header für Ihre Antwort fest. Meistens brauchen Sie sich um den Vary Header keine Gedanken zu machen. In einigen fortgeschrittenen Anwendungsfällen haben Sie jedoch möglicherweise andere Header, die Sie benötigen, um den Cache zu beeinflussen. Wenn dies der Fall ist, können Sie den Vary Header für Ihre Antwort festlegen. Zum Beispiel:

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

In diesem Fall lautet 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 zwischengespeichert. Beachten Sie, dass Hosting standardmäßig Cookie und Authorization zum Vary Header hinzufügt, wenn eine Anforderung für dynamischen Inhalt gestellt wird. Dadurch wird sichergestellt, dass jeder Sitzungs- oder Cookie-Autorisierungsheader, den Sie verwenden, Teil des Cache-Schlüssels wird, wodurch ein versehentliches Durchsickern von Inhalten verhindert wird.

Beachten Sie auch:

• Nur GET und HEAD Anforderungen können zwischengespeichert werden. HTTPS-Anforderungen mit anderen Methoden werden niemals zwischengespeichert.

• Seien Sie vorsichtig, wenn Sie Einstellungen zum Vary Header hinzufügen. Je mehr Einstellungen Sie hinzufügen, desto unwahrscheinlicher ist es, dass das CDN zwischengespeicherte Inhalte bereitstellen kann. Denken Sie auch daran, dass Vary auf Anforderungsheadern und nicht auf Antwortheadern basiert.

Verwendung von Cookies

Bei der Verwendung von Firebase Hosting zusammen mit Cloud Functions oder Cloud Run werden Cookies im Allgemeinen aus eingehenden Anfragen entfernt. Dies ist notwendig, um ein effizientes CDN- Cache-Verhalten zu ermöglichen. Nur das speziell benannte __session Cookie darf zur Ausführung Ihrer App durchgelassen werden.

Wenn vorhanden, wird das __session Cookie automatisch zu einem Teil des Cache-Schlüssels, was bedeutet, dass es für zwei Benutzer mit unterschiedlichen Cookies unmöglich ist, die zwischengespeicherte Antwort des anderen zu erhalten. Verwenden Sie das __session Cookie nur, wenn Ihre App je nach Benutzerautorisierung unterschiedliche Inhalte bereitstellt.