Zarządzaj zachowaniem pamięci podręcznej

Hosting Firebase korzysta z potężnej globalnej sieci CDN, aby Twoja witryna była jak najszybsza.

Wszelkie żądana zawartość statyczna jest automatycznie buforowane na CDN. Jeśli ponownie wdrożysz zawartość swojej witryny, Hosting Firebase automatycznie wyczyści całą zawartość statyczną z pamięci podręcznej w sieci CDN aż do następnego żądania.

Ponieważ jednak usługi Cloud Functions i Cloud Run generują zawartość dynamicznie, zawartość danego adresu URL może się różnić w zależności od danych wprowadzanych przez użytkownika lub tożsamości użytkownika. W celu uwzględnienia tego żądania, które są obsługiwane przez kod backend nie buforować na CDN domyślnie.

Można jednak configure zachowanie buforowania dla dynamicznej zawartości. Na przykład, jeśli funkcja generuje nową zawartość tylko okresowo, możesz przyspieszyć działanie aplikacji, buforując wygenerowaną zawartość przez co najmniej krótki okres czasu.

Możesz również potencjalnie zmniejszyć koszty wykonania funkcji, ponieważ zawartość jest obsługiwana z sieci CDN, a nie za pośrednictwem wyzwalanej funkcji. Czytaj więcej o optymalizacji realizacji funkcji i usług w funkcji chmurze i Chmura Run dokumentacji.

Dowiedz się więcej o zachowanie w pamięci podręcznej Google dokumentacji web developer .

Ustaw kontrolę pamięci podręcznej

Głównym narzędziem służącym do zarządzania cache dla zawartości dynamicznej jest Cache-Control nagłówka. Konfigurując ten nagłówek, możesz komunikować przeglądarce i sieci CDN, jak długo zawartość może być buforowana. W funkcji można ustawić Cache-Control tak:

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

W tym przykładowym nagłówku dyrektywy robią trzy rzeczy:

• public - Znaki cache jako public . Oznacza to, że zarówno przeglądarki i serwery pośrednie (czyli CDN dla Firebase Hosting) może buforować zawartość.

• max-age - informuje przeglądarkę, a CDN ile sekund, które mogą buforować treści. Po upływie ustawionego czasu przeglądarka i sieć CDN muszą ponownie zweryfikować zawartość na serwerze pochodzenia. W przykładowym nagłówku, jesteśmy pozwalając przeglądarkę a CDN buforowania zawartości przez pięć minut (patrz s-maxage poniżej dla poszczególnych sterowników do buforowania CDN).

• s-maxage - Przesłania max-age dyrektywa dla CDN-buforowanie tylko; informuje CDN, przez ile sekund może buforować zawartość. Po upływie ustawionego czasu sieć CDN musi ponownie zweryfikować zawartość na serwerze pochodzenia. W przykładowym nagłówku, jesteśmy nadrzędne ustawienie max-age za jedyne CDN CDN i pozwalając, aby buforować zawartość przez dziesięć minut.

Dla max-age i s-maxage ustawić ich wartości do najdłuższego czasu, że czujesz się komfortowo z użytkownikami otrzymujących nieświeży treści. Jeśli strona zmienia się co kilka sekund, użyj małej wartości czasu. Jednak inne rodzaje treści można bezpiecznie buforować przez godziny, dni, a nawet miesiące.

Możesz dowiedzieć się więcej o Cache-Control nagłówka na Mozilla Developer Network i Google w dokumentacji web developer .

Kiedy jest serwowana zawartość z pamięci podręcznej?

Przeglądarka i CDN buforują zawartość na podstawie:

• Nazwa hosta
• Ścieżka
• Ciąg zapytania
• Zawartość nagłówków żądań określonych w Vary nagłówek

Różne nagłówki

Vary nagłówka Określa, które występują o nagłówki powinny być wykorzystywane w celu zapewnienia odpowiedniej reakcji (czy zawartość pamięci podręcznej jest nieprawidłowy lub jeśli zawartość powinna być odnawiane z serwera pochodzenia).

Firebase Hosting automatycznie ustawia odpowiednią Vary nagłówek na swojej odpowiedzi dla typowych sytuacji. Większość czasu, nie trzeba się martwić o Vary nagłówek. Jednak w niektórych zaawansowanych przypadkach użycia możesz mieć inne nagłówki, które muszą mieć wpływ na pamięć podręczną. Kiedy to przypadek, można ustawić Vary nagłówek na odpowiedź. Na przykład:

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

W tym przypadku, wartość materiałów Vary nagłówek jest:

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

Z tych ustawień, w przeciwnym razie dwa identyczne wnioski z różnymi X-My-Custom-Header nagłówków są buforowane oddzielnie. Należy pamiętać, że hosting dodaje Cookie i Authorization do Vary nagłówek domyślnie, gdy został złożony wniosek o dynamicznej zawartości. Gwarantuje to, że każdy używany nagłówek sesji lub autoryzacji pliku cookie jest częścią klucza pamięci podręcznej, co zapobiega przypadkowym wyciekom treści.

Uwaga również:

• Tylko GET i HEAD wnioski mogą być buforowane. Żądania HTTPS korzystające z innych metod nigdy nie są buforowane.

• Bądź ostrożny przy dodawaniu ustawień do Vary nagłówek. Im więcej ustawień dodasz, tym mniejsze prawdopodobieństwo, że sieć CDN może obsługiwać zawartość z pamięci podręcznej. Należy również pamiętać, że Vary oparty jest na życzenie, a nie nagłówki nagłówki odpowiedzi.

Korzystanie z plików cookie

Gdy używasz Hostingu Firebase razem z Cloud Functions lub Cloud Run, pliki cookie są zazwyczaj usuwane z przychodzących żądań. Jest to konieczne, aby umożliwić wydajne CDN zachowanie pamięci podręcznej . Tylko specjalnie nazwany __session cookies wolno przechodzi do wykonywania aplikacji.

Kiedy obecny, __session cookie jest automatycznie wykonana część klucza pamięci podręcznej, co oznacza, że jest to niemożliwe dla dwóch użytkowników z różnych ciasteczek, aby otrzymać inne pamięci podręcznej odpowiedzi. Używać tylko __session ciasteczko jeśli aplikacja służy inną treść w zależności od autoryzacji użytkownika.