서비스 워커는 웹사이트가 오프라인으로 작동하고 자체적으로 특수 캐싱 규칙을 만들 수 있는 강력한 도구입니다. 서비스 워커 fetch 핸들러는 제어하는 페이지의 모든 요청을 확인하고 서비스 워커 캐시에서 응답을 제공할지 결정하거나 URL을 재작성하여 완전히 다른 응답을 가져올 수도 있습니다(예: 로컬 사용자 환경설정에 따라).
그러나 페이지가 한동안 처음으로 로드되고 제어 서비스 워커가 현재 실행되고 있지 않은 경우 서비스 워커에 성능 비용이 발생할 수 있습니다. 모든 가져오기는 서비스 워커를 통해 이루어져야 하므로 브라우저는 서비스 워커가 시작되고 실행될 때까지 기다려야 로드할 콘텐츠를 알 수 있습니다. 이 시작 비용은 서비스 워커를 사용하여 캐싱 전략을 통해 성능을 개선하는 개발자에게는 작지만 중요할 수 있습니다.
탐색 미리 로드는 이 문제를 해결하는 한 가지 방법으로, 서비스 워커 시작과 동시에 네트워크를 통해 탐색 요청을 할 수 있도록 허용합니다. 하지만 초기 탐색 요청으로 제한되며 여전히 중요한 경로에 서비스 워커가 포함됩니다. 탐색 미리 로드가 출시된 이후 서비스 워커 시작 시 일부 요청이 전혀 차단되지 않는 방법을 비롯하여 문제 영역에 대한 보다 일반적인 솔루션을 개발하기 위한 여러 노력이 있었습니다.
Service Worker 정적 라우팅 API
Chrome 116부터 이러한 솔루션의 첫 번째 단계를 테스트하는 데 실험용 Service Worker Static Routing API를 사용할 수 있습니다. 서비스 워커가 설치되면 서비스 워커 정적 라우팅 API를 사용하여 특정 리소스 경로를 가져오는 방법을 선언적으로 지정할 수 있습니다.
API의 초기 버전에서는 경로가 항상 서비스 워커가 아닌 네트워크에서 제공되도록 선언할 수 있습니다. 나중에 제어된 URL이 로드되면 브라우저는 서비스 워커가 시작을 완료하기 전에 이러한 경로에서 리소스 가져오기를 시작할 수 있습니다. 이렇게 하면 서비스 워커가 필요하지 않은 것으로 확인된 경로에서 서비스 워커가 삭제됩니다.
API를 사용하기 위해 서비스 워커는 일련의 규칙을 사용하여 install 이벤트에서 event.registerRouter를 호출합니다.
self.addEventListener('install', event => {
if (event.registerRouter) {
// Go straight to the network and bypass invoking "fetch" handlers for all
// same-origin URLs that start with '/form/'.
event.registerRouter([{
condition: {
urlPattern: {pathname: '/form/*'},
},
source: 'network',
}]);
}
});
일반적으로 각 규칙에는 두 가지 속성이 있습니다.
condition: URL 패턴 API를 사용하여 리소스 경로를 일치시키는 규칙이 적용되는 시점을 지정합니다. 이 속성은URLPattern인스턴스 또는URLPattern생성자에 전달될 수 있는 등가의 일반 객체(예:new URLPattern({pathname: '*.jpg'})또는{pathname: '*.jpg'})를 사용할 수 있습니다.URL 패턴의 유연성은 규칙이 경로 아래의 리소스와 같이 간단한 항목을 매우 구체적이고 상세한 조건과 일치시킬 수 있음을 의미합니다. 일반적으로 널리 사용되는 라우팅 라이브러리의 사용자는 이 패턴을 잘 알고 있습니다.
source:condition와 일치하는 리소스를 로드하는 방법을 지정합니다. 현재'network'값만 지원되며 (서비스 워커를 우회하여 네트워크를 통해 리소스를 직접 로드함) 향후 다른 값으로 확장할 계획입니다.
사용 사례
설명한 대로 API의 초기 버전은 기본적으로 일부 경로의 서비스 워커 제어에서 탈출하는 해치입니다. 이를 사용하는 것이 적절한 경우는 서비스 워커를 사용하는 방식과 사용자가 사이트를 탐색하는 방식에 따라 달라집니다.
예를 들어 사이트에서 캐시 우선 전략(네트워크로 대체)을 사용하지만 방문 빈도가 너무 낮아 캐시를 치는 것이 거의 또는 전혀 가치가 없는 콘텐츠 (예: 보관처리된 콘텐츠 또는 RSS 피드)가 있을 수 있습니다. 네트워크에서 가져올 경로를 제한하는 것은 서비스 워커에서만 설정할 수 있지만, 서비스 워커는 이러한 요청을 처리하는 방법을 결정하기 위해 여전히 시작되고 실행되어야 합니다.
반면 정적 라우팅 API는 몇 줄의 선언으로 서비스 워커를 완전히 우회합니다.
self.addEventListener('install', event => {
if (event.registerRouter) {
event.registerRouter([{
condition: {
urlPattern: {pathname: '/feeds/*.xml'},
},
source: 'network',
}, {
condition: {
urlPattern: {pathname: '/archives/*'},
},
source: 'network',
}]);
}
});
Service Worker Static Routing API가 발전함에 따라 이 구성은 더 유연해지고 네트워크 가져오기와 서비스 워커 시작을 선언적으로 경합하는 등 더 많은 시나리오를 지원할 계획입니다. 자세한 내용은 API의 잠재적인 '최종 형식'에 관한 사양 설명을 참고하세요.
Service Worker 정적 라우팅 API 사용해 보기
서비스 워커 정적 라우팅 API는 Chrome 버전 116부터 오리진 트라이얼을 통해 사용할 수 있습니다. 이를 통해 개발자는 사이트에서 실제 사용자를 대상으로 API를 테스트하여 효과를 측정할 수 있습니다. 출처 무료 체험에 관한 배경 정보는 '출처 무료 체험 시작하기'를 참고하세요.
로컬 테스트의 경우 Service Worker Static Routing API는 chrome://flags/#service-worker-static-router의 플래그를 사용하거나 --enable-features=ServiceWorkerStaticRouter와 같이 명령어에서 Chrome을 실행하여 사용 설정할 수 있습니다.
의견 및 향후 방향
Service Worker Static Routing API는 현재 활발하게 개발 중이며 아직 완성되지 않았습니다. 유용하다고 생각되면 시작 체험판을 통해 사용해 보고 API, 구현, 사용 가능한 기능에 관한 의견을 제공해 주세요.