Zarządzanie zachowaniem pamięci podręcznej

Firebase Hosting korzysta z wydajnej globalnej sieci CDN, aby Twoja witryna działała jak najszybciej.

Wszystkie żądane treści statyczne są automatycznie zapisywane w pamięci podręcznej sieci CDN. Jeśli ponownie wdrożysz treści witryny, Firebase Hosting automatycznie wyczyści całą zawartość pamięci podręcznej w sieci CDN aż do następnego żądania.

Jednak ze względu na to, że usługi Cloud Functions i Cloud Run generują treści dynamicznie, zawartość danego adresu URL może się różnić w zależności od takich czynników jak dane wejściowe użytkownika czy jego tożsamość. Z tego powodu żądania obsługiwane przez kod backendu nie są domyślnie zapisywane w pamięci podręcznej sieci CDN.

Możesz jednak skonfigurować sposób działania pamięci podręcznej w przypadku treści dynamicznych. Jeśli na przykład funkcja generuje nowe treści tylko okresowo, możesz przyspieszyć działanie aplikacji, zapisując wygenerowane treści w pamięci podręcznej przez co najmniej krótki czas.

Podobnie możesz skonfigurować sposób działania pamięci podręcznej, aby potencjalnie obniżyć koszty wykonywania funkcji, ponieważ treści są wyświetlane z sieci CDN, a nie z wywołanej funkcji. Więcej informacji o optymalizacji wykonywania funkcji i usług znajdziesz w dokumentacji Cloud Functions i Cloud Run.

Wyjątkiem są żądania, które zwracają błędy 404. Sieć CDN zapisuje w pamięci podręcznej odpowiedź 404 usługi na nieistniejący adres URL przez 10 minut, dzięki czemu kolejne żądania tego adresu URL są obsługiwane przez sieć CDN. Jeśli zmienisz usługę tak, aby treści były teraz dostępne pod tym adresem URL, sieć CDN będzie nadal wyświetlać wszystkie zapisane w pamięci podręcznej odpowiedzi 404 przez maksymalnie 10 minut, a następnie będzie normalnie wyświetlać treści z tego adresu URL.

Jeśli odpowiedź 404 zawiera już nagłówki pamięci podręcznej ustawione przez usługę Cloud Functions lub Cloud Run, zastępują one domyślny czas 10 minut i w pełni określają sposób działania pamięci podręcznej sieci CDN.

Więcej informacji o sposobie działania pamięci podręcznej znajdziesz w dokumentacji dla programistów stron internetowych Google's .

Ustawianie nagłówka Cache-Control

Głównym narzędziem do zarządzania pamięcią podręczną treści dynamicznych jest nagłówek Cache-Control. Konfigurując ten nagłówek, możesz poinformować zarówno przeglądarkę, jak i sieć CDN, jak długo treści mogą być przechowywane w pamięci podręcznej. W funkcji ustawiasz Cache-Control w ten sposób:

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

W tym przykładzie nagłówka dyrektywy wykonują 3 czynności:

  • public – oznacza odpowiedź jako public. Oznacza to, że zarówno przeglądarka jak i pośrednie pamięci podręczne (w tym sieć CDN dla Firebase Hosting) mogą zapisywać treści w pamięci podręcznej.

  • max-age – określa, ile sekund może upłynąć od momentu utworzenia odpowiedzi, zanim zostanie ona ponownie zweryfikowana na serwerze źródłowym. Dotyczy to przeglądarek. Jeśli nie ma nagłówka s-maxage, dotyczy to też wszystkich innych pamięci podręcznych (w tym sieci CDN).

  • s-maxage – zastępuje dyrektywę max-age w przypadku współdzielonych pamięci podręcznych (takich jak sieć CDN). Gdy sieć CDN znajdzie odpowiedź starszą niż s-maxage sekund, ponownie zweryfikuje ją na serwerze źródłowym. W przykładowym nagłówku przeglądarki mogą zapisywać odpowiedź w pamięci podręcznej przez 5 minut, ale sieć CDN i inne pośrednie pamięci podręczne mogą ją zapisywać przez 10 minut.

