Firebase Hosting korzysta z zaawansowanej globalnej sieci CDN, dzięki czemu Twoja strona może działać tak szybko, jak jak to tylko możliwe.
Każde żądane treści statyczne jest automatycznie umieszczane w pamięci podręcznej CDN. Jeśli ponowne wdrożenie treści witryny, Firebase Hosting automatycznie usunie treści w pamięci podręcznej w całej sieci CDN, aż do następnego żądania.
Ponieważ jednak 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 znajdziesz w dokumentacji Cloud Functions i Cloud Run.
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 Cache-Control
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 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ą jakopublic
. Oznacza to, że zarówno przeglądarka jak i serwery pośrednie (czyli CDN dla Firebase Hosting) 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 (zobaczs-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 ustawieniemax-age
tylko w sieci CDN i pozwolić sieci CDN na 10 minut zapisanie treści w pamięci podręcznej.
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 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 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 typowe sytuacje. W większości przypadków nie musisz się martwić
o nagłówku Vary
. 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
to:
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 usługa Hosting dodaje
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
iHEAD
. Żą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 poleVary
działa na podstawie nagłówków żądania, a nie odpowiedzi nagłówki.
Korzystanie z plików cookie
Jeśli używasz pola Firebase Hosting razem z atrybutem Cloud Functions lub
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.