서비스 워커의 한 가지 기능은 서비스 워커가 설치될 때 파일을 캐시에 저장하는 기능입니다. 이를 '미리 캐싱'이라고 합니다. 사전 캐싱을 사용하면 네트워크에 연결하지 않고도 캐시된 파일을 브라우저에 제공할 수 있습니다. 사이트가 오프라인 상태일 때도 필요한 주요 애셋(기본 페이지, 스타일, 대체 이미지, 필수 스크립트)에 미리 캐싱을 사용하세요.
Workbox를 사용해야 하는 이유
사전 캐싱에 Workbox를 사용하는 것은 선택사항입니다. 서비스 워커가 설치될 때 중요한 애셋을 미리 캐시하는 자체 코드를 작성할 수 있습니다. Workbox를 사용할 때의 주요 이점은 즉시 사용할 수 있는 버전 제어입니다. Workbox를 사용하면 사전 캐시된 애셋을 업데이트할 때 이러한 파일의 버전 관리 및 업데이트를 직접 관리할 때보다 훨씬 덜 문제가 생깁니다.
매니페스트 미리 캐시
미리 캐싱은 URL 목록과 각 URL의 연결된 버전 관리 정보에 의해 실행됩니다. 이러한 정보를 통칭하여 미리 캐시 매니페스트라고 합니다. 매니페스트는 특정 버전의 웹 앱에 대한 미리 캐시의 모든 항목의 상태에 관한 '정보 소스'입니다. Workbox에서 사용하는 형식의 미리 캐시 매니페스트는 다음과 같습니다.
[{
url: 'app.abcd1234.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
서비스 워커가 설치되면 나열된 세 가지 URL 각각에 대해 캐시 저장소에 세 개의 캐시 항목이 생성됩니다. 첫 번째 애셋에는 URL에 이미 버전 관리 정보가 포함되어 있습니다(app는 실제 파일 이름이고 .abcd1234에는 파일 확장자 .js 바로 앞에 버전 관리 정보가 포함됨). Workbox의 빌드 도구는 이를 감지하고 버전 입력란을 제외할 수 있습니다. 다른 두 애셋은 URL에 버전 관리 정보를 포함하지 않으므로 Workbox의 빌드 도구는 로컬 파일 콘텐츠의 해시가 포함된 별도의 revision 필드를 생성합니다.
미리 캐시된 리소스 제공
캐시에 애셋을 추가하는 것은 미리 캐싱의 한 부분일 뿐입니다. 애셋이 캐시되면 나가는 요청에 응답해야 합니다. 이를 위해서는 서비스 워커에 사전 캐시된 URL을 확인하고 프로세스 중에 네트워크를 우회하여 이러한 캐시된 응답을 안정적으로 반환할 수 있는 fetch 이벤트 리스너가 필요합니다. 서비스 워커는 캐시에서 응답을 확인하고 네트워크보다 먼저 응답을 사용하므로 이를 캐시 우선 전략이라고 합니다.
효율적인 업데이트
미리 캐시된 매니페스트는 예상되는 캐시 상태를 정확하게 나타냅니다. 매니페스트의 URL/버전 조합이 변경되면 서비스 워커는 이전에 캐시된 항목이 더 이상 유효하지 않으며 업데이트해야 함을 인지합니다. 미리 캐시된 URL 중 새로고침해야 하는 URL을 확인하는 데는 서비스 워커 업데이트 확인의 일환으로 브라우저에서 자동으로 실행하는 단일 네트워크 요청만 필요합니다.
미리 캐시된 리소스 업데이트
시간이 지남에 따라 웹 앱의 새 버전을 출시할 때는 이전에 미리 캐시된 URL을 최신 상태로 유지하고, 새 애셋을 미리 캐시하고, 오래된 항목을 삭제해야 합니다. 사이트를 빌드할 때마다 전체 미리 캐시 매니페스트를 계속 생성하는 한, 이 매니페스트는 언제든지 미리 캐시 상태의 '소스' 역할을 합니다.
새 버전 필드가 있는 기존 URL이 있거나 매니페스트에서 URL이 추가 또는 삭제된 경우 서비스 워커는 install 및 activate 이벤트 핸들러의 일부로 업데이트를 실행해야 한다는 신호를 받습니다. 예를 들어 사이트를 일부 변경하고 다시 빌드한 경우 최신 사전 캐시 매니페스트에 다음과 같이 변경되었을 수 있습니다.
[{
url: 'app.ffaa4455.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
이러한 각 변경사항은 이전에 캐시된 항목('offline.svg' 및 'index.html')을 업데이트하고 새 URL을 캐시('app.ffaa4455.js')하는 것과 더 이상 사용되지 않는 URL을 삭제하여 정리('app.abcd1234.js')하기 위해 새 요청을 보내야 한다고 서비스 워커에 알립니다.
진정한 '앱 스토어' 설치 환경
미리 캐싱의 또 다른 이점은 '앱 스토어' 설치 외부에서 달성하기 어려운 환경을 사용자에게 제공할 수 있다는 것입니다. 사용자가 웹 앱의 페이지를 처음 방문하면 사용자가 개별 뷰를 방문할 때까지 기다릴 필요 없이 모든 웹 앱 뷰를 미리 표시하는 데 필요한 모든 URL을 미리 캐시할 수 있습니다.
사용자는 앱을 설치할 때 이전에 방문한 뷰뿐만 아니라 모든 부분이 빠르게 표시되기를 기대합니다. 사전 캐싱은 동일한 경험을 웹 앱에 제공합니다.
어떤 애셋을 미리 캐시해야 하나요?
로드되는 항목 식별 가이드를 다시 참고하여 사전 캐시하기에 가장 적합한 URL을 파악하세요. 일반적인 규칙은 초기에 로드되고 특정 페이지의 기본 구조를 표시하는 데 중요한 HTML, JavaScript 또는 CSS를 미리 캐시하는 것입니다.
웹 앱의 기능에 중요한 경우가 아니라면 나중에 로드되는 미디어 또는 기타 애셋을 미리 캐시하지 않는 것이 좋습니다. 대신 런타임 캐싱 전략을 사용하여 이러한 애셋이 사용한 만큼 캐시되도록 하세요.
앱 스토어에서 앱을 설치할 때와 마찬가지로 미리 캐시하면 사용자 기기에서 네트워크 대역폭과 저장소를 사용해야 합니다. 개발자는 현명하게 미리 캐시하고 부풀려진 미리 캐시 매니페스트를 피해야 합니다.
Workbox의 빌드 도구는 미리 캐시 매니페스트의 항목 수와 미리 캐시 페이로드의 총 크기를 알려주므로 유용합니다.
웹 앱을 반복 방문하는 사용자는 전송을 피하는 기능이 시간이 지남에 따라 절약되는 대역폭으로 빠르게 비용을 상쇄하므로, 사전 캐싱의 초기 비용으로 장기적으로 이익을 얻습니다.