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