앱 콘텐츠 캐시

Cloud CDN은 App Hosting의 웹 앱 지원에서 중요한 부분입니다. 백엔드에 대한 모든 요청은 먼저 Cloud CDN을 통과합니다. CDN에 이미 캐시된 콘텐츠는 웹 앱의 서버 코드를 실행하는 Cloud Run 서비스로 이동하는 단계를 건너뛰고 사용자에게 즉시 다시 제공됩니다. web.dev에서 CDN의 일반적인 이점에 대해 자세히 알아보세요.

기본 Cloud CDN 구성은 App Hosting에 의해 설정되며 수정할 수 없지만, 페이지 로드 속도를 높이고, 캐시되지 않은 콘텐츠에 청구되는 비용을 줄이며, Cloud Run으로의 트래픽을 최소화하기 위해 캐싱을 최적화하는 데 사용할 수 있는 여러 가지 방법이 있습니다.

캐시 가능한 콘텐츠

Cloud CDN은 다음 조건이 모두 참인 경우 캐시에 응답을 저장합니다.

  1. 요청이 GET입니다.

  2. 응답의 상태 코드가 200, 203, 204, 206, 300, 301, 302, 307, 308, 404, 405, 410, 421, 451, 501입니다.

  3. 응답에 max-age 또는 s-maxage 지시문이 있는 Cache-Control 헤더가 있거나 이후 타임스탬프를 포함하는 Expires 헤더가 있습니다.

  4. 응답에 Age 헤더 또는 명시적 public 지시문이 있는 Cache-Control 헤더가 있습니다.

  5. 응답 크기는 10MiB 이하입니다.

다음 중 하나도 참이 아닙니다.

  1. 응답에 Set-Cookie 헤더가 있음

  2. 응답에 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 또는 Next-Router-Segment-Prefetch 이외의 값이 있는 Vary 헤더가 있습니다.

  3. 응답에 no-store 또는 private 지시문이 있는 Cache-Control 헤더가 있습니다.

  4. 요청에 no-store 지시문이 있는 Cache-Control 헤더가 있습니다.

  5. 응답에 명시적인 캐시 관리 지시문이 없는 한 요청에 Authorization 헤더가 있습니다.

캐시 제어 지시어로 동작 맞춤설정

Next.js

Next.js는 여러 요소를 기반으로 cache-control 지시어를 암시적으로 설정합니다. 하지만 next.config.js 파일에서 헤더를 수동으로 설정하여 이를 재정의할 수 있습니다. 예를 들어 페이지가 Cloud CDN에 캐시되지 않도록 하려면 다음 단계를 따르세요.

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

Angular

Angular SSR은 기본적으로 명시적인 cache-control 지시어를 설정하지 않습니다. 서버 경로에서 cache-control 헤더를 지정하여 자체 헤더를 추가할 수 있습니다. 예를 들어 Cloud CDN이 1시간 동안 모든 페이지를 캐시하도록 허용하려면 다음을 실행합니다.

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

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

또는 특정 페이지가 캐시되지 않도록 하려면 다음을 실행합니다.

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

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

준수해야 하는 지시어

Firebase App Hosting의 Cloud CDN 인스턴스는 다음 캐시 제어 지시어를 따릅니다.

지시문 요청 응답
no-store 요청에 있는 경우 응답이 캐시되지 않습니다. no-store가 포함된 응답은 캐시되지 않습니다.
no-cache 클라이언트가 원본에 재검증을 잠재적으로 시작하거나 강제하지 못하게 하기 위해 no-cache 요청 지시문은 무시됩니다. no-cache가 포함된 응답은 캐시되지만 제공하기 전에 원본으로 재검증해야 합니다.
public 해당 사항 없음 캐시 가능성에는 이 지시문이 필요하지 않지만 프록시에서 캐시해야 하는 콘텐츠에 포함하는 것이 좋습니다.
private 해당 사항 없음 private 지시문이 있는 응답은 응답이 캐시 가능한 것으로 간주되는 경우에도 Cloud CDN에 의해 캐시되지 않습니다. 클라이언트(예: 브라우저)는 여전히 결과를 캐시할 수 있습니다. 모든 응답 캐싱을 방지하려면 no-store를 사용합니다.
max-age=SECONDS max-age 요청 지시문은 무시됩니다. 이 헤더가 요청에 포함되지 않은 것처럼 캐시된 응답이 반환됩니다. max-age 지시문이 있는 응답은 정의된 SECONDS로 캐시됩니다.
s-maxage=SECONDS 해당 사항 없음 s-maxage 지시문이 있는 응답은 정의된 SECONDS로 캐시됩니다. max-age와 s-maxage가 모두 있는 경우 Cloud CDN에서 s‑maxage를 사용합니다. 이 지시문이 있는 응답은 비활성 상태가 아닙니다. s-max-age (하이픈 2개)는 캐싱 목적에 유효하지 않습니다.
max-stale=SECONDS max-stale 요청 지시문은 클라이언트가 허용할 최대 비활성 상태를 초 단위로 나타냅니다. Cloud CDN은 이를 받아들여 응답의 비활성 상태가 max-stale 지시문보다 짧은 경우에만 오래된 캐시된 응답을 반환합니다. 그렇지 않으면 요청을 처리하기 전에 재검증합니다. 해당 사항 없음
stale-while-revalidate=SECONDS 해당 사항 없음 stale-while-revalidate가 있는 응답은 클라이언트에 최대 SECONDS까지 제공되고 재검증이 비동기식으로 발생합니다.
must-revalidate 해당 사항 없음 must-revalidate가 있는 응답은 만료된 후 원본 서버에서 재검증합니다. 이 지시문이 있는 응답은 비활성 상태가 아닙니다.
proxy-revalidate proxy-revalidate가 있는 응답은 만료된 후 원본 서버에서 재검증합니다. 이 지시문이 있는 응답은 비활성 상태가 아닙니다.
no-transform 해당 사항 없음 Cloud CDN에는 변환이 적용되지 않습니다.

캐시된 트래픽 및 캐시되지 않은 트래픽 측정

App Hosting 콘솔의 사용량 탭에 있는 'Cloud CDN - 아웃바운드 대역폭' 그래프에는 캐시된 바이트와 캐시되지 않은 바이트가 표시되며 각 출시에 대한 표시가 있습니다. 이 그래프를 사용하여 캐시 최적화 작업의 효과를 측정할 수 있습니다.