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-Cache gespeichert. Wenn Sie die Inhalte Ihrer Website neu bereitstellen, löscht Firebase Hosting automatisch alle Ihre im CDN zwischengespeicherten Inhalte bis zur nächsten Anfrage.

Da bei den Diensten Cloud Functions und Cloud Run Inhalte jedoch dynamisch generiert werden, können die Inhalte für eine bestimmte URL je nach Faktoren wie Nutzereingaben oder der Identität des Nutzers variieren. Aus diesem Grund werden Anfragen, die von Backend-Code verarbeitet werden, standardmäßig nicht im CDN-Cache gespeichert.

Sie können jedoch das Caching-Verhalten für dynamische Inhalte konfigurieren. Wenn eine Funktion beispielsweise nur in regelmäßigen Abständen neue Inhalte generiert, können Sie die Leistung Ihrer App verbessern, indem Sie die generierten Inhalte für mindestens kurze Zeit im Cache speichern.

Sie können das Caching-Verhalten auf ähnliche Weise konfigurieren, um die Kosten für die Funktionsausführung zu senken, da die Inhalte über das CDN und nicht über eine ausgelöste Funktion bereitgestellt werden. Weitere Informationen zur Optimierung der Funktionsausführung und der Dienste finden Sie in der Dokumentation zu Cloud Functions und Cloud Run.

Ausgenommen sind 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 aus dem CDN bereitgestellt werden. Wenn Sie Ihren Dienst so ändern, dass Inhalte jetzt unter dieser URL verfügbar sind, werden alle im Cache gespeicherten 404-Fehler vom CDN weiterhin für maximal 10 Minuten bereitgestellt. Danach werden Inhalte von dieser URL normal bereitgestellt.

Wenn eine 404-Antwort bereits Caching-Header enthält, die von Ihrem Cloud Functions- oder Cloud Run-Dienst festgelegt wurden, überschreiben sie den Standardwert von 10 Minuten und bestimmen das Caching-Verhalten des CDN vollständig.

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

Cachesteuerung festlegen

Das wichtigste Tool zum Verwalten des Caches für dynamische Inhalte ist der Header Cache-Control. Mit diesem Header können Sie sowohl dem Browser als auch dem CDN mitteilen, wie lange Ihre Inhalte im Cache gespeichert werden dürfen. In Ihrer Funktion legen Sie Cache-Control so fest:

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

In diesem Beispielheader werden durch die Direktiven drei Dinge erreicht:

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

• max-age: Gibt an, wie viele Sekunden der Browser und das CDN den Inhalt im Cache speichern können. Wenn die festgelegte Zeit abläuft, müssen der Browser und das CDN die Inhalte mit dem Ursprungsserver neu 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 spezifische Steuerelemente für das CDN-Caching.

• s-maxage: Überschreibt die max-age-Anweisung nur für das CDN-Caching. Gibt an, wie viele Sekunden das CDN den Inhalt im Cache speichern kann. Wenn die festgelegte Zeit abläuft, muss das CDN die Inhalte mit dem Ursprungsserver neu validieren. Im Beispielheader wird die Einstellung für max-age nur für das CDN überschrieben und das CDN darf den Inhalt zehn Minuten lang im Cache speichern.

Legen Sie für max-age und s-maxage die Werte auf die längste Zeitspanne fest, in der Nutzer Ihrer Meinung nach noch akzeptable Inhalte erhalten. Wenn sich eine Seite alle paar Sekunden ändert, verwenden Sie einen kleinen Zeitwert. Andere Arten von Inhalten können jedoch problemlos über Stunden, Tage oder sogar Monate hinweg im Cache gespeichert werden.

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

Wann werden Inhalte aus dem Cache bereitgestellt?

Der Browser und das CDN speichern Ihre Inhalte im Cache basierend auf:

• Der Hostname
• Der Pfad
• Der Abfragestring
• Der Inhalt der in Vary-Header angegebenen Anfrageheader

Vary-Header

Der Vary-Header bestimmt, welche Anfrageheader verwendet werden sollen, um eine geeignete Antwort zu liefern. Er gibt an, ob der Cache-Inhalt gültig ist oder ob der Inhalt mit dem Ursprungsserver neu validiert werden soll.

Firebase Hosting legt automatisch einen geeigneten Vary-Header in Ihrer Antwort für häufige Situationen fest. In den meisten Fällen müssen Sie sich keine Gedanken über den Vary-Header machen. In einigen erweiterten Anwendungsfällen sind jedoch möglicherweise andere Header erforderlich, um den Cache zu beeinflussen. In diesem Fall können Sie den Header Vary 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

Mit diesen Einstellungen werden zwei ansonsten identische Anfragen mit unterschiedlichen X-My-Custom-Header-Headern separat im Cache gespeichert. Hosting fügt dem Vary-Header standardmäßig Cookie und Authorization hinzu, wenn dynamische Inhalte angefordert werden. So wird sichergestellt, dass alle von Ihnen verwendeten Autorisierungsheader für Sitzungen oder Cookies Teil des Cache-Schlüssels sind. Dadurch wird verhindert, dass Inhalte versehentlich preisgegeben werden.

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 Inhalte aus dem Cache bereitstellen kann. Vary basiert auf Anfrage-Headern, 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 erforderlich, um ein effizientes CDN-Cacheverhalten zu ermöglichen. Nur das speziell benannte __session-Cookie darf an die Ausführung Ihrer App weitergeleitet werden.

Wenn das __session-Cookie vorhanden ist, wird es automatisch in den Cache-Schlüssel aufgenommen. Das bedeutet, dass zwei Nutzer mit unterschiedlichen Cookies nicht die zwischengespeicherte Antwort des jeweils anderen erhalten können. Verwenden Sie das __session-Cookie nur, wenn in Ihrer App je nach Nutzerautorisierung unterschiedliche Inhalte bereitgestellt werden.