서비스 워커의 한 가지 기능은 설치할 것입니다. 이를 '프리캐싱'이라고 합니다. 사전 캐싱을 사용하면 다른 페이지로 이동하지 않고도 캐시된 파일을 브라우저에 제공할 수 있으며, 네트워크에 연결합니다. 사이트에 필요한 중요 자산에 대해 사전 캐싱 사용 오프라인일 때: 기본 페이지, 스타일, 대체 이미지 및 필수 스크립트
Workbox를 사용해야 하는 이유는 무엇인가요?
사전 캐싱에 Workbox를 사용하는 것은 선택사항입니다. 자체 코드를 작성하여 서비스 워커를 설치할 때 중요한 애셋을 사전 캐시합니다. Workbox를 사용할 때의 주요 이점은 즉시 사용할 수 있는 버전 제어입니다. Workbox를 사용하면 사전 캐시된 애셋을 업데이트하는 데 이러한 파일의 버전 관리 및 업데이트를 직접 관리해야 하는 경우에 유용합니다.
매니페스트 사전 캐시
프리캐싱은 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 필드를 생성합니다.
할 수 있습니다.
사전 캐시된 리소스 제공
캐시에 자산을 추가하는 것은 사전 캐싱 스토리의 일부일 뿐입니다.
나가는 요청에 응답해야 합니다. 이를 위해서는
서비스 워커의 fetch 이벤트 리스너로, 어떤 URL에 포함되었는지 확인할 수 있습니다.
사전 캐시되고 캐시된 응답을 안정적으로 반환하여
네트워크를 형성하기도 합니다. 서비스 워커는 캐시의 응답을 확인하고
(네트워크 이전에 사용) 이것을
캐시 우선 전략을 따라야 합니다.
효율적인 업데이트
사전 캐시 매니페스트는 예상 캐시의 정확한 표현을 제공합니다. state; 매니페스트의 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을 사용자가 각 사이트를 방문할 때까지 기다릴 필요 없이 미리 볼 수 있습니다. 개별 보기를 선택합니다.
사용자는 앱을 설치할 때 모든 부분이 빠르게 표시되기를 기대합니다. 이전에 봤던 견해뿐만 아니라 사전 캐싱은 웹 앱에 도입하는 것입니다.
어떤 애셋을 사전 캐시해야 하나요?
이미지의 로드 가이드를 검토하여 사전 캐시하기에 가장 적합한 URL을 파악할 수 있습니다. 일반적인 규칙은 초기에 로드되는 모든 HTML, JavaScript 또는 CSS를 사전 캐시하고 특정 페이지의 기본 구조를 표시합니다.
나중에 로드되는 미디어 또는 기타 애셋을 사전 캐싱하지 않는 것이 좋습니다. (웹 앱의 기능에 중요하지 않은 경우) 대신 runtime 캐싱 전략을 사용하여 사용하는 만큼만 애셋이 캐시됩니다.
사전 캐싱에는 네트워크 대역폭 및 스토리지 사용이 포함됨을 항상 명심하세요 앱 스토어에서 앱을 설치하는 것과 같습니다. 신중하게 사전 캐시하고 과다한 양상을 피하는 것은 개발자의 몫입니다. 사전 캐시 매니페스트를 참조하세요
Workbox의 빌드 도구는 사전 캐시에 있는 항목 수를 알려줍니다. 사전 캐시 페이로드의 총 크기도 지정할 수 있습니다.
웹 앱을 반복적으로 방문하는 사용자는 초기 투자 비용이 왜냐하면 네트워크를 회피하는 능력이 제공하는 것은 자동으로 백업됩니다.