서비스 워커는 뛰어난 유틸리티를 제공하지만 처음에는 작업하기가 까다로울 수 있습니다. Workbox는 서비스 워커를 더 쉽게 사용할 수 있도록 해줍니다. 그러나 서비스 워커는 어려운 문제를 해결하므로 이를 이해하지 못하면 해당 기술을 추상화하기가 까다로울 수 있습니다. 따라서 처음 몇 분간의 문서에서는 Workbox의 세부사항에 대해 설명하기 전에 이러한 기본 기술을 다룹니다.
서비스 워커의 실행 목록을 보려면 주소 표시줄에 chrome://serviceworker-internals/를 입력합니다.
서비스 워커는 무엇을 제공하나요?
서비스 워커는 웹브라우저와 웹 서버 사이에서 프록시 역할을 하는 특수한 자바스크립트 애셋입니다. 오프라인 액세스를 제공하여 안정성을 개선하고 페이지 성능을 높이는 것을 목표로 합니다.
앱과 비슷한 수명 주기를 점진적으로 개선
서비스 워커는 기존 웹사이트를 개선한 기능입니다. 즉, 서비스 워커를 지원하지 않는 브라우저를 사용하는 사용자가 서비스 워커를 사용하는 웹사이트를 방문할 경우 기준 기능이 중단되지 않습니다. 이것이 바로 웹입니다.
서비스 워커는 플랫폼별 애플리케이션과 유사한 수명 주기를 통해 웹사이트를 점진적으로 개선합니다. 앱 스토어에서 네이티브 앱을 설치하면 어떤 일이 발생하는지 생각해 보세요.
- 애플리케이션 다운로드 요청이 접수되었습니다.
- 앱이 다운로드되고 설치됩니다.
- 앱을 사용할 준비가 되었으며 실행할 수 있습니다.
- 새 출시 버전의 앱이 업데이트됩니다.
서비스 워커 수명 주기는 비슷하지만 점진적인 개선 방식을 사용합니다. 새 서비스 워커를 설치하는 웹페이지를 처음 방문할 때 페이지를 처음 방문하면 서비스 워커가 다운로드되는 동안 기본 기능이 제공됩니다. 서비스 워커를 설치하고 활성화하면 개선된 안정성과 속도를 제공하도록 페이지를 제어합니다.
JavaScript 기반 캐싱 API 액세스
서비스 워커 기술의 필수적인 측면은 HTTP 캐시와 완전히 별개인 캐싱 메커니즘인 Cache 인터페이스입니다.
Cache 인터페이스는 서비스 워커 범위와 기본 스레드 범위 내에서 액세스할 수 있습니다.
이를 통해 Cache 인스턴스와의 사용자 주도 상호작용의 수많은 가능성이 열립니다.
HTTP 캐시는 HTTP 헤더에 지정된 캐싱 지시어의 영향을 받는 반면, Cache 인터페이스는 자바스크립트를 통해 프로그래밍할 수 있습니다.
즉, 네트워크 요청에 대한 응답 캐싱은 특정 웹사이트에 가장 적합한 로직을 기반으로 할 수 있습니다.
예를 들면 다음과 같습니다.
- 정적 애셋을 첫 번째 요청 시 캐시에 저장하고, 이후의 모든 요청에 대해서만 캐시에서 정적 애셋을 제공합니다.
- 페이지 마크업을 캐시에 저장하되 오프라인 시나리오에서만 캐시의 마크업을 제공합니다.
- 캐시의 특정 애셋에 대한 비활성 응답을 제공하되 백그라운드에서는 네트워크에서 업데이트합니다.
- 네트워크에서 일부 콘텐츠를 스트리밍하고 캐시에서 앱 셸과 결합하여 인지 성능을 개선합니다.
각각은 캐싱 전략의 예입니다. 캐싱 전략은 오프라인 환경을 가능하게 하며 지연 시간이 긴 재검증을 피함으로써 HTTP 캐시 시작 검사를 회피함으로써 더 나은 성능을 제공할 수 있습니다. Workbox를 살펴보기 전에 먼저 작동에 도움이 되는 몇 가지 캐싱 전략과 코드를 살펴보겠습니다.
비동기 이벤트 기반 API
네트워크를 통한 데이터 전송은 본질적으로 비동기식입니다. 애셋을 요청하고, 서버가 요청에 응답하고, 응답을 다운로드하는 데 시간이 걸립니다. 소요 시간은 다양하고 불확실합니다. 서비스 워커는 다음과 같은 이벤트에 콜백을 사용하여 이벤트 기반 API를 통해 이러한 비동기성을 수용합니다.
- 서비스 워커가 설치될 때
- 서비스 워커가 활성화 중일 때
- 서비스 워커가 네트워크 요청을 감지하는 경우
이벤트는 익숙한 addEventListener API를 사용하여 등록할 수 있습니다.
이러한 모든 이벤트는 잠재적으로 Cache 인터페이스와 상호작용할 수 있습니다.
특히 네트워크 요청이 전달될 때 콜백을 실행하는 기능은 추구하는 안정성과 속도를 제공하는 데 중요합니다.
자바스크립트에서 비동기 작업을 하려면 프로미스를 사용해야 합니다.
프로미스는 async 및 await도 뒷받침하므로 이러한 자바스크립트 기능을 사용하여 더 나은 개발자 환경을 위해 서비스 워커 (및 Workbox!) 코드를 단순화할 수도 있습니다.
사전 캐싱 및 런타임 캐싱
서비스 워커와 Cache 인스턴스 간의 상호작용에는 사전 캐싱과 런타임 캐싱이라는 두 가지 서로 다른 캐싱 개념이 포함됩니다.
이들 각각은 서비스 워커가 제공할 수 있는 이점의 핵심입니다.
사전 캐싱은 일반적으로 서비스 워커 설치 중에 애셋을 미리 캐시하는 프로세스입니다.
사전 캐싱을 사용하면 오프라인 액세스에 필요한 주요 정적 애셋과 자료를 다운로드하여 Cache 인스턴스에 저장할 수 있습니다.
이러한 유형의 캐싱은 또한 사전 캐시된 애셋이 필요한 후속 페이지의 페이지 속도를 개선합니다.
런타임 캐싱은 런타임 시 네트워크에서 요청될 때 자산에 캐싱 전략이 적용되는 경우입니다. 이러한 종류의 캐싱은 사용자가 이미 방문한 페이지 및 자산에 대한 오프라인 액세스를 보장하므로 유용합니다.
서비스 워커에서 Cache 인터페이스를 사용하는 이러한 접근 방식을 결합하면 사용자 환경에 엄청난 이점을 제공할 수 있으며 그 외의 일반적인 웹페이지에서는 앱과 유사한 동작을 제공할 수 있습니다.
기본 스레드에서 격리
자바스크립트 성능의 상태는 끊임없이 진화하고 있는 웹 문제이며, 사용자 관점에서 이 문제는 기기 기능과 고속 인터넷 액세스에 좌우됩니다. 자바스크립트를 많이 사용할수록 만족스러운 사용자 환경을 제공하는 빠른 웹사이트를 빌드하기가 더 어려워집니다.
서비스 워커가 수행하는 모든 작업은 자체 스레드에서 발생한다는 점에서 웹 워커와 유사합니다. 즉, 서비스 워커 태스크는 기본 스레드의 다른 태스크와 주의를 끌기 위해 경쟁하지 않습니다. 서비스 워커는 사용자 중심입니다!
앞으로 가야 할 길
이 문서는 개요에 불과합니다. Workbox에 대한 적절한 내용을 다루기 전에 서비스 워커에 관해 몇 가지 주제를 더 살펴봐야 합니다. 하지만 서비스 워커에 대해 확실히 이해하면 Workbox를 더 쉽고 생산적으로 사용할 수 있을 것입니다.