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 zum Optimieren der Funktionsausführung und der 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 Inhalte jetzt unter dieser URL vorhanden sind, stellt das CDN höchstens 10 Minuten lang im Cache gespeicherte 404-Fehler bereit und stellt dann 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 Cache für dynamische Inhalte ist der Header Cache-Control. 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: 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.

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. s-maxageunten finden Sie spezielle 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. Im Beispielheader wird die Einstellung für max-age nur für das CDN überschrieben und das CDN kann den Inhalt zehn Minuten lang im Cache 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 bereitgestellt?

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. In einigen erweiterten Anwendungsfällen können jedoch auch andere Header vorhanden sein, die Auswirkungen auf den Cache haben 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 lautet der Wert des Headers Vary:

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. Hosting fügt dem Header Vary standardmäßig Cookie und Authorization hinzu, wenn eine Anfrage für dynamische Inhalte gestellt wird. 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 im Cache gespeicherte Inhalte bereitstellen kann. Denken Sie auch daran, dass Vary auf Anfrage-Headern basiert, nicht auf Antwort-Headern.

Verwendung von Cookies

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 speziell benannte __session-Cookie darf an die Ausführung Ihrer Anwendung weitergeleitet werden.

Wenn das __session-Cookie vorhanden ist, wird es automatisch Teil des Cacheschlü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.