비활성 상태 재검증을 통해 최신 상태 유지

웹 앱을 제공할 때 즉시성과 최신성의 균형을 맞추는 데 도움이 되는 추가 도구입니다.

Jeff Posnick

출시된 기능

stale-while-revalidate는 개발자가 즉시성(캐시된 콘텐츠를 바로 로드)과 최신성(캐시된 콘텐츠의 업데이트가 향후 사용되도록 보장) 간의 균형을 유지하는 데 도움이 됩니다. 정기적으로 업데이트되는 서드 파티 웹 서비스 또는 라이브러리를 유지관리하거나 퍼스트 파티 애셋의 수명이 짧은 경우 stale-while-revalidate를 기존 캐싱 정책에 추가하면 유용할 수 있습니다.

Cache-Control 응답 헤더에서 max-age와 함께 stale-while-revalidate를 설정하는 기능은 Chrome 75 및 Firefox 68에서 지원됩니다.

stale-while-revalidate를 지원하지 않는 브라우저는 해당 구성 값을 자동으로 무시하고 max-age를 사용합니다. 이에 대해서는 잠시 후에 설명하겠습니다.

무슨 뜻인가요?

stale-while-revalidate를 캐시된 응답이 오래되었을 수 있다는 생각과 재검증 프로세스라는 두 부분으로 나누어 살펴보겠습니다.

먼저 브라우저는 캐시된 응답이 'stale'인지 어떻게 알 수 있을까요? stale-while-revalidate를 포함하는 Cache-Control 응답 헤더에는 max-age도 포함되어야 하며 max-age를 통해 지정된 초 수에 따라 비활성이 결정됩니다. max-age보다 최신인 캐시된 응답은 최신으로 간주되고 이전의 캐시된 응답은 오래된 것으로 간주됩니다.

로컬에 캐시된 응답이 여전히 최신 상태이면 브라우저의 요청을 처리하는 데 그대로 사용할 수 있습니다. stale-while-revalidate의 관점에서 이 시나리오에서는 아무것도 할 필요가 없습니다.

하지만 캐시된 응답이 오래된 경우 다른 기간 기반 검사가 수행됩니다. 캐시된 응답의 기간이 stale-while-revalidate 설정에서 제공하는 추가 기간 내에 있나요?

오래된 응답의 기간이 이 기간에 속하면 브라우저의 요청을 처리하는 데 사용됩니다. 동시에 캐시된 응답의 사용을 지연시키지 않는 방식으로 네트워크에 '재검증' 요청이 전송됩니다. 반환된 응답에는 이전에 캐시된 응답과 동일한 정보가 포함될 수도 있고, 다른 정보가 포함될 수도 있습니다. 어느 쪽이든 네트워크 응답은 로컬에 저장되어 이전에 캐시된 항목을 대체하고 향후 max-age 비교 중에 사용되는 '새로고침' 타이머를 재설정합니다.

그러나 오래된 캐시된 응답이 stale-while-revalidate 기간을 벗어날 만큼 오래된 경우 브라우저의 요청을 처리하지 않습니다. 대신 브라우저는 네트워크에서 응답을 가져와 초기 요청을 처리하고 로컬 캐시를 새로운 응답으로 채우는 데 사용합니다.

실시간 예시

다음은 현재 시간, 더 구체적으로는 현재 시간에서 경과한 시간(분)을 반환하는 HTTP API의 간단한 예시입니다.

이 시나리오에서 웹 서버는 HTTP 응답에 이 Cache-Control 헤더를 사용합니다.

Cache-Control: max-age=1, stale-while-revalidate=59

이 설정은 다음 1초 이내에 시간 요청이 반복되면 이전에 캐시된 값이 여전히 최신 상태이며 재검증 없이 그대로 사용된다는 의미입니다.

