서비스 워커는 웹사이트가 오프라인으로 작동하고 자체적으로 특수한 캐싱 규칙을 만들 수 있는 강력한 도구입니다. 서비스 워커 fetch 핸들러는 제어되는 페이지의 모든 요청을 확인하고 서비스 워커 캐시에서 응답을 제공할지, 아니면 로컬 사용자 환경설정에 따라 완전히 다른 응답을 가져오도록 URL을 재작성할 수도 있습니다.
그러나 한동안 페이지가 처음으로 로드되고 제어 중인 서비스 워커가 현재 실행되고 있지 않으면 서비스 워커에 성능 비용이 발생할 수 있습니다. 모든 가져오기는 서비스 워커를 통해 이루어져야 하므로 브라우저는 서비스 워커가 시작되고 실행될 때까지 기다렸다가 로드할 콘텐츠를 파악해야 합니다. 이 시작 비용은 작지만 서비스 워커를 사용하는 개발자가 캐싱 전략을 통해 성능을 개선하는데 큰 도움이 될 수 있습니다.
탐색 미리 로드는 문제를 해결하기 위한 한 가지 접근 방식(서비스 워커 시작과 동시에 네트워크를 통해 탐색 요청을 할 수 있도록 함)이지만 초기 탐색 요청으로 제한되며 여전히 중요한 경로에 서비스 워커를 포함합니다. 탐색 미리 로드가 출시된 이후 서비스 워커 시작 시 일부 요청이 전혀 차단되지 않는 방법을 포함하여 문제 공간에 관한 보다 일반적인 솔루션을 개발하기 위해 여러 가지 노력을 기울였습니다.
Service Worker Static Routing API
Chrome 116부터 이러한 솔루션의 첫 단계를 테스트하는 데 실험용 Service Worker Static Routing API를 사용할 수 있습니다. 서비스 워커가 설치되면 Service Worker Static Routing 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 Pattern 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 Static Routing API 사용해 보기
Service Worker Static Routing API는 오리진 트라이얼 뒤에 버전 116부터 Chrome에서 사용할 수 있습니다. 이 API를 사용하면 개발자가 실제 사용자를 통해 사이트에서 API를 테스트하여 효과를 측정할 수 있습니다. 오리진 트라이얼의 배경 정보는 '오리진 트라이얼 시작하기'를 참고하세요.
로컬 테스트의 경우 chrome://flags/#service-worker-static-router에서 플래그를 사용하거나 --enable-features=ServiceWorkerStaticRouter와 같은 명령어에서 Chrome을 실행하여 Service Worker Static Routing API를 사용 설정할 수 있습니다.
의견 및 향후 경로
Service Worker Static Routing API는 활발히 개발 중이며 아직 발전 중입니다. 도움이 될 것 같다면 오리진 트라이얼을 통해 사용해 보고 API, 구현, 사용 가능한 기능에 대한 의견을 제공해 주세요.