Zawartość aplikacji w pamięci podręcznej

Cloud CDN jest kluczowym elementem obsługi aplikacji internetowej w App Hosting. Każde żądanie do backendu przechodzi najpierw przez Cloud CDN. Treści, które są już zapisane w pamięci podręcznej CDN, są natychmiast udostępniane użytkownikowi, co pozwala uniknąć wysyłania żądania do usługi Cloud Run, w której działa kod serwera aplikacji internetowej. Więcej informacji o ogólnych zaletach sieci CDN znajdziesz w witrynie web.dev.

Podstawowa konfiguracja Cloud CDN jest ustawiana przez App Hosting i nie można jej modyfikować. Możesz jednak zoptymalizować buforowanie, aby zwiększyć szybkość wczytywania stron, zmniejszyć ilość płatnych treści niebuforowanych i zminimalizować ruch do Cloud Run.

Treści podlegające zapisywaniu w pamięci podręcznej

Cloud CDN przechowuje odpowiedzi w pamięci podręcznej, jeśli WSZYSTKIE z tych warunków są spełnione:

  1. Żądanie jest typu GET.

  2. Odpowiedź ma kod stanu 200, 203, 204, 206, 300, 301, 302, 307, 308, 404, 405, 410, 421, 451 lub 501.

  3. Odpowiedź ma nagłówek Cache-Control z dyrektywą max-age lub s-maxage albo nagłówek Expires ze znacznikiem czasu w przyszłości.

  4. Odpowiedź ma nagłówek Age lub nagłówek Cache-Control z jawną dyrektywą public.

  5. Rozmiar odpowiedzi nie przekracza 10 MiB.

i ŻADEN z tych warunków nie jest spełniony:

  1. Odpowiedź ma nagłówek Set-Cookie.

  2. Odpowiedź ma nagłówek Vary z wartością inną niż Accept, Accept-Encoding, Access-Control-Request-Headers, Access-Control-Request-Method, Origin, Sec-Fetch-Dest, Sec-Fetch-Mode, Sec-Fetch-Site, X-Goog-Allowed-Resources, X-Origin, RSC, Next-Router-State-Tree, Next-Router-Prefetch, lub Next-Router-Segment-Prefetch.

  3. Odpowiedź ma nagłówek Cache-Control z dyrektywą no-store lub private.

  4. Żądanie ma nagłówek Cache-Control z dyrektywą no-store.

  5. Żądanie ma nagłówek Authorization, chyba że odpowiedź ma jawną dyrektywę dotyczącą sterowania pamięcią podręczną.

Dostosowywanie działania za pomocą dyrektyw sterowania pamięcią podręczną

Next.js

Next.js ustawia dyrektywy sterowania pamięcią podręczną niejawnie na podstawie wielu czynników. Możesz jednak zastąpić te ustawienia, ręcznie ustawiając nagłówek w pliku next.config.js. Aby na przykład mieć pewność, że strona nie jest buforowana w Cloud CDN:

  /** @type {import('next').NextConfig} */
  const nextConfig = {
      headers: async () => [{
          source: "/YOUR_PRIVATE_PAGE",
          headers: [{
              key: "Cache-Control",
              value: "private"
          }],
      }],
  };

Angular

Angular SSR nie ustawia domyślnie jawnych dyrektyw sterowania pamięcią podręczną. Możesz dodać własne, określając nagłówki sterowania pamięcią podręczną w trasach serwera. Aby na przykład zezwolić Cloud CDN na buforowanie wszystkich stron przez godzinę:

import { RenderMode, ServerRoute } from '@angular/ssr';

export const serverRoutes: ServerRoute[] = [
  {
    path: '**',
    renderMode: RenderMode.Prerender,
    headers: {
      'Cache-Control': 'public, max-age=3600',
    }
  }
];

Lub aby mieć pewność, że określona strona nie będzie buforowana:

import { RenderMode, ServerRoute } from '@angular/ssr';

export const serverRoutes: ServerRoute[] = [
  // ... other routes
  {
    path: 'YOUR_PRIVATE_PAGE',
    renderMode: RenderMode.Server,
    headers: {
      'Cache-Control': 'private',
    }
  }
];

