Zarządzanie zachowaniem pamięci podręcznej

Firebase Hosting korzysta z wydajnej globalnej sieci CDN, aby zapewnić jak największą szybkość działania witryny.

Wszystkie żądane treści statyczne są automatycznie zapisywane w pamięci podręcznej CDN. Jeśli ponownie wdrożysz zawartość witryny, Firebase Hosting automatycznie wyczyści całą zawartość w pamięci podręcznej w sieci CDN do czasu następnego żądania.

Usługi Cloud Functions i Cloud Run generują jednak treści dynamicznie, więc 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 są buforowane w sieci CDN.

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

Podobnie możesz skonfigurować działanie pamięci podręcznej, aby potencjalnie obniżyć koszty wykonywania funkcji, ponieważ treści są obsługiwane z sieci CDN, a nie z wywoływanej funkcji. 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. Sieć CDN buforuje odpowiedź usługi 404 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ść była teraz dostępna pod tym adresem URL, sieć CDN będzie nadal wyświetlać wszelkie zapisane w pamięci podręcznej odpowiedzi 404 przez maksymalnie 10 minut, a następnie będzie normalnie wyświetlać treść 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ślny czas 10 minut i w pełni określają zachowanie buforowania sieci CDN.

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

Ustawianie nagłówka Cache-Control

Głównym narzędziem do zarządzania pamięcią podręczną treści dynamicznych jest nagłówek Cache-Control. Konfigurując ten nagłówek, możesz określić zarówno w przeglądarce, jak i w CDN, jak długo treści mogą być przechowywane w pamięci podręcznej. W funkcji ustawiasz Cache-Control w ten sposób:

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

W tym przykładzie nagłówka dyrektywy wykonują 3 czynności:

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

• max-age – informuje przeglądarkę i sieć CDN, przez ile sekund mogą przechowywać w pamięci podręcznej treść. Po upływie ustawionego czasu przeglądarka i sieć CDN muszą ponownie zweryfikować treść na serwerze pierwotnym. W przykładowym nagłówku zezwalamy przeglądarce i sieci CDN na buforowanie treści przez 5 minut (szczegółowe informacje o kontroli buforowania w sieci CDN znajdziesz w sekcji s-maxage poniżej).

• s-maxage – zastępuje dyrektywę max-age tylko w przypadku buforowania w sieci CDN; informuje sieć CDN, przez ile sekund może buforować treści. Po upływie ustawionego czasu sieć CDN musi ponownie zweryfikować zawartość na serwerze pierwotnym. W przykładzie nagłówka zastępujemy ustawienie max-age tylko dla sieci CDN i zezwalasz na buforowanie treści przez sieć CDN przez 10 minut.

W przypadku parametrów max-age i s-maxage ustaw najdłuższy czas, w którym użytkownicy mogą 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 godziny, dni, a nawet miesiące.

Więcej informacji o nagłówku Cache-Control znajdziesz w Mozilla Developer Network i w dokumentacji dla programistów stron internetowych Google.

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

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

• Nazwa hosta
• Ścieżka
• Ciąg zapytania
• Zawartość nagłówków żądań określonych w Vary nagłówku.

Nagłówki Vary

Nagłówek Vary określa, które nagłówki żądań powinny być używane do dostarczania odpowiedniej odpowiedzi (czy treść 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 w typowych sytuacjach. W większości przypadków nie musisz się martwić o nagłówek Vary. W niektórych zaawansowanych przypadkach możesz jednak mieć inne nagłówki, które mają wpływ na pamięć podręczną. W takim przypadku możesz ustawić nagłówek Vary w odpowiedzi. 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

Dzięki tym ustawieniom 2 identyczne żądania z różnymi nagłówkami X-My-Custom-Header są zapisywane w pamięci podręcznej oddzielnie. Pamiętaj, że Hosting domyślnie dodaje Cookie i Authorization do nagłówka Vary, gdy wysyłane jest żądanie treści dynamicznych. Dzięki temu każdy nagłówek autoryzacji sesji lub pliku cookie, którego używasz, staje się częścią klucza pamięci podręcznej, co zapobiega przypadkowym wyciekom treści.

Uwaga:

• 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 mogła wyświetlać treści z pamięci podręcznej. Pamiętaj też, że Vary opiera się na nagłówkach żądania, a nie na nagłówkach odpowiedzi.

Korzystanie z plików cookie

Gdy używasz polecenia Firebase Hosting razem z poleceniem 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 sieci CDN. Tylko specjalnie nazwany plik cookie __session może być przekazywany do wykonania aplikacji.

Gdy ten plik cookie jest obecny, automatycznie staje się częścią klucza pamięci podręcznej, co oznacza, że 2 użytkowników z różnymi plikami cookie nie może otrzymać odpowiedzi z pamięci podręcznej drugiego użytkownika.__session Używaj pliku cookie __session tylko wtedy, gdy aplikacja wyświetla różne treści w zależności od autoryzacji użytkownika.