서비스 워커의 한 가지 기능은 서비스 워커를 설치할 때 캐시에 파일을 저장할 수 있는 기능입니다. 이를 '프리캐싱'이라고 합니다. 사전 캐싱을 사용하면 네트워크로 이동하지 않고도 캐시된 파일을 브라우저에 제공할 수 있습니다. 오프라인일 때도 사이트에 필요한 중요 애셋(기본 페이지, 스타일, 대체 이미지, 필수 스크립트)에 사전 캐싱을 사용합니다.
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이 추가 또는 삭제된 경우 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, 자바스크립트 또는 CSS를 사전 캐시하는 것입니다.
미디어 또는 나중에 로드되는 기타 애셋은 미리 캐시하지 않는 것이 좋습니다(웹 앱 기능에 중요하지 않은 경우 제외). 대신 런타임 캐싱 전략을 사용하여 이러한 애셋이 사용되는 만큼 캐시되도록 하세요.
앱 스토어에서 앱을 설치하는 것과 마찬가지로 사전 캐싱을 위해서는 사용자 기기의 네트워크 대역폭과 저장용량을 사용해야 합니다. 개발자는 현명하게 사전 캐시하고 지나치게 커진 사전 캐시 매니페스트를 피하는 것이 개발자의 몫입니다.
Workbox의 빌드 도구를 사용하면 사전 캐시 매니페스트의 항목 수와 사전 캐시 페이로드의 총 크기를 알 수 있습니다.
웹 앱을 반복적으로 방문하는 사용자는 프리캐싱에 드는 초기 비용의 이점을 누리게 됩니다. 네트워크 회피 기능을 통해 시간이 지남에 따라 절약된 대역폭으로 비용을 신속하게 지불하기 때문입니다.