1~60초 후에 요청이 반복되면 캐시된 값이 오래되었지만 API 요청을 처리하는 데 사용됩니다. 동시에 '백그라운드에서' 재검증 요청이 이루어져 향후 사용을 위해 캐시를 새로운 값으로 채웁니다.

60초가 지난 후 요청이 반복되면 오래된 응답은 전혀 사용되지 않으며 브라우저의 요청 처리와 캐시 재검증은 모두 네트워크에서 응답을 다시 받는 것에 따라 달라집니다.

다음은 이 세 가지 상태와 각 상태가 예시에 적용되는 기간을 보여줍니다.

이전 섹션의 정보를 보여주는 다이어그램

일반적인 사용 사례는 무엇인가요?

위의 '정각 이후 경과 시간' API 서비스 예시는 인위적이지만 예상되는 사용 사례를 보여줍니다. 즉, 새로고침이 필요한 정보를 제공하지만 어느 정도의 비활성은 허용되는 서비스입니다.

좀 더 자연스러운 예시로는 현재 기상 상태를 알려주는 API나 지난 1시간 동안 작성된 주요 뉴스 헤드라인을 알려주는 API가 있습니다.

일반적으로 알려진 간격으로 업데이트되고 여러 번 요청될 가능성이 있으며 해당 간격 내에서 정적인 응답은 max-age를 통한 단기 캐싱에 적합합니다. max-age 외에도 stale-while-revalidate를 사용하면 네트워크 응답을 차단하지 않고도 최신 콘텐츠가 포함된 캐시에서 향후 요청을 처리할 가능성이 높아집니다.

서비스 워커와 어떻게 상호작용하나요?

stale-while-revalidate에 대해 들어본 적이 있다면 서비스 워커 내에서 사용되는 레시피의 맥락에서 들어봤을 가능성이 높습니다.

Cache-Control 헤더를 통해 stale-while-revalidate를 사용하는 것은 서비스 워커에서 사용하는 것과 유사하며, 최신 상태 장단점 및 최대 전체 기간에 관한 동일한 고려사항이 많이 적용됩니다. 하지만 서비스 워커 기반 접근 방식을 구현할지 아니면 Cache-Control 헤더 구성에만 의존할지 결정할 때 고려해야 할 몇 가지 사항이 있습니다.

다음과 같은 경우 서비스 워커 접근 방식을 사용하세요.

  • 웹 앱에서 이미 서비스 워커를 사용하고 있습니다.
  • 캐시 콘텐츠를 세밀하게 제어해야 하며 가장 최근에 사용한 만료 정책과 같은 항목을 구현하려고 합니다. Workbox의 캐시 만료 모듈이 이 작업에 도움이 될 수 있습니다.
  • 재검증 단계에서 백그라운드에서 오래된 응답이 변경될 때 알림을 받으려고 합니다. Workbox의 Broadcast Cache Update 모듈이 이 작업에 도움이 될 수 있습니다.
  • 모든 최신 브라우저에서 이 stale-while-revalidate 동작이 필요합니다.

Cache-Control 접근 방식을 사용하는 경우…

  • 웹 앱의 서비스 워커를 배포하고 유지관리하는 오버헤드를 처리하지 않으려는 경우
  • 브라우저의 자동 캐시 관리를 통해 로컬 캐시가 너무 커지지 않도록 방지할 수 있습니다.
  • 현재 모든 최신 브라우저에서 지원되지 않는 접근 방식도 괜찮습니다 (2019년 7월 기준, 향후 지원이 확대될 수 있음).

서비스 워커를 사용하고 Cache-Control 헤더를 통해 일부 응답에 stale-while-revalidate를 사용 설정한 경우 일반적으로 서비스 워커가 요청에 대한 응답을 '먼저 처리'합니다. 서비스 워커가 응답하지 않기로 결정하거나 응답을 생성하는 과정에서 fetch()를 사용하여 네트워크 요청을 하는 경우 Cache-Control 헤더를 통해 구성된 동작이 적용됩니다.

자세히 알아보기