Join us for Firebase Summit on November 10, 2021. Tune in to learn how Firebase can help you accelerate app development, release with confidence, and scale with ease. Register

Cache-Verhalten verwalten

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

Alle angeforderten statischen Inhalt wird automatisch auf dem CDN zwischengespeichert. Wenn Sie den Inhalt Ihrer Website erneut bereitstellen, löscht Firebase Hosting automatisch alle zwischengespeicherten statischen Inhalte im gesamten CDN bis zur nächsten Anfrage.

Da Cloud Functions- und Cloud Run-Dienste jedoch Inhalte dynamisch generieren, kann der Inhalt für eine bestimmte URL je nach Benutzereingabe oder der Identität des Benutzers variieren. Zur Berücksichtigung hierfür Anforderungen , die von Back - End - Code behandelt werden können cachen nicht auf dem CDN standardmäßig aktiviert .

Sie können, aber configure Caching - Verhalten für dynamische Inhalte. Wenn eine Funktion beispielsweise nur in regelmäßigen Abständen neue Inhalte generiert, können Sie Ihre App beschleunigen, indem Sie die generierten Inhalte zumindest für kurze Zeit zwischenspeichern.

Sie können auch potenziell die Kosten für die Funktionsausführung reduzieren, da der Inhalt vom CDN und nicht über eine ausgelöste Funktion bereitgestellt wird. Lesen Sie mehr über Funktionsausführung zu optimieren und Dienstleistungen in den Cloud - Funktionen und Cloud - Run - Dokumentation.

Erfahren Sie mehr über das Verhalten Cachen in Googles Web - Entwickler - Dokumentation .

Cache-Steuerung einstellen

Das wichtigste Werkzeug , dass Sie Cache für dynamische Inhalte verwalten verwenden ist der Cache-Control - Header. Durch die Konfiguration dieses Headers 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:

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

In diesem Beispielheader bewirken die Direktiven drei Dinge:

  • public - Markiert den Cache als public . Dies bedeutet , dass sowohl der Browser als auch die Zwischenserver (die CDN für Firebase Hosting bedeutet) können den Inhalt zwischenzuspeichern.

  • max-age - Weist den Browser und das CDN , wie viele Sekunden , dass sie den Inhalt zwischenspeichern können. Wenn die eingestellte Zeit abläuft, müssen der Browser und das CDN den Inhalt mit dem Ursprungsserver erneut validieren. Im Beispiel - Header, erlauben wir den Browser und die CDN den Inhalt für fünf Minuten in dem Cache (siehe s-maxage unten für spezifische Kontrollen für CDN - Caching).

  • s-maxage - Überschreibungen die max-age Richtlinie für die CDN-Caching von nur; teilt dem CDN mit, wie viele Sekunden es den Inhalt zwischenspeichern kann. Wenn die festgelegte Zeit abläuft, muss das CDN den Inhalt mit dem Ursprungsserver erneut validieren. Im Beispiel - Header sind zwingende wir die Einstellung für max-age für das CDN nur und ermöglicht das CDN den Inhalt für 10 Minuten zwischenzuspeichern.

Für max-age und s-maxage , setzen ihre Werte auf die längste Zeit , die Sie bequem mit den Nutzern veraltete Inhalte zu empfangen. 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.

Sie können mehr über das erfahren Cache-Control - Header auf dem Mozilla Developer Network und in Googles Web - Entwickler - Dokumentation .

Wann werden zwischengespeicherte Inhalte bereitgestellt?

Der Browser und das CDN cachen Ihre Inhalte basierend auf:

  • Der Hostname
  • Der Weg
  • Der Abfragestring
  • Der Inhalt der Request - Header in dem angegebenen Vary - Header

Kopfzeilen variieren

Die Vary - Header bestimmt , welche Request - Header verwendet werden sollen , eine angemessene Antwort zu geben (ob der zwischengespeicherten Inhalt gültig ist oder wenn der Inhalt sollte mit dem Ursprungsserver neu validiert werden).

Firebase Hosting stellt automatisch eine entsprechende Vary - Header für allgemeine Situationen auf Ihre Antwort. Die meiste Zeit, müssen Sie sich keine Sorgen machen brauchen , um über die Vary - Header. In einigen fortgeschrittenen Anwendungsfällen haben Sie jedoch möglicherweise andere Header, die Sie benötigen, um den Cache zu beeinflussen. Wenn das der Fall ist, können Sie die Set Vary - Header auf Ihre Antwort. Zum Beispiel:

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

In diesem Fall wird der Wert der Vary - Header ist:

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

Mit diesen Einstellungen zwei ansonsten identische Anforderungen mit verschiedenen X-My-Custom-Header - Header werden separat zwischengespeichert. Beachten Sie, dass Hosting fügt Cookie und Authorization an die Vary - Header standardmäßig , wenn eine Anforderung für dynamische Inhalte gemacht wird. Dadurch wird sichergestellt, dass jeder von Ihnen verwendete Sitzungs- oder Cookie-Autorisierungsheader Teil des Cache-Schlüssels wird, wodurch versehentliche Inhaltslecks verhindert werden.

Beachten Sie auch:

  • Nur GET und HEAD - Anfragen zwischengespeichert werden können. HTTPS-Anfragen, die andere Methoden verwenden, werden nie zwischengespeichert.

  • Seien Sie vorsichtig beim Hinzufügen von Einstellungen der Vary - Header. Je mehr Einstellungen Sie hinzufügen, desto unwahrscheinlicher ist es, dass das CDN zwischengespeicherte Inhalte bereitstellen kann. Denken Sie auch daran , dass Vary basiert auf Request - Header, nicht - Antwort - Header.

Verwendung von Cookies

Wenn Sie Firebase Hosting zusammen mit Cloud Functions oder Cloud Run verwenden, werden Cookies im Allgemeinen aus eingehenden Anfragen entfernt. Dies ist notwendig für eine effiziente CDN zu ermöglichen Cache - Verhalten . Nur die speziell genannten __session Cookie erlaubt die Ausführung Ihrer App durchlaufen.

Wenn vorhanden, die __session wird Cookie automatisch einen Teil des Cache - Schlüssel gemacht, was bedeutet , dass es für zwei Benutzer mit unterschiedlichen Cookies unmöglich ist , die anderen zwischengespeicherte Antwort zu erhalten. Verwenden Sie nur das __session Cookie wenn Ihre Anwendung auf Benutzerberechtigung je unterschiedliche Inhalte dient.