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 momentu 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. Aby to uwzględnić, żądania obsługiwane przez kod backendu domyślnie nie zapisują się w pamięci podręcznej w sieci CDN.

Możesz jednak skonfigurować buforowanie w przypadku 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 buforowania ustawione przez usługę Cloud Functions lub Cloud Run, zastępują one wartość domyślną wynoszącą 10 minut i w pełni określają działanie buforowania w sieci CDN.

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

Ustaw kontrolę pamięci podręcznej

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 przekazać przeglądarce i sieci 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 spełniają 3 funkcje:

• 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 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, ż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 można jednak bezpiecznie przechowywać w pamięci podręcznej przez wiele 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órych nagłówków żądania należy użyć, aby dostarczyć odpowiednią odpowiedź (czy treść w pamięci podręcznej jest prawidłowa czy też powinna zostać ponownie zweryfikowana na serwerze pierwotnym).

Firebase Hosting automatycznie ustawia w odpowiedzi odpowiedni nagłówek Vary w typowych sytuacjach. 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 oddzielnie. 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:

• W pamięci podręcznej można przechowywać 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 mniejsze prawdopodobieństwo, że sieć CDN będzie wyświetlać treści z pamięci podręcznej. Pamiętaj też, że zmienna Vary jest określana na podstawie nagłówków żądania, a nie nagłówków 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ć efektywne działanie pamięci podręcznej CDN. Do uruchomienia aplikacji może zostać przesłany tylko plik cookie __session o specjalnej nazwie.

Gdy ten plik jest używany, __session automatycznie staje się częścią klucza pamięci podręcznej, co oznacza, że dwóch użytkowników mających różne pliki cookie nie może 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.