서비스 워커의 한 가지 기능은 서비스 워커를 설치할 때 파일을 캐시에 저장하는 기능입니다. 이를 '프리캐싱'이라고 합니다. 사전 캐싱을 사용하면 네트워크로 이동하지 않고도 캐시된 파일을 브라우저에 제공할 수 있습니다. 기본 페이지, 스타일, 대체 이미지, 필수 스크립트 등 사이트에 오프라인일 때도 필요한 중요한 애셋에 사전 캐싱을 사용하세요.
Workbox를 사용해야 하는 이유는 무엇인가요?
사전 캐싱에 Workbox를 사용하는 것은 선택사항입니다. 자체 코드를 작성하여 서비스 워커를 설치할 때 중요한 애셋을 사전 캐시할 수 있습니다. Workbox를 사용할 때의 주요 이점은 즉시 사용할 수 있는 버전 제어입니다. 이러한 파일의 버전 관리 및 업데이트를 직접 관리해야 하는 경우보다 Workbox를 사용하여 사전 캐시된 애셋을 업데이트할 때 발생하는 문제가 훨씬 적습니다.
매니페스트 사전 캐시
사전 캐싱은 URL 목록과 각 URL의 관련 버전 관리 정보에 기반합니다. 종합적으로 이 정보를 사전 캐시 매니페스트라고 합니다. 매니페스트는 특정 웹 앱 버전의 사전 캐시에 있어야 하는 모든 항목의 상태에 관한 '정보 소스'입니다. 사전 캐시 매니페스트는 Workbox에서 사용하는 형식으로 다음과 같습니다.
[{
url: 'app.abcd1234.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
서비스 워커가 설치되면 나열된 3개의 URL 각각에 대해 캐시 저장소에 세 개의 캐시 항목이 생성됩니다. 첫 번째 애셋의 버전 관리 정보는 URL에 이미 포함되어 있습니다 (app은 실제 파일 이름이고 .abcd1234에는 파일 확장자 .js 바로 앞에 버전 관리 정보가 포함되어 있음). Workbox의 빌드 도구는 이를 감지하고 버전 필드를 제외할 수 있습니다. 다른 두 애셋은 URL에 버전 관리 정보를 포함하지 않으므로 Workbox의 빌드 도구는 로컬 파일 콘텐츠의 해시가 포함된 별도의 revision 필드를 생성합니다.
사전 캐시된 리소스 제공
캐시에 애셋을 추가하는 것은 사전 캐싱 스토리의 일부일 뿐입니다. 애셋이 캐시되면 발신 요청에 응답해야 합니다. 이를 위해서는 서비스 워커에 사전 캐시된 URL을 확인하고, 프로세스에서 네트워크를 우회하여 캐시된 응답을 안정적으로 반환할 수 있는 fetch 이벤트 리스너가 필요합니다. 서비스 워커는 캐시에서 응답을 확인하고 네트워크보다 먼저 응답을 사용하므로 이를 캐시 우선 전략이라고 합니다.
효율적인 업데이트
사전 캐시 매니페스트는 예상 캐시 상태의 정확한 표현을 제공합니다. 매니페스트의 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의 빌드 도구는 사전 캐시 매니페스트의 항목 수와 사전 캐시 페이로드의 총 크기를 알려주므로 유용합니다.
웹 앱을 반복적으로 방문하는 사용자는 네트워크를 회피하는 기능을 제공하므로 시간이 지남에 따라 저장된 대역폭에서 빠르게 비용을 지불하므로 장기적으로는 사전 캐싱의 초기 비용 측면에서 이점을 얻을 수 있습니다.