updateViaCache는 worker script의 업데이트 검사와 runtime Cache Storage를 어떻게 다르게 다루나요?

updateViaCache는 등록된 worker script의 업데이트 검사에서 HTTP cache를 사용할지 정하는 등록 설정이고, runtime Cache Storage의 응답 선택과는 별개입니다. 세 값의 차이는 명확합니다. imports는 top-level worker script는 HTTP cache를 우회하지만 imported script에는 HTTP cache를 허용합니다. all은 top-level과 imported script 모두 HTTP cache를 고려하고, none은 둘 다 우회합니다. 기본값은 imports입니다.

예를 들어 sw.js=v4, helper.js=v3, runtime cache의 /api/items=v1을 두면 imports에서는 sw.js의 검사는 새 바이트를 확인하는 경로가 되고 helper.js는 HTTP cache 정책 영향을 받을 수 있습니다. runtime-v1은 그 어느 값에서도 자동으로 만료되지 않습니다. worker가 새로 설치돼도 fetch handler가 runtime-v1을 먼저 match하면 오래된 API가 반환됩니다. 그래서 로그를 script update check, install/activate, runtime match, HTTP Age·ETag·304로 분리합니다. 명세의 값과 알고리즘을 기준으로 설명했지만 실제 업데이트 검사 시점과 브라우저별 재검증은 대상 매트릭스에서 확인해야 합니다.

여기서 “우회”는 runtime fetch가 네트워크로만 간다는 뜻이 아니라 업데이트 알고리즘이 HTTP cache를 고려하는 방식의 차이입니다. importScripts('/helper.js')로 의존하는 파일은 imports 모드에서 top-level과 다른 경로를 가지므로, helper 변경을 배포했는데 sw.js 바이트만 확인한 상황을 별도로 테스트해야 합니다. 반면 /api/items는 worker가 실행된 뒤 Cache API로 조회하는 데이터이므로 세 enum의 직접 대상이 아닙니다. script 응답의 버전과 runtime 응답의 세대를 같은 로그 필드에 섞지 않는 것이 핵심입니다.