Zarządzanie zachowaniem pamięci podręcznej

Firebase Hosting korzysta z zaawansowanej globalnej sieci CDN, dzięki czemu Twoja strona może działać tak szybko, jak jak to tylko możliwe.

Każde żądane treści statyczne jest automatycznie umieszczane w pamięci podręcznej CDN. Jeśli ponowne wdrożenie treści witryny, Firebase Hosting automatycznie usunie treści w pamięci podręcznej w całej sieci CDN, aż do następnego żądania.

Ponieważ jednak usługi Cloud Functions i Cloud Run generują jednak treści pod różnymi adresami URL, zawartość pod tym adresem URL może się zmieniać danych wejściowych użytkownika lub jego tożsamości. W związku z tym prośby, które są domyślnie obsługiwane przez kod backendu nie zapisują się w pamięci podręcznej w sieci CDN.

Możesz jednak skonfigurować buforowanie w przypadku treści dynamicznych. Dla: Jeśli np. funkcja generuje nowe treści tylko okresowo, można przyspieszyć do aplikacji przez przechowywanie wygenerowanych treści w pamięci podręcznej na co najmniej krótki czas.

W podobny sposób możesz skonfigurować działanie buforowania, aby potencjalnie ograniczyć funkcję koszty wykonania, ponieważ treść jest wyświetlana z sieci CDN, a nie wyzwoloną funkcję. 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. CDN zapisuje w pamięci podręcznej zwracanie błędu 404 na nieistniejący adres URL przez 10 minut, aby kolejne dla tego adresu URL są obsługiwane poza siecią CDN. Jeśli zmienisz usługę aby treść znajdowała się pod tym adresem URL, CDN nadal wyświetla wszystkie 404 przez 10 minut (maksymalnie), a potem normalnie będzie wyświetlać treści z tego adresu URL.

Jeśli odpowiedź 404 zawiera już nagłówki buforowania ustawione przez Cloud Functions lub Cloud Run, zastępują one jest ustawiona domyślnie na 10 minut i pozwala w pełni określić zachowanie pamięci podręcznej w sieci CDN.

Więcej informacji o buforowaniu w dokumentacji dla programistów stron internetowych.

Ustaw Cache-Control

Głównym narzędziem do zarządzania pamięcią podręczną dla treści dynamicznych jest nagłówek Cache-Control. Konfigurując ten nagłówek, możesz przekazywać oba adresy do jak długo Twoje treści mogą być przechowywane w pamięci podręcznej przeglądarki i sieci CDN. W swojej funkcji ustawiasz Cache-Control w ten sposób:

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

W tym przykładowym nagłówku dyrektywy pełnią 3 czynności:

  • public – oznacza pamięć podręczną jako public. Oznacza to, że zarówno przeglądarka jak i serwery pośrednie (czyli CDN dla Firebase Hosting) mogą buforować dane treści.

  • max-age – informuje przeglądarkę i sieć CDN, ile sekund mogą buforować dane. treści. Po upływie określonego czasu przeglądarka i sieć CDN muszą ponownie zweryfikować treści na serwerze pierwotnym. W przykładowym nagłówku co umożliwi przeglądarce i sieci CDN zapisanie treści w pamięci podręcznej przez pięć minut (zobacz s-maxage poniżej, aby dowiedzieć się więcej o ustawieniach buforowania CDN.

  • s-maxage – zastępuje dyrektywę max-age tylko w przypadku buforowania CDN. opowiada sieć CDN, o jaką może ona zapisywać treści w pamięci podręcznej. Po ustawieniu godziny wygasa, sieć CDN musi ponownie zweryfikować treść na serwerze pierwotnym. W przykładowy nagłówek, zastępujemy ustawienie max-age tylko w sieci CDN i pozwolić sieci CDN na 10 minut zapisanie treści w pamięci podręcznej.

W przypadku parametrów max-age i s-maxage ustaw ich wartości na najdłuższy czas, przez jaki akceptujesz, że użytkownicy będą otrzymywać nieaktualne treści. Jeśli strona zmienia się co kilka sekund, użyj małej wartości czasu. Inne typy treści mogą jednak i można je bezpiecznie przechowywać w pamięci podręcznej na wiele godzin, dni, a nawet miesięcy.

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

Kiedy jest wyświetlana zawartość pamięci podręcznej?

Przeglądarka i sieć CDN buforują treść na podstawie:

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

Zróżnicuj nagłówki

Nagłówek Vary określa, które nagłówki żądania należy użyć, aby uzyskać odpowiednią odpowiedź (czy zawartość w pamięci podręcznej jest prawidłowa, czy też należy ją ponownie zweryfikować na serwerze źródłowym).

Firebase Hosting automatycznie ustawia odpowiedni nagłówek Vary w odpowiedzi na typowe sytuacje. W większości przypadków nie musisz się martwić o nagłówku Vary. W niektórych zaawansowanych przypadkach możesz jednak mieć inne nagłówki, które mogą wpływać na pamięć podręczną. W takim przypadku możesz ustawić w odpowiedzi nagłówek Vary. 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 usługa Hosting dodaje Cookie i Authorization do nagłówka Vary, gdy żądanie jest stworzonych z myślą o treściach dynamicznych. Dzięki temu każda sesja lub autoryzacja plików cookie nagłówek jest częścią klucza pamięci podręcznej, co zapobiega przypadkowemu wyciekom treści.

Pamiętaj też:

  • W pamięci podręcznej można przechowywać tylko żądania GET i HEAD. Żądania HTTPS korzystające z innego źródła Metody nigdy nie są zapisywane w pamięci podręcznej.

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

Korzystanie z plików cookie

Jeśli używasz pola Firebase Hosting razem z atrybutem Cloud Functions lub Cloud Run, pliki cookie są zwykle usuwane z żądań przychodzących. Ten jest niezbędna do efektywnego działania pamięci podręcznej CDN. Do metody może trafiać tylko plik cookie __session o specjalnej nazwie uruchomienia aplikacji.

Jeśli plik cookie __session jest obecny, automatycznie staje się częścią pamięci podręcznej co oznacza, że dwóch użytkowników z różnymi plikami cookie odpowiedź z pamięci podręcznej drugiej strony. Pliku cookie __session używaj tylko wtedy, gdy może wyświetlać różne treści w zależności od autoryzacji użytkownika.