Uwzględniane dyrektywy

Instancja Cloud CDN w Firebase App Hosting's uwzględnia te dyrektywy sterowania pamięcią podręczną:

Dyrektywa Żądanie Odpowiedź
no-store Jeśli ta dyrektywa jest obecna w żądaniu, odpowiedź nie będzie buforowana. Odpowiedź z dyrektywą no-store nie jest buforowana.
no-cache Dyrektywa żądania no-cache jest ignorowana, aby uniemożliwić klientom inicjowanie lub wymuszanie ponownej weryfikacji w punkcie początkowym. Odpowiedź z dyrektywą no-cache jest buforowana, ale przed jej udostępnieniem musi zostać ponownie zweryfikowana w punkcie początkowym.
public Nie dotyczy Ta dyrektywa nie jest wymagana do buforowania, ale warto ją uwzględnić w przypadku treści, które powinny być buforowane przez serwery proxy.
private Nie dotyczy Odpowiedź z dyrektywą private nie jest buforowana przez Cloud CDN, nawet jeśli w przeciwnym razie byłaby uznawana za podlegającą buforowaniu. Klienci (np. przeglądarki) mogą nadal buforować wynik. Aby zapobiec buforowaniu odpowiedzi, użyj dyrektywy no-store.
max-age=SECONDS Dyrektywa żądania max-age jest ignorowana. Buforowana odpowiedź jest zwracana tak, jakby ten nagłówek nie był uwzględniony w żądaniu. Odpowiedź z dyrektywą max-age jest buforowana przez zdefiniowaną liczbę SEKUND.
s-maxage=SECONDS Nie dotyczy Odpowiedź z dyrektywą s-maxage jest buforowana przez zdefiniowaną liczbę SEKUND. Jeśli obecne są zarówno dyrektywy max-age, jak i s-maxage, Cloud CDN używa dyrektywy s‑maxage. Odpowiedzi z tą dyrektywą nie są udostępniane jako nieaktualne. Dyrektywa s-max-age (z dwoma łącznikami) nie jest prawidłowa na potrzeby buforowania.
max-stale=SECONDS Dyrektywa żądania max-stale określa maksymalną nieaktualność (w sekundach), jaką klient jest gotów zaakceptować. Cloud CDN uwzględnia tę dyrektywę i zwraca nieaktualną buforowaną odpowiedź tylko wtedy, gdy nieaktualność odpowiedzi jest mniejsza niż wartość dyrektywy max-stale. W przeciwnym razie przed udostępnieniem żądania ponownie je weryfikuje. Nie dotyczy
stale-while-revalidate=SECONDS Nie dotyczy Odpowiedź z dyrektywą stale-while-revalidate jest udostępniana klientowi przez maksymalnie SEKUND, podczas gdy ponowna weryfikacja odbywa się asynchronicznie.
must-revalidate Nie dotyczy Odpowiedź z dyrektywą must-revalidate jest ponownie weryfikowana na serwerze pierwotnym po wygaśnięciu. Odpowiedzi z tą dyrektywą nie są udostępniane jako nieaktualne.
proxy-revalidate Odpowiedź z dyrektywą proxy-revalidate jest ponownie weryfikowana na serwerze pierwotnym po wygaśnięciu. Odpowiedzi z tą dyrektywą nie są udostępniane jako nieaktualne.
no-transform Nie dotyczy Cloud CDN nie stosuje żadnych przekształceń.

Pomiar ruchu buforowanego i niebuforowanego

Na karcie App Hosting > Użycie w konsoli Firebase wykres „Cloud CDN – przepustowość wychodząca” pokazuje liczbę udostępnionych bajtów buforowanych i niebuforowanych oraz zawiera oznaczenie każdej wersji. Za pomocą tego wykresu możesz mierzyć skuteczność działań związanych z optymalizacją pamięci podręcznej.

Możesz też wyświetlić współczynnik trafień w pamięci podręcznej w przypadku określonych tras w aplikacji internetowej za pomocą monitorowania opartego na trasach.