Cache-Verhalten verwalten

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

Alle angeforderten statischen Inhalte werden automatisch im CDN im Cache gespeichert. Wenn Sie Websiteinhalte noch einmal bereitstellen, löscht Firebase Hosting automatisch alle Content im CDN bis zur nächsten Anfrage gespeichert.

Da die Dienste Cloud Functions und Cloud Run jedoch dynamisch geändert werden, kann der Inhalt für eine bestimmte URL je nach als Eingabe oder als Identität des Nutzers. Daher werden Anfragen, die die vom Back-End-Code verarbeitet werden, speichern standardmäßig nicht im CDN.

Sie können jedoch das Caching-Verhalten für dynamische Inhalte konfigurieren. Für Generiert eine Funktion beispielsweise nur regelmäßig neue Inhalte, können Sie den Vorgang beschleunigen. die generierten Inhalte für mindestens kurze Zeit im Cache zu speichern.

Auf ähnliche Weise können Sie das Caching-Verhalten konfigurieren, um die Funktion da der Content über das CDN und nicht über ein ausgelöste Funktion. Weitere Informationen zum Optimieren der Funktionsausführung und der Dienste in Cloud Functions und Cloud Run Dokumentation.

Die Ausnahme sind Anfragen, die 404-Fehler zurückgeben. Das CDN speichert Ihre 404-Fehler des Dienstes auf eine nicht vorhandene URL für 10 Minuten, sodass nachfolgende Anfragen für diese URL aus dem CDN bereitgestellt werden. Wenn Sie Ihren Dienst so ändern, dass jetzt Inhalte unter dieser URL vorhanden sind, liefert das CDN alle im Cache gespeicherten 404-Antworten noch maximal 10 Minuten lang aus und stellt dann die Inhalte von dieser URL normal bereit.

Wenn eine 404-Antwort bereits Caching-Header enthält, die von deinem Cloud Functions oder Cloud Run überschreiben, überschreiben sie 10 Minuten eingestellt und das Caching-Verhalten das CDN.

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

Cache-Steuerung festlegen

Das wichtigste Tool, das Sie zur Verwaltung des Cache für dynamische Inhalte verwenden, ist das Cache-Control-Header. Wenn Sie diesen Header konfigurieren, 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 Beispiel-Header bewirken die Anweisungen drei Dinge:

  • public: Markiert den Cache als public. Das bedeutet, dass sowohl der Browser als auch die Zwischenserver (d. h. das CDN für Firebase Hosting) die Inhalte im Cache speichern können.

  • max-age: Gibt dem Browser und dem CDN an, wie viele Sekunden die Inhalte im Cache gespeichert werden können. Nach Ablauf der festgelegten Zeit müssen der Browser und das CDN den Inhalt mit dem Ursprungsserver neu validieren. In der Beispielüberschrift sodass der Browser und das CDN den Inhalt fünf Minuten lang im Cache speichern können (siehe s-maxage unten für spezielle Steuerelemente für das CDN-Caching.

  • s-maxage: überschreibt die Anweisung max-age nur für das CDN-Caching. erzählt wie viele Sekunden der Content im Cache gespeichert werden kann. Wenn zum festgelegten Zeitpunkt abläuft, muss das CDN den Inhalt mit dem Ursprungsserver neu validieren. Im Beispielheader wird die Einstellung für max-age nur für das CDN überschrieben. und dem CDN erlauben, den Inhalt zehn Minuten lang im Cache zu speichern.

Legen Sie für max-age und s-maxage die Werte auf die längste Zeit fest. dass Nutzer veraltete Inhalte erhalten. Wenn sich eine Seite ändert verwenden Sie einen kleinen Zeitwert. Andere Arten von Inhalten können jedoch für Stunden, Tage oder sogar Monate sicher im Cache gespeichert werden.

Weitere Informationen zur Kopfzeile Cache-Control finden Sie in der Mozilla Developer Network und in der Dokumentation für Webentwickler.

Wann werden im Cache gespeicherte Inhalte bereitgestellt?

Der Browser und das CDN speichern Ihre Inhalte basierend auf:

  • Der Hostname
  • Der Pfad
  • Abfragestring
  • Der Inhalt der Anfrageheader, die im Vary-Header angegeben sind

Vary-Header

Die Vary-Header bestimmt, welche Anfrageheader verwendet werden sollen, um eine geeignete Antwort (ob der im Cache gespeicherte Inhalt gültig ist oder mit dem Ursprungsserver neu validiert werden.

Firebase Hosting legt automatisch einen passenden Vary-Header auf Ihrer für häufige Situationen. Meistens müssen Sie sich zur Kopfzeile Vary. Bei einigen fortgeschrittenen Anwendungsfällen weitere Header, die Sie benötigen, um den Cache zu beeinflussen. In diesem Fall können Sie den Vary-Header für Ihre 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-Header werden separat im Cache gespeichert. Beachten Sie, dass Hosting Cookie und Authorization werden standardmäßig in den Vary-Header eingefügt, wenn eine Anfrage für dynamische Inhalte gemacht. So wird sichergestellt, dass alle von dir verwendeten Sitzungs- oder Cookie-Autorisierungsheader Teil des Cache-Schlüssels werden, was versehentliches Lecken von Inhalten verhindert.

Beachten Sie außerdem Folgendes:

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

  • Seien Sie vorsichtig, wenn Sie dem Vary-Header Einstellungen hinzufügen. Je mehr Einstellungen desto unwahrscheinlicher ist es, dass das CDN im Cache gespeicherte Inhalte bereitstellen kann. Denken Sie auch daran, dass Vary auf Anfrageheadern und nicht auf Antwort basiert. Header.

Cookies verwenden

Bei Verwendung von Firebase Hosting zusammen mit Cloud Functions oder Cloud Run, werden Cookies in der Regel aus eingehenden Anfragen entfernt. Dieses ist erforderlich, um ein effizientes CDN-Cache-Verhalten zu ermöglichen. Nur das speziell benannte __session-Cookie darf an den die Ausführung Ihrer App.

Wenn vorhanden, wird das Cookie __session automatisch Teil des Caches Das bedeutet, dass zwei Nutzer mit unterschiedlichen Cookies nicht die im Cache gespeicherte Antwort der anderen empfangen. Verwenden Sie das Cookie __session nur, wenn Ihre App stellt je nach Benutzerautorisierung unterschiedliche Inhalte bereit.