Zarządzaj zachowaniem pamięci podręcznej

Firebase Hosting wykorzystuje potężną globalną sieć CDN, aby Twoja witryna działała tak szybko, jak to możliwe.

Żądana zawartość statyczna jest automatycznie zapisywana w pamięci podręcznej w sieci CDN . Jeśli ponownie wdrożysz zawartość witryny, Firebase Hosting automatycznie wyczyści całą zawartość statyczną przechowywaną w pamięci podręcznej w sieci CDN do następnego żądania.

Ponieważ jednak usługi Cloud Functions i Cloud Run generują treści dynamicznie, treść dla 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, z wyjątkiem żądań zwracających błędy 404. Aby wyczyścić zapisane w pamięci podręcznej wyniki 404, ponownie wdróż Firebase Hosting; ponowne wdrożenie Cloud Functions i Cloud Run nie unieważnia automatycznie pamięci podręcznej.

Możesz jednak skonfigurować zachowanie pamięci podręcznej dla zawartości dynamicznej . Na przykład, jeśli funkcja generuje nową zawartość tylko okresowo, możesz przyspieszyć działanie aplikacji, przechowując wygenerowaną zawartość w pamięci podręcznej przez co najmniej krótki okres czasu.

Możesz również potencjalnie obniżyć koszty wykonywania funkcji, ponieważ treść 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 poinformować zarówno przeglądarkę, jak i 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ą jako public . 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ą przechowywać zawartość w pamięci podręcznej. Po upływie ustawionego czasu przeglądarka i CDN muszą ponownie zweryfikować zawartość na serwerze źródłowym. W przykładowym nagłówku zezwalamy przeglądarce i sieci CDN na buforowanie zawartości przez pięć minut (zobacz s-maxage poniżej, aby zapoznać się z określonymi kontrolkami buforowania sieci CDN).

• s-maxage — zastępuje dyrektywę max-age tylko dla buforowania CDN; informuje CDN, ile sekund może przechowywać zawartość w pamięci podręcznej. Po upływie ustawionego czasu CDN musi ponownie zweryfikować zawartość na serwerze źródłowym. W przykładowym nagłówku zastępujemy ustawienie max-age tylko dla sieci CDN i zezwalamy sieci CDN na buforowanie zawartości przez dziesięć minut.

W parametrach max-age i s-maxage ustaw ich wartości na najdłuższy okres czasu, przez jaki użytkownicy mogą otrzymywać nieaktualne treści. Jeśli strona zmienia się co kilka sekund, użyj małej wartości czasu. Jednak inne rodzaje 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 jest wyświetlana zawartość z pamięci podręcznej?

Przeglądarka i CDN przechowują zawartość w pamięci podręcznej na podstawie:

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

Zmieniaj nagłówki

Nagłówek Vary określa, których nagłówków żądań należy użyć, aby zapewnić odpowiednią odpowiedź (czy treść przechowywana w pamięci podręcznej jest prawidłowa lub czy treść powinna zostać ponownie zweryfikowana 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łówek Vary . Jednak w niektórych zaawansowanych przypadkach możesz mieć inne nagłówki, których potrzebujesz, aby wpłynąć 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 nagłówkami X-My-Custom-Header są buforowane oddzielnie. Pamiętaj, ż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żda sesja lub nagłówek autoryzacji pliku cookie, którego używasz, jest częścią klucza pamięci podręcznej, co zapobiega przypadkowym wyciekom treści.

Uwaga:

• Tylko żądania GET i HEAD mogą być buforowane. Żądania HTTPS korzystające z innych metod nigdy nie są buforowane.

• Zachowaj ostrożność podczas dodawania ustawień do nagłówka Vary . Im więcej dodasz ustawień, tym mniejsze jest prawdopodobieństwo, że CDN może obsługiwać zawartość z pamięci podręcznej. Pamiętaj też, że Vary opiera się na nagłówkach żądań , a nie nagłówkach odpowiedzi .

Korzystanie z plików cookie

Podczas korzystania z Firebase Hosting 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 plik cookie o specjalnej nazwie __session może przejść do wykonania Twojej aplikacji.

Jeśli jest obecny, plik cookie __session jest automatycznie włączany do klucza pamięci podręcznej, co oznacza, że ​​dwóch użytkowników z różnymi plikami cookie nie może otrzymać odpowiedzi z pamięci podręcznej drugiego. Używaj pliku cookie __session tylko wtedy, gdy Twoja aplikacja wyświetla różne treści w zależności od autoryzacji użytkownika.