W przypadku max-age i s-maxage ustaw wartości na najdłuższy czas, w którym użytkownicy mogą otrzymywać nieaktualne treści. Jeśli strona zmienia się co kilka sekund, użyj małej wartości czasu. Inne typy treści można jednak bezpiecznie zapisywać w pamięci podręcznej przez godziny, dni, a nawet miesiące.

Jeśli chcesz całkowicie uniemożliwić zapisywanie w pamięci podręcznej (np. aby zawsze wyświetlać najnowszą wersję treści statycznych), możesz skonfigurować to w firebase.json za pomocą ustawienia headers:

"hosting": {
  // ...

  // Disables caching for the /posts route
  "headers": [ {
    // Change source to match your dynamically-rendered routes
    "source": "/posts/**",
    "headers": [ {
      "key": "Cache-Control",
      "value": "no-cache, no-store"
    } ]
  } ]
}

Więcej informacji o nagłówku Cache-Control znajdziesz w Mozilla Developer Network i w dokumentacji dla programistów stron internetowych Google.

Kiedy wyświetlane są treści z pamięci podręcznej?

Przeglądarka i sieć CDN zapisują treści w pamięci podręcznej na podstawie tych informacji:

  • nazwa hosta,
  • ścieżka,
  • ciąg zapytania,
  • zawartość nagłówków żądania określonych w nagłówku Vary

Nagłówki Vary

Nagłówek Vary określa, które nagłówki żądania powinny być używane do podania odpowiedniej odpowiedzi (czy treści z pamięci podręcznej są prawidłowe, czy też należy je ponownie zweryfikować na serwerze źródłowym).

Firebase Hosting automatycznie ustawia odpowiedni nagłówek Vary w odpowiedzi w typowych sytuacjach. W większości przypadków nie musisz się martwić o nagłówek Vary header. W niektórych zaawansowanych przypadkach użycia możesz jednak mieć inne nagłówki, które muszą wpływać na pamięć podręczną. W takim przypadku możesz ustawić nagłówek Vary w odpowiedzi. Przykład:

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

W tym przypadku wartość nagłówka Vary to:

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

Przy tych ustawieniach 2 identyczne żądania z różnymi nagłówkami X-My-Custom-Header są zapisywane w pamięci podręcznej oddzielnie. Pamiętaj, że Hosting domyślnie dodaje Cookie i Authorization do nagłówka Vary gdy wysyłane jest żądanie treści dynamicznych. Dzięki temu każdy nagłówek autoryzacji sesji lub pliku cookie, którego używasz, jest częścią klucza pamięci podręcznej, co zapobiega przypadkowemu wyciekowi treści.

Pamiętaj też:

  • W pamięci podręcznej można zapisywać tylko żądania GET i HEAD. Żądania HTTPS korzystające z innych metod nigdy nie są zapisywane w pamięci podręcznej.

  • Zachowaj ostrożność podczas dodawania ustawień do nagłówka Vary. Im więcej ustawień dodasz, tym mniejsze prawdopodobieństwo, że sieć CDN będzie mogła wyświetlać treści z pamięci podręcznej. Pamiętaj też, że Vary jest oparty na nagłówkach żądania , a nie na nagłówkach odpowiedzi.

Używanie plików cookie

Gdy używasz Firebase Hosting razem z Cloud Functions lub Cloud Run, pliki cookie są zwykle usuwane z przychodzących żądań. Jest to konieczne, aby umożliwić efektywne działanie pamięci podręcznej sieci CDN cache behavior. Tylko plik cookie o specjalnej nazwie __session może zostać przekazany do wykonania aplikacji.

Gdy plik cookie __session jest obecny, automatycznie staje się częścią klucza pamięci podręcznej, co oznacza, że 2 użytkowników z różnymi plikami cookie nie mogą otrzymać odpowiedzi z pamięci podręcznej drugiego użytkownika. Używaj pliku cookie __session tylko wtedy, gdy aplikacja wyświetla różne treści w zależności od autoryzacji użytkownika.