Zarządzanie zachowaniem pamięci podręcznej

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

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

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 w Cloud Functions oraz Cloud Run dokumentacji.

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 kontrolę pamięci podręcznej

Głównym narzędziem służącym do zarządzania pamięcią podręczną 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 Hostingu Firebase) 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 metod max-age i s-maxage ustaw ich wartości na najdłuższy okres że użytkownicy będą otrzymywać nieaktualne treści. Jeśli strona się zmieni 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 powinny być używane do uzyskania odpowiednich odpowiedź (czy treść z pamięci podręcznej jest prawidłowa czy powinna być została ponownie zweryfikowana na serwerze pierwotnym).

Hosting Firebase automatycznie ustawia odpowiedni nagłówek Vary w Twojej witrynie odpowiedzi na typowe sytuacje. W większości przypadków nie musisz się martwić o nagłówku Vary. Jednak w niektórych zaawansowanych przypadkach użycia możesz mieć inne nagłówki, które wymagają zmiany pamięci podręcznej. 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 są to dwa identyczne żądania o różnych Nagłówki X-My-Custom-Header są przechowywane w pamięci podręcznej oddzielnie. Pamiętaj, że Hosting zapewnia 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

Gdy korzystasz z Hostingu Firebase razem z Cloud Functions lub w 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.