서비스 워커 캐시 및 HTTP 캐시 레이어에서 일관되거나 다른 만료 로직을 사용할 때의 장단점
서비스 워커와 PWA가 최신 웹 애플리케이션의 표준이 되고 있지만 리소스 캐싱은 그 어느 때보다 복잡해졌습니다. 이 문서에서는 다음을 포함하여 브라우저 캐싱의 전반적인 상황을 설명합니다.
- 서비스 워커 캐싱과 HTTP 캐싱의 사용 사례와 차이점
- 일반 HTTP 캐싱 전략과 비교한 다양한 서비스 워커 캐싱 만료 전략의 장단점
캐싱 흐름 개요
상위 수준에서 브라우저는 리소스를 요청할 때 아래의 캐싱 순서를 따릅니다.
- 서비스 워커 캐시: 서비스 워커는 리소스가 캐시에 있는지 확인하고 프로그래밍된 캐싱 전략에 따라 리소스 자체를 반환할지 여부를 결정합니다. 이 과정은 자동으로 수행되지 않습니다. 네트워크 대신 서비스 워커의 캐시에서 요청이 처리되도록 서비스 워커에 가져오기 이벤트 핸들러를 만들고 네트워크 요청을 가로채야 합니다.
- HTTP 캐시 (브라우저 캐시라고도 함): 리소스가 HTTP 캐시에 있고 아직 만료되지 않은 경우 브라우저가 HTTP 캐시의 리소스를 자동으로 사용합니다.
- 서버 측: 서비스 워커 캐시나 HTTP 캐시에 아무것도 없는 경우 브라우저가 네트워크로 이동하여 리소스를 요청합니다. 리소스가 CDN에 캐시되지 않으면 요청은 원본 서버로 다시 이동해야 합니다.
레이어 캐싱
서비스 워커 캐싱
서비스 워커는 네트워크 유형 HTTP 요청을 가로채고 캐싱 전략을 사용하여 브라우저에 반환할 리소스를 결정합니다. 서비스 워커 캐시와 HTTP 캐시는 동일하게 범용적이지만 서비스 워커 캐시는 정확히 캐시되는 항목과 캐싱이 수행되는 방식에 대한 세분화된 제어 등 더 많은 캐싱 기능을 제공합니다.
서비스 워커 캐시 제어
서비스 워커는 이벤트 리스너 (일반적으로 fetch 이벤트)를 사용하여 HTTP 요청을 가로챕니다. 이 코드 스니펫은 캐시 우선 캐싱 전략의 로직을 보여줍니다.
시간을 낭비하지 않으려면 Workbox를 사용하는 것이 좋습니다. 예를 들어 한 줄의 정규식 코드로 리소스 URL 경로를 등록할 수 있습니다.
import {registerRoute} from 'workbox-routing';
registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);
서비스 워커 캐싱 전략 및 사용 사례
다음 표에는 일반적인 서비스 워커 캐싱 전략과 각 전략이 유용한 경우가 나와 있습니다.
| 전략 | 최신 업데이트 근거 | 사용 사례 |
|---|---|---|
| 네트워크 전용 | 콘텐츠가 항상 최신 상태여야 합니다. |
|
| 캐시로 대체하는 네트워크 | 최신 콘텐츠를 제공하는 것이 좋습니다. 하지만 네트워크가 실패하거나 불안정한 경우 약간 오래된 콘텐츠를 제공해도 됩니다. |
|
| 재검증 중 비활성 상태 | 캐시된 콘텐츠를 즉시 제공하는 것은 괜찮지만, 향후에 업데이트된 캐시된 콘텐츠를 사용해야 합니다. |
|
| 캐시 우선, 네트워크로 복귀 | 이 콘텐츠는 중요하지 않고 성능 향상을 위해 캐시에서 제공될 수 있지만 서비스 워커는 때때로 업데이트를 확인해야 합니다. |
|
| 캐시 전용 | 콘텐츠는 거의 변경되지 않습니다. |
|
서비스 워커 캐싱의 추가 이점
캐싱 로직을 세밀하게 제어하는 것 외에 서비스 워커 캐싱은 다음 기능도 제공합니다.
- 원본에 추가 메모리 및 저장공간: 브라우저가 원본별로 HTTP 캐시 리소스를 할당합니다. 즉, 여러 하위 도메인이 있는 경우 모두 동일한 HTTP 캐시를 공유합니다. 원본/도메인의 콘텐츠가 HTTP 캐시에 오랫동안 유지된다는 보장은 없습니다. 예를 들어 사용자가 브라우저의 설정 UI를 수동으로 정리하거나 페이지를 강제로 새로고침하여 캐시를 삭제할 수 있습니다. 서비스 워커 캐시를 사용하면 캐시된 콘텐츠가 캐시된 상태로 유지될 가능성이 훨씬 커집니다. 자세한 내용은 영구 스토리지를 참조하세요.
- 불안정한 네트워크 또는 오프라인 환경에 따른 유연성 향상: HTTP 캐시를 사용하면 리소스 캐시 여부와 상관없이 바이너리를 선택할 수 있습니다. 서비스 워커 캐싱을 사용하면 '비활성' 전략을 훨씬 쉽게 완화하고('비활성' 전략 사용), 완전한 오프라인 환경('캐시 전용' 전략 사용)을 제공하거나 페이지 일부를 서비스 워커 캐시에서 오는 페이지의 일부를 포함한 맞춤설정된 UI와 적절한 경우 '캐치 핸들러 설정' 전략 사용 (해당하는 경우)과 같은 완전한 오프라인 환경을 제공할 수 있습니다.
HTTP 캐싱
브라우저는 웹페이지 및 관련 리소스를 처음으로 로드할 때 이러한 리소스를 HTTP 캐시에 저장합니다. HTTP 캐시는 최종 사용자가 명시적으로 사용 중지하지 않는 한 일반적으로 브라우저에서 자동으로 사용 설정됩니다.
HTTP 캐싱을 사용한다는 것은 서버를 사용하여 리소스를 캐시할 시기와 기간을 결정한다는 것을 의미합니다.
HTTP 응답 헤더로 HTTP 캐시 만료 제어
서버가 브라우저 리소스에 응답할 때 서버는 HTTP 응답 헤더를 사용하여 리소스를 캐시해야 하는 시간을 브라우저에 알려줍니다. 자세한 내용은 응답 헤더: 웹 서버 구성을 참조하세요.
HTTP 캐싱 전략 및 사용 사례
HTTP 캐싱은 시간 기반 (TTL) 리소스 만료 로직만 처리하므로 HTTP 캐싱은 서비스 워커 캐싱보다 훨씬 간단합니다. HTTP 캐싱 전략에 대한 자세한 내용은 어떤 응답 헤더 값을 사용해야 하나요?와 요약을 참조하세요.
캐시 만료 로직 설계
이 섹션에서는 서비스 워커 캐시 및 HTTP 캐시 레이어에서 일관된 만료 로직을 사용할 때의 장단점과 함께 이러한 레이어에 걸쳐 개별 만료 로직의 장단점을 설명합니다.
아래 Glitch는 여러 시나리오에서 서비스 워커 캐싱과 HTTP 캐싱이 작동하는 방식을 보여줍니다.
모든 캐시 레이어의 일관된 만료 로직
장단점을 설명하기 위해 장기, 중기, 단기의 3가지 시나리오를 살펴보겠습니다.
| 시나리오 | 장기 캐싱 | 중기 캐싱 | 단기 캐싱 |
|---|---|---|---|
| 서비스 워커 캐싱 전략 | 캐시, 네트워크로 복귀 | 재확인 중 비활성 상태 | 네트워크 캐시로 폴백 |
| 서비스 워커 캐시 TTL | 30일 | 1일 | 10분 |
| HTTP 캐시 max-age | 30일 | 1일 | 10분 |
시나리오: 장기 캐싱 (캐시, 네트워크로 대체)
- 캐시된 리소스가 유효한 경우(30일 이하): 서비스 워커는 네트워크로 이동하지 않고 캐시된 리소스를 즉시 반환합니다.
- 캐시된 리소스가 만료되는 경우(30일 초과): 서비스 워커가 리소스를 가져오기 위해 네트워크로 이동합니다. 브라우저의 HTTP 캐시에 리소스 사본이 없으므로 리소스를 위해 서버 측으로 이동합니다.
단점: 이 시나리오에서는 캐시가 서비스 워커에서 만료될 때 브라우저가 항상 서버 측에 요청을 전달하기 때문에 HTTP 캐싱의 값이 더 적습니다.
시나리오: 중기 캐싱 (비활성 기간 동안 재검증)
- 캐시된 리소스가 유효한 경우(1일 이하): 서비스 워커가 캐시된 리소스를 즉시 반환하고 네트워크로 이동하여 리소스를 가져옵니다. 브라우저의 HTTP 캐시에 리소스 사본이 있으므로 해당 사본을 서비스 워커에 반환합니다.
- 캐시된 리소스가 만료되는 경우(1일 초과): 서비스 워커가 캐시된 리소스를 즉시 반환하고 네트워크로 이동하여 리소스를 가져옵니다. 브라우저의 HTTP 캐시에 리소스 사본이 없으므로 서버 측으로 이동하여 리소스를 가져옵니다.
단점: '재검증' 단계를 최대한 활용하기 위해 서비스 워커에서 HTTP 캐시를 재정의하려면 추가적인 캐시 무효화가 필요합니다.
시나리오: 단기 캐싱 (네트워크가 캐시로 대체)
- 캐시된 리소스가 유효한 경우(10분 이하): 서비스 워커가 리소스를 가져오기 위해 네트워크로 이동합니다. 브라우저의 HTTP 캐시에 리소스 사본이 있으므로 서버 측으로 이동하지 않고 서비스 워커에 사본을 반환합니다.
- 캐시된 리소스가 만료되는 경우(10분 초과): 서비스 워커가 캐시된 리소스를 즉시 반환하고 네트워크로 이동하여 리소스를 가져옵니다. 브라우저의 HTTP 캐시에 리소스 사본이 없으므로 서버 측으로 이동하여 리소스를 가져옵니다.
단점: 중기적인 캐싱 시나리오와 마찬가지로 서비스 워커에 서버 측에서 최신 리소스를 가져오기 위해 HTTP 캐시를 재정의하기 위한 추가 캐시 무효화 로직이 필요합니다.
모든 시나리오에서의 서비스 워커
네트워크가 불안정한 경우에도 서비스 워커 캐시는 모든 시나리오에서 캐시된 리소스를 반환할 수 있습니다. 반면 HTTP 캐시는 네트워크가 불안정하거나 다운되면 신뢰할 수 없습니다.
서비스 워커 캐시 및 HTTP 레이어의 다른 캐시 만료 로직
장단점을 설명하기 위해 장기, 중기, 단기 시나리오를 다시 살펴보겠습니다.
| 시나리오 | 장기 캐싱 | 중기 캐싱 | 단기 캐싱 |
|---|---|---|---|
| 서비스 워커 캐싱 전략 | 캐시, 네트워크로 복귀 | 재확인 중 비활성 상태 | 네트워크 캐시로 폴백 |
| 서비스 워커 캐시 TTL | 90일 | 30일 | 1일 |
| HTTP 캐시 max-age | 30일 | 1일 | 10분 |
시나리오: 장기 캐싱 (캐시, 네트워크로 대체)
- 캐시된 리소스가 서비스 워커 캐시에서 유효한 경우(90일 이하): 서비스 워커가 캐시된 리소스를 즉시 반환합니다.
- 캐시된 리소스가 서비스 워커 캐시에서 만료된 경우(90일 초과): 서비스 워커가 리소스를 가져오기 위해 네트워크로 이동합니다. 브라우저의 HTTP 캐시에 리소스 사본이 없으므로 서버 측으로 이동합니다.
장점 및 단점:
- 장점: 서비스 워커가 캐시된 리소스를 즉시 반환하므로 사용자는 즉각적인 응답을 경험합니다.
- 장점: 서비스 워커는 캐시를 사용할 시기와 새 리소스 버전을 요청할 시기를 더 세밀하게 제어할 수 있습니다.
- 단점: 잘 정의된 서비스 워커 캐싱 전략이 필요합니다.
시나리오: 중간 캐싱 (재검증하는 동안 비활성 상태)
- 캐시된 리소스가 서비스 워커 캐시에서 유효한 경우(30일 이하): 서비스 워커가 캐시된 리소스를 즉시 반환합니다.
- 캐시된 리소스가 서비스 워커 캐시에서 만료된 경우(30일 초과): 서비스 워커가 리소스의 네트워크로 이동합니다. 브라우저의 HTTP 캐시에 리소스 사본이 없으므로 서버 측으로 이동합니다.
장점 및 단점:
- 장점: 서비스 워커가 캐시된 리소스를 즉시 반환하므로 사용자는 즉각적인 응답을 경험합니다.
- 장점: 유효성 재검사가 '백그라운드에서' 발생하므로 서비스 워커가 지정된 URL에 대한 다음 요청이 네트워크의 새 응답을 사용하도록 할 수 있습니다.
- 단점: 잘 정의된 서비스 워커 캐싱 전략이 필요합니다.
시나리오: 단기 캐싱 (네트워크가 캐시로 대체)
- 캐시된 리소스가 서비스 워커 캐시에서 유효한 경우(1일 이하): 서비스 워커가 리소스의 네트워크로 이동합니다. 브라우저는 HTTP 캐시가 있으면 해당 리소스를 반환합니다. 네트워크가 다운되면 서비스 워커는 서비스 워커 캐시에서 리소스를 반환합니다.
- 캐시된 리소스가 서비스 워커 캐시에서 만료된 경우(1일 초과): 서비스 워커가 리소스를 가져오기 위해 네트워크로 이동합니다. HTTP 캐시에 캐시된 버전이 만료되면 브라우저가 네트워크를 통해 리소스를 가져옵니다.
장점 및 단점:
- 장점: 네트워크가 불안정하거나 다운되면 서비스 워커가 캐시된 리소스를 즉시 반환합니다.
- 단점: HTTP 캐시를 재정의하고 '네트워크 우선' 요청을 수행하려면 서비스 워커가 추가적인 캐시 무효화를 수행해야 합니다.
결론
캐싱 시나리오 조합의 복잡성을 고려할 때 모든 사례에 적용되는 하나의 규칙을 설계하는 것은 불가능합니다. 그러나 이전 섹션의 결과를 기반으로 캐시 전략을 설계할 때 고려할 몇 가지 제안 사항이 있습니다.
- 서비스 워커 캐싱 로직은 HTTP 캐싱 만료 로직과 일관되지 않아도 됩니다. 가능하면 서비스 워커에서 더 긴 만료 로직을 사용하여 서비스 워커에 더 많은 제어 권한을 부여하세요.
- HTTP 캐싱은 여전히 중요한 역할을 하지만, 네트워크가 불안정하거나 다운되면 신뢰할 수 없습니다.
- 각 리소스의 캐싱 전략을 다시 방문하여 서비스 워커 캐싱 전략이 HTTP 캐시와 충돌하지 않고 값을 제공하는지 확인합니다.