If you are building server-rendered Angular or Next.js apps, check out next-generation Firebase App Hosting, a full-stack solution for modern web frameworks.

Diese Seite wurde von der Cloud Translation API übersetzt.

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 neu bereitstellen, werden alle im CDN zwischengespeicherten Inhalte bis zur nächsten Anfrage automatisch von Firebase Hosting gelöscht.

Da Cloud Functions- und Cloud Run-Dienste Inhalte jedoch dynamisch generieren, können die Inhalte für eine bestimmte URL je nach Nutzereingaben oder Identität des Nutzers variieren. Aus diesem Grund werden Anfragen, die vom Backend-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 gelegentlich neue Inhalte generiert, können Sie Ihre App beschleunigen, indem Sie die generierten Inhalte für mindestens einen kurzen Zeitraum im Cache speichern.

Sie können das Caching-Verhalten ebenfalls so konfigurieren, dass die Kosten für die Funktionsausführung möglicherweise gesenkt werden, da die Inhalte nicht über eine ausgelöste Funktion, sondern über das CDN bereitgestellt werden. Weitere Informationen zur Optimierung der Funktionsausführung und Dienste finden Sie in der Dokumentation zu Cloud Functions und Cloud Run.

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 über das CDN ausgeliefert 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 Cache-Header enthält, die von Ihrem Cloud Functions- oder Cloud Run-Dienst festgelegt wurden, wird die Standardeinstellung von 10 Minuten überschrieben und das Cache-Verhalten des CDN wird vollständig bestimmt.

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

Cache-Control festlegen

Das Haupttool zum Verwalten des Caches für dynamische Inhalte ist der 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 Beispielheader haben die Anweisungen drei Aufgaben:

public: Der Cache wird als public markiert. 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.

Hinweis: Standardmäßig ist Cache-Control auf private festgelegt. Wenn Sie Cache-Control also nicht explizit auf public festlegen, darf nur der Browser des anfragenden Nutzers die Inhalte im Cache speichern.
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 die Inhalte noch einmal mit dem Ursprungsserver validieren. Im Beispielheader erlauben wir dem Browser und dem CDN, die Inhalte fünf Minuten lang im Cache zu speichern. Unter s-maxage finden Sie weitere Steuerelemente für das CDN-Caching.
s-maxage: Überschreibt die max-age-Anweisung nur für das CDN-Caching. Gibt dem CDN an, wie viele Sekunden die Inhalte im Cache gespeichert werden können. Nach Ablauf der festgelegten Zeit muss das CDN die Inhalte noch einmal mit dem Ursprungsserver validieren. In der Beispiel-Header-Datei überschreiben wir die Einstellung für max-age nur für das CDN und erlauben dem CDN, den Inhalt zehn Minuten lang im Cache zu speichern.

Legen Sie für max-age und s-maxage die längste Zeitspanne fest, in der Nutzer veraltete Inhalte erhalten sollen. Wenn sich eine Seite alle paar Sekunden ändert, verwenden Sie einen kurzen Zeitwert. Andere Arten von Inhalten können jedoch für Stunden, Tage oder sogar Monate sicher im Cache gespeichert werden.

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

Wann werden im Cache gespeicherte Inhalte ausgeliefert?

Der Browser und das CDN speichern Ihre Inhalte basierend auf:

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

Vary-Header

Der Vary-Header gibt an, welche Anfrageheader für die Bereitstellung einer geeigneten Antwort verwendet werden sollten (d. h., ob die im Cache gespeicherten Inhalte gültig sind oder ob sie noch einmal vom Ursprungsserver bestätigt werden müssen).

Firebase Hosting setzt in häufigen Situationen automatisch einen geeigneten Vary-Header in Ihrer Antwort. In den meisten Fällen müssen Sie sich keine Gedanken über den Vary-Header machen. Bei einigen erweiterten Anwendungsfällen benötigen Sie jedoch möglicherweise andere Header, um den Cache zu beeinflussen. 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 lautet der Wert des Vary-Headers:

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

Bei diesen Einstellungen werden zwei ansonsten identische Anfragen mit unterschiedlichen X-My-Custom-Header-Headern getrennt im Cache gespeichert. Hinweis: Wenn eine Anfrage für dynamische Inhalte gestellt wird, fügt Hosting standardmäßig Cookie und Authorization zum Vary-Header hinzu. 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 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 gecachte Inhalte bereitstellen kann. Denken Sie auch daran, dass Vary auf Anfrage-Headern und nicht auf Antwort-Headern 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 für ein effizientes CDN-Cache-Verhalten erforderlich. Nur das Cookie mit dem speziellen Namen __session darf an die Ausführung Ihrer App übergeben werden.

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