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, która uruchamia 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 spełnione są WSZYSTKIE te warunki:

  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ą kontroli pamięci podręcznej.

Dostosowywanie działania za pomocą dyrektyw kontroli pamięci podręcznej

Next.js

Next.js ustawia dyrektywy cache-control niejawnie na podstawie kilku 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 cache-control. Możesz dodać własne, określając nagłówki cache-control 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 cache control:

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 określony czas (w SEKUNDACH).
s-maxage=SECONDS Nie dotyczy Odpowiedź z dyrektywą s-maxage jest buforowana przez określony czas (w SEKUNDACH). Jeśli występują zarówno dyrektywa 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 2 łą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 określony czas (w SEKUNDACH), 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ę buforowanych i niebuforowanych bajtów oraz oznaczenie każdej wersji. Za pomocą tego wykresu możesz mierzyć skuteczność optymalizacji 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.