Hosting Firebase korzysta z potężnej globalnej sieci CDN, aby Twoja witryna była jak najszybsza.
Żądana zawartość statyczna jest automatycznie buforowana w sieci CDN . Jeśli ponownie wdrożysz zawartość swojej witryny, Hosting Firebase automatycznie wyczyści całą zawartość statyczną z pamięci podręcznej w sieci CDN aż do następnego żądania.
Jednak ponieważ usługi Cloud Functions i Cloud Run generują zawartość dynamicznie, zawartość danego adresu URL może się różnić w zależności od danych wprowadzanych przez użytkownika lub tożsamości użytkownika. Aby to uwzględnić, żądania obsługiwane przez kod zaplecza nie są domyślnie buforowane w sieci CDN.
Możesz jednak skonfigurować buforowanie zawartości dynamicznej . Na przykład, jeśli funkcja generuje nową zawartość tylko okresowo, możesz przyspieszyć działanie aplikacji, buforując wygenerowaną zawartość przez co najmniej krótki okres czasu.
Możesz również potencjalnie zmniejszyć koszty wykonania funkcji, ponieważ zawartość jest obsługiwana z sieci CDN, a nie za pośrednictwem wyzwalanej funkcji. Przeczytaj więcej o optymalizacji wykonywania funkcji i usług w dokumentacji Cloud Functions i Cloud Run .
Dowiedz się więcej o zachowaniu w pamięci podręcznej 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ą zawartości dynamicznej jest nagłówek Cache-Control . Konfigurując ten nagłówek, możesz komunikować przeglądarce i sieci CDN, jak długo zawartość może być buforowana. W swojej funkcji ustawiasz Cache-Control 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, przez ile sekund mogą buforować zawartość. Po upływie ustawionego czasu przeglądarka i sieć CDN muszą ponownie zweryfikować zawartość na serwerze pochodzenia. W przykładowym nagłówku zezwalamy przeglądarce i sieci CDN na buforowanie zawartości przez pięć minut (zobaczs-maxageponiżej, aby uzyskać szczegółowe informacje na temat 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 zweryfikować 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 wartości max-age i s-maxage ustaw ich wartości na najdłuższy czas, przez jaki użytkownicy mogą otrzymywać nieaktualną zawartość. Jeśli strona zmienia się co kilka sekund, użyj małej wartości czasu. Jednak inne rodzaje treści można bezpiecznie buforować przez godziny, dni, a nawet miesiące.
Więcej informacji o nagłówku Cache-Control można znaleźć w sieci Mozilla Developer Network oraz w dokumentacji Google dla programistów internetowych .
Kiedy jest serwowana zawartość z pamięci podręcznej?
Przeglądarka i CDN buforują zawartość na podstawie:
- Nazwa hosta
- Ścieżka
- Ciąg zapytania
- Zawartość nagłówków żądań określonych w nagłówku
Vary
Różne nagłówki
Nagłówek Vary określa, które nagłówki żądań powinny być używane do zapewnienia odpowiedniej odpowiedzi (czy zawartość pamięci podręcznej jest prawidłowa, czy zawartość powinna zostać ponownie zweryfikowana z serwerem pochodzenia).
Hosting Firebase automatycznie ustawia w odpowiedzi odpowiedni nagłówek Vary w typowych sytuacjach. W większości przypadków nie musisz się martwić o nagłówek Vary . Jednak w niektórych zaawansowanych przypadkach użycia możesz mieć inne nagłówki, które muszą mieć wpływ 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 to:
vary: X-My-Custom-Header, x-fh-requested-host, accept-encoding, cookie, authorization
Przy tych ustawieniach dwa identyczne żądania z różnymi X-My-Custom-Header są buforowane oddzielnie. Pamiętaj, że Hosting domyślnie dodaje plik Cookie i Authorization do nagłówka Vary , gdy wysyłane jest żądanie dotyczące zawartości dynamicznej. Gwarantuje to, że każdy używany nagłówek autoryzacji sesji lub pliku cookie jest częścią klucza pamięci podręcznej, co zapobiega przypadkowym wyciekom treści.
Uwaga również:
Buforować można 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 prawdopodobieństwo, że sieć CDN może obsługiwać zawartość z pamięci podręcznej. Pamiętaj też, żeVaryopiera się na nagłówkach żądań , a nie nagłówków 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 zachowanie pamięci podręcznej CDN. Tylko specjalnie nazwany plik cookie __session może przejść do wykonania Twojej aplikacji.
Gdy jest obecny, plik cookie __session jest automatycznie częścią klucza pamięci podręcznej, co oznacza, że dwóch użytkowników z różnymi plikami cookie nie może otrzymać odpowiedzi w pamięci podręcznej. Używaj pliku cookie __session tylko wtedy, gdy Twoja aplikacja udostępnia różne treści w zależności od autoryzacji użytkownika.