Zarządzanie zachowaniem pamięci podręcznej

Firebase Hosting korzysta z potężnej globalnej sieci CDN, aby Twoja witryna była tak szybka, jak to tylko możliwe.

Każde żądane treści statyczne jest automatycznie umieszczane w pamięci podręcznej CDN. Jeśli ponownie wdrożysz zawartość witryny, Firebase Hosting automatycznie usunie wszystkie z pamięci podręcznej w CDN do czasu następnego żądania.

Ponieważ jednak 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 danych wejściowych użytkownika lub jego tożsamości. Dlatego żądania obsługiwane przez kod backendu domyślnie nie są przechowywane w pamięci podręcznej CDN.

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

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

Wyjątkiem są żądania zwracające błędy 404. Sieć CDN przechowuje w pamięci podręcznej odpowiedź 404 Twojej 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 strony z błędem 404 przez 10 minut (maksymalnie), a następnie będzie wyświetlać treści z tego adresu URL w normalny sposób.

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

Więcej informacji o zachowaniu pamięci podręcznej znajdziesz w dokumentacji dla deweloperów.

Ustaw Cache-Control

Głównym narzędziem do zarządzania pamięcią podręczną dla treści dynamicznych jest nagłówek Cache-Control. Dzięki skonfigurowaniu tego nagłówka możesz przekazać przeglądarce i CDN, jak długo treści mogą być przechowywane w pamięci podręcznej. W swojej funkcji Cache-Control ustawiasz w ten sposób:

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

W tym przykładowym nagłówku dyrektywy wykonują 3 działania:

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

  • max-age – informuje przeglądarkę i sieć CDN, jak długo mogą przechowywać treści w pamięci podręcznej. Po upływie ustawionego czasu przeglądarka i sieć CDN muszą ponownie zweryfikować zawartość z serwerem źródłowym. W przykładowym nagłówku zezwalamy przeglądarce i sieci CDN na buforowanie treści przez 5 minut (szczegółowe ustawienia buforowania w sieci CDN znajdziesz poniżej, w sekcji s-maxage).

  • s-maxage – zastępuje dyrektywę max-age tylko w przypadku buforowania w sieci CDN; informuje sieć CDN, ile sekund może buforować treści. Po upływie ustawionego czasu sieć CDN musi ponownie zweryfikować zawartość na serwerze źródłowym. W nagłówku przykładowym zastępujemy ustawienie max-age tylko dla sieci CDN i zezwalamy sieci CDN na umieszczenie treści w pamięci podręcznej na 10 minut.

W przypadku parametrów max-age i s-maxage ustaw ich wartości na najdłuższy czas, przez jaki akceptujesz wyświetlanie użytkownikom nieaktualnych treści. Jeśli strona zmienia się co kilka sekund, użyj małej wartości czasu. Inne typy treści mogą jednak być bezpiecznie przechowywane w pamięci podręcznej przez kilka godzin, dni, a nawet miesięcy.

Więcej informacji o główce Cache-Control znajdziesz w sieci programistów Mozilla oraz w dokumentacji Google dla programistów stron internetowych.

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

Przeglądarka i CDN zapisują w pamięci podręcznej Twoje treści na podstawie:

  • 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 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 potrzeby typowych sytuacji. W większości przypadków nie musisz się martwić Vary nagłówkiem. 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:

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 osobno. Pamiętaj, że gdy Hosting otrzyma żądanie dotyczące treści dynamicznych, do nagłówka Vary doda domyślnie wartości Cookie i Authorization. Dzięki temu każdy nagłówek autoryzacji sesji lub plików cookie, którego używasz, staje się częścią klucza pamięci podręcznej, co zapobiega przypadkowemu wyciekowi treści.

Pamiętaj też o tym:

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

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

Korzystanie z 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ć wydajne zachowanie pamięci podręcznej w sieci CDN. Do wykonania aplikacji może przejść tylko plik cookie o specjalnej nazwie __session.

Jeśli jest obecny, plik cookie __session jest automatycznie dodawany do klucza pamięci podręcznej, co oznacza, że 2 użytkownicy z różnymi plikami cookie nie mogą otrzymać odpowiedzi z zapisaną w pamięci podręcznej drugiej osoby. Używaj pliku cookie __session tylko wtedy, gdy aplikacja wyświetla różne treści w zależności od autoryzacji użytkownika.