Hosting Firebase korzysta z potężnego globalnego CDN, aby Twoja witryna była tak szybka, jak to możliwe.
Wszelkie żądane treści statyczne są automatycznie buforowane w sieci CDN . Jeśli ponownie wdrożysz zawartość swojej witryny, Firebase Hosting automatycznie wyczyści całą zawartość pamięci podręcznej w sieci CDN do czasu następnego żądania.
Ponieważ jednak usługi Cloud Functions i Cloud Run generują treść dynamicznie, treść danego adresu URL może się różnić w zależności od danych wprowadzonych przez użytkownika lub jego tożsamości. Aby to uwzględnić, żądania obsługiwane przez kod zaplecza domyślnie nie są buforowane w sieci CDN.
Można jednak skonfigurować zachowanie buforowania dla zawartości dynamicznej . Na przykład, jeśli funkcja generuje nową treść tylko okresowo, możesz przyspieszyć działanie aplikacji, buforując wygenerowaną treść przez co najmniej krótki okres czasu.
W podobny sposób można skonfigurować zachowanie buforowania, aby potencjalnie zmniejszyć koszty wykonania funkcji, ponieważ zawartość jest udostępniana z sieci CDN, a nie z wyzwalanej funkcji. Więcej informacji na temat 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 buforuje odpowiedź 404 Twojej usługi na nieistniejący adres URL przez 10 minut, dzięki czemu kolejne żądania dotyczące tego adresu URL są obsługiwane poza siecią CDN. Jeśli zmienisz usługę tak, aby treść istniała teraz pod tym adresem URL, CDN będzie nadal obsługiwać wszystkie buforowane błędy 404 przez maksymalnie 10 minut, a następnie normalnie będzie udostępniać zawartość z tego adresu URL.
Jeśli odpowiedź 404 zawiera już nagłówki buforowania ustawione przez usługę Cloud Functions lub Cloud Run, zastępują one domyślne wartości 10 minut i w pełni określają zachowanie pamięci podręcznej sieci CDN.
Więcej informacji na temat buforowania znajdziesz w dokumentacji Google dla programistów internetowych .
Ustaw kontrolę pamięci podręcznej
Głównym narzędziem używanym do zarządzania pamięcią podręczną dla zawartości dynamicznej jest nagłówek Cache-Control . Konfigurując ten nagłówek, możesz poinformować przeglądarkę i sieć CDN, jak długo zawartość może być przechowywana w pamięci podręcznej. W swojej funkcji ustawiasz Cache-Control w następujący sposób:
res.set('Cache-Control', 'public, max-age=300, s-maxage=600');
W tym przykładowym nagłówku dyrektywy robią trzy rzeczy:
public— Oznacza pamięć podręczną jakopublic. Oznacza to, że zarówno przeglądarka , jak i serwery pośrednie (czyli CDN dla Firebase Hosting) mogą buforować zawartość.max-age— Informuje przeglądarkę i sieć CDN, ile sekund mogą przechowywać zawartość w pamięci podręcznej. Po upływie ustawionego czasu przeglądarka i CDN muszą ponownie sprawdzić zawartość na serwerze źródłowym. W przykładowym nagłówku pozwalamy przeglądarce i sieci CDN na buforowanie zawartości przez pięć minut (zobaczs-maxageponiżej, aby uzyskać szczegółowe informacje dotyczące buforowania CDN).s-maxage— Zastępuje dyrektywęmax-agetylko dla buforowania CDN; informuje CDN, przez ile sekund może buforować zawartość. Po upływie ustawionego czasu sieć CDN musi ponownie sprawdzić zawartość na serwerze pochodzenia. W przykładowym nagłówku zastępujemy ustawieniemax-agetylko dla sieci CDN i zezwalamy sieci CDN na buforowanie zawartości przez dziesięć minut.
W przypadku max-age i s-maxage ustaw ich wartości na najdłuższy czas, przez który użytkownicy będą otrzymywać nieaktualne treści. Jeśli strona zmienia się co kilka sekund, użyj małej wartości czasu. Jednak inne typy treści można bezpiecznie przechowywać w pamięci podręcznej przez wiele godzin, dni, a nawet miesięcy.
Więcej informacji na temat nagłówka Cache-Control można znaleźć w witrynie Mozilla Developer Network oraz w dokumentacji Google dla programistów internetowych .
Kiedy udostępniana jest zawartość z pamięci podręcznej?
Przeglądarka i CDN buforują zawartość w oparciu o:
- Nazwa hosta
- Ścieżka
- Ciąg zapytania
- Zawartość nagłówków żądań określona w nagłówku
Vary
Zmieniaj nagłówki
Nagłówek Vary określa, które nagłówki żądań powinny zostać użyte w celu zapewnienia odpowiedniej odpowiedzi (czy zawartość w pamięci podręcznej jest prawidłowa, czy też zawartość powinna zostać ponownie sprawdzona na serwerze pochodzenia).
Hosting Firebase automatycznie ustawia odpowiedni nagłówek Vary w odpowiedzi na typowe sytuacje. W większości przypadków nie musisz się martwić o nagłówek Vary . Jednak w niektórych zaawansowanych przypadkach użycia mogą istnieć inne nagłówki, które będą potrzebne do wpływu na pamięć podręczną. W takim przypadku możesz ustawić nagłówek Vary w swojej odpowiedzi. Na przykład:
res.set('Vary', 'Accept-Encoding, X-My-Custom-Header');
W tym przypadku wartość nagłówka Vary wynosi:
vary: X-My-Custom-Header, x-fh-requested-host, accept-encoding, cookie, authorization
Przy tych ustawieniach dwa skądinąd identyczne żądania z różnymi X-My-Custom-Header są buforowane osobno. Należy pamiętać, że Hosting domyślnie dodaje Cookie i Authorization do nagłówka Vary , gdy wysyłane jest żądanie dotyczące zawartości dynamicznej. Dzięki temu każdy używany nagłówek autoryzacji sesji lub pliku cookie stanie się częścią klucza pamięci podręcznej, co zapobiega przypadkowym wyciekom treści.
Uwaga:
Buforowane mogą być tylko żądania
GETiHEAD. Żą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 jest prawdopodobieństwo, że sieć CDN będzie mogła obsługiwać zawartość z pamięci podręcznej. Pamiętaj też, żeVaryopiera się na nagłówkach żądań , a nie nagłówkach odpowiedzi .
Korzystanie z plików cookie
Podczas korzystania z Hostingu Firebase razem z Cloud Functions lub Cloud Run pliki cookie są zazwyczaj usuwane z przychodzących żądań. Jest to konieczne, aby umożliwić wydajne działanie pamięci podręcznej CDN. Tylko specjalnie nazwany plik cookie __session może przejść do wykonania Twojej aplikacji.
Jeśli plik cookie __session jest obecny, automatycznie staje się częścią klucza pamięci podręcznej, co oznacza, że dwóch użytkowników korzystających z różnych plików cookie nie może otrzymać odpowiedzi z pamięci podręcznej drugiej strony. Używaj pliku cookie __session tylko wtedy, gdy Twoja aplikacja udostępnia inną treść w zależności od autoryzacji użytkownika.