Firebase Hosting은 강력한 CDN을 사용하여 사이트의 속도를 극대화합니다.
요청된 정적 콘텐츠는 CDN에 자동으로 캐시됩니다. 사이트의 콘텐츠를 재배포하면 Firebase Hosting은 다음 요청이 있을 때까지 CDN에서 캐시된 모든 콘텐츠를 자동으로 지웁니다.
그러나 Cloud Functions 및 Cloud Run 서비스는 동적으로 콘텐츠를 생성하므로 제공된 URL의 콘텐츠는 사용자 입력 또는 사용자의 ID와 같은 요소에 따라 달라질 수 있습니다. 따라서 백엔드 코드로 처리되는 요청은 기본적으로 CDN에 캐시되지 않습니다.
그래도 동적 콘텐츠에 대한 캐싱 동작을 구성할 수 있습니다. 예를 들어 함수가 일정한 주기로 새 콘텐츠를 생성한다면 생성된 콘텐츠를 짧은 시간 동안 캐시하여 앱의 속도를 높일 수 있습니다.
콘텐츠가 트리거된 함수를 통해서가 아닌 CDN에서 제공되므로 실행 비용을 줄일 수 있는 캐싱 동작을 유사하게 구성할 수 있습니다. 함수 실행 및 서비스 최적화에 대한 자세한 내용은 Cloud Functions 및 Cloud Run 문서를 참조하세요.
404 오류를 반환하는 요청은 예외입니다. CDN은 존재하지 않는 URL에 대한 서비스의 404 응답을 10분 동안 캐시하므로 이후 해당 URL에 대한 요청은 CDN에서 제공됩니다. 이제 콘텐츠가 이 URL에 존재하도록 서비스를 변경하면 CDN은 캐시된 404를 최대 10분 동안 계속 제공한 후 해당 URL의 콘텐츠를 정상적으로 제공합니다.
404 응답에 이미 Cloud Functions 또는 Cloud Run 서비스에서 설정한 캐싱 헤더가 포함되어 있는 경우 기본값 10분을 재정의하고 CDN의 캐싱 동작을 완전히 확인합니다.
캐싱 동작에 대한 자세한 내용은 Google의 웹 개발자 문서를 참조하세요.
Cache-Control 설정
동적 콘텐츠의 캐시를 관리할 때 주로 사용하는 도구는 Cache-Control 헤더입니다. 이 헤더를 구성하여 브라우저와 CDN에 콘텐츠를 캐시할 수 있는 기간을 전달할 수 있습니다. 함수에서는 다음과 같이 Cache-Control을 설정합니다.
res.set('Cache-Control', 'public, max-age=300, s-maxage=600');
이 예시 헤더의 지시문은 다음 세 가지 작업을 수행합니다.
public— 캐시를public으로 표시합니다. 즉, 브라우저 및 중간 서버(Firebase Hosting용 CDN) 둘 다 콘텐츠를 캐시할 수 있습니다.max-age— 콘텐츠를 캐시할 수 있는 시간을 초 단위로 브라우저와 CDN에 전달합니다. 지정된 시간이 만료되면 브라우저와 CDN은 원본 서버에서 콘텐츠를 다시 검증해야 합니다. 위 예시 헤더에서는 브라우저와 CDN에 5분 동안 콘텐츠를 캐시하도록 지시합니다. CDN 캐싱에 대한 특정 컨트롤은 아래의s-maxage를 참조하세요.s-maxage— CDN 캐싱에 대해서만max-age지시문을 재정의하고, 콘텐츠를 캐시할 수 있는 시간을 초 단위로 CDN에 전달합니다. 지정된 시간이 만료되면 CDN은 원본 서버에서 콘텐츠를 다시 검증해야 합니다. 위 예시 헤더에서는 CDN에 대해서만max-age설정을 재정의하고 CDN에 10분 동안 콘텐츠를 캐시하도록 합니다.
max-age 및 s-maxage의 값은 사용자가 최신 상태가 아닌 콘텐츠를 수신해도 무방한 제일 긴 시간으로 설정합니다. 페이지가 몇 초마다 바뀌는 경우에는 작은 값으로 지정합니다. 그러나 콘텐츠에 따라서는 몇 시간, 며칠 또는 몇 달 동안 캐시해도 무방할 수 있습니다.
Cache-Control 헤더에 관한 자세한 내용은 Mozilla 개발자 네트워크 및 Google의 웹 개발자 문서를 참조하세요.
캐시된 콘텐츠를 제공하는 시점
브라우저와 CDN은 다음을 기준으로 콘텐츠를 캐시합니다.
- 호스트 이름
- 경로
- 쿼리 문자열
Vary헤더에 지정된 요청 헤더의 콘텐츠
Vary 헤더
Vary 헤더는 적절한 응답을 제공하기 위해 사용해야 하는 요청 헤더를 확인합니다(캐시된 콘텐츠가 유효한지 여부 또는 콘텐츠를 원본 서버에서 재검증해야 하는지 여부).
Firebase Hosting은 일반적으로 응답에 적절한 Vary 헤더를 자동으로 설정합니다. 대부분의 경우에는 Vary 헤더를 신경쓰지 않아도 됩니다. 그러나 일부 고급 사용 사례에서는 다른 헤더로 캐시를 관리해야 할 수 있습니다. 이러한 경우 응답에 Vary 헤더를 설정하면 됩니다. 예를 들면 다음과 같습니다.
res.set('Vary', 'Accept-Encoding, X-My-Custom-Header');
이 경우 Vary 헤더 값은 다음과 같습니다.
vary: X-My-Custom-Header, x-fh-requested-host, accept-encoding, cookie, authorization
이러한 설정을 사용하면 X-My-Custom-Header 헤더만 다르고 나머지 부분은 동일한 두 요청이 서로 구분되어 캐시됩니다. Hosting은 동적 콘텐츠에 대한 요청이 이루어질 때 기본적으로 Cookie 및 Authorization을 Vary 헤더에 추가합니다. 이렇게 하면 사용하는 세션 또는 쿠키 승인 헤더가 캐시 키의 일부가 되어 우발적인 콘텐츠 유출을 방지할 수 있습니다.
또한 다음을 참고하세요
GET및HEAD요청만 캐시할 수 있습니다. 다른 메서드를 사용하는 HTTPS 요청은 절대 캐시되지 않습니다.Vary헤더에 설정을 추가할 때는 신중해야 합니다. 많은 설정을 추가할수록 CDN에서 캐시된 콘텐츠를 제공할 가능성이 낮아집니다. 또한Vary의 기준은 응답 헤더가 아니라 요청 헤더라는 점에 주의해야 합니다.
쿠키 사용
Firebase Hosting을 Cloud Functions 또는 Cloud Run과 함께 사용하면 수신 요청에서 일반적으로 쿠키가 제거됩니다. 이는 효율적인 CDN 캐시 동작을 위한 조치입니다.
특별히 __session으로 이름이 지정된 쿠키만 앱 실행으로 전달될 수 있습니다.
__session 쿠키가 있으면 자동으로 캐시 키에 포함되므로 서로 다른 쿠키를 사용하는 두 사용자는 상대방의 캐시된 응답을 수신할 수 없습니다. 앱에서 사용자 승인에 따라 다른 콘텐츠를 제공하는 경우만 __session 쿠키를 사용해야 합니다.