웹 작업자와 서비스 워커가 사이트 성능을 개선할 수 있는 방법과 웹 워커와 서비스 워커를 비교하는 경우
이 개요에서는 웹 워커와 서비스 워커가 웹사이트 성능을 개선할 수 있는 방법과 웹 워커와 서비스 워커를 함께 사용해야 하는 경우를 설명합니다. 이 시리즈의 나머지 부분에서 창 및 서비스 워커 통신의 특정 패턴을 확인하세요.
작업자가 웹사이트를 개선하는 방법
브라우저는 단일 스레드 (기본 스레드)를 사용하여 웹페이지의 모든 자바스크립트를 실행하고 페이지 렌더링 및 가비지 컬렉션 실행과 같은 작업을 실행합니다. 과도한 자바스크립트 코드를 실행하면 기본 스레드가 차단되어 브라우저에서 이러한 작업을 실행하지 못하며 사용자 환경이 저하될 수 있습니다.
iOS/Android 애플리케이션 개발에서 앱의 기본 스레드가 사용자 이벤트에 자유롭게 응답하도록 하는 일반적인 패턴은 작업을 추가 스레드로 오프로드하는 것입니다. 실제로 최신 버전의 Android에서는 기본 스레드를 너무 오래 차단하면 앱이 다운됩니다.
웹에서 JavaScript는 단일 스레드의 개념을 중심으로 설계되었으며 공유 메모리와 같이 앱에 있는 것과 같은 멀티스레딩 모델을 구현하는 데 필요한 기능이 없습니다.
이러한 제한에도 불구하고, worker를 사용하여 백그라운드 스레드에서 스크립트를 실행하면 웹에서도 유사한 패턴을 달성할 수 있습니다. 이렇게 하면 기본 스레드를 방해하지 않고 작업을 실행할 수 있습니다. 작업자는 공유 메모리 없이 별도의 스레드에서 실행되는 전체 JavaScript 범위입니다.
이 게시물에서는 두 가지 유형의 작업자 (웹 작업자와 서비스 작업자), 이들의 유사점과 차이점, 프로덕션 웹사이트에서 작업자를 사용하기 위한 가장 일반적인 패턴에 대해 알아봅니다.
웹 워커 및 서비스 워커
공통점
웹 워커와 서비스 워커는 웹사이트에서 사용할 수 있는 두 가지 유형의 작업자입니다. 이들의 공통점은 다음과 같습니다.
- 둘 다 보조 스레드에서 실행되므로 기본 스레드와 사용자 인터페이스를 차단하지 않고도 자바스크립트 코드를 실행할 수 있습니다.
- 이러한 클래스는
Window및Document객체에 액세스할 수 없으므로 DOM과 직접 상호작용할 수 없으며 브라우저 API 액세스가 제한됩니다.
차이점
웹 워커에 위임할 수 있는 대부분의 작업을 서비스 워커에서 수행할 수 있고 그 반대의 경우도 마찬가지라고 생각할 수 있지만 그중에는 중요한 차이점이 있습니다.
- 웹 워커와 달리 서비스 워커에서는
fetch이벤트를 통해 네트워크 요청을 가로채고push이벤트를 통해 백그라운드에서 Push API 이벤트를 수신 대기할 수 있습니다. - 페이지에 여러 웹 워커가 생성될 수 있지만 단일 서비스 워커는 등록된 범위 내에서 모든 활성 탭을 제어합니다.
- 웹 워커의 수명은 웹 워커가 속한 탭과 밀접하게 연결되어 있지만 서비스 워커의 수명 주기는 웹 워커와 별개입니다. 따라서 웹 워커가 실행 중인 탭을 닫으면 탭이 종료되지만, 사이트에 열려 있는 활성 탭이 없더라도 서비스 워커는 백그라운드에서 계속 실행될 수 있습니다.
사용 사례
두 작업자 유형 간의 차이를 보면 어떤 상황에서 어느 작업자를 사용해야 할지 알 수 있습니다.
웹 작업자 사용 사례는 UI 차단을 방지하기 위해 작업 (예: 많은 계산)을 보조 스레드로 오프로드하는 것과 더 관련이 있습니다.
- 예: 비디오 게임 PROXX를 빌드한 팀은 사용자 입력 및 애니메이션을 처리하기 위해 기본 스레드를 최대한 자유롭게 유지하고자 했습니다. 이를 위해 Octro는 웹 워커를 사용하여 별도의 스레드에서 게임 로직과 상태 유지관리를 실행했습니다.
서비스 워커 태스크는 일반적으로 네트워크 프록시 역할, 백그라운드 태스크 처리, 캐싱 및 오프라인 작업과 더 관련이 있습니다.
예: 팟캐스트 PWA에서는 사용자가 전체 에피소드를 다운로드하여 오프라인으로 들을 수 있도록 허용할 수 있습니다. 이를 위해 서비스 워커, 특히 Background Fetch API를 사용할 수 있습니다. 이렇게 하면 에피소드를 다운로드하는 동안 사용자가 탭을 닫을 때 작업을 중단할 필요가 없습니다.
도구 및 라이브러리
창 및 작업자 통신은 다양한 하위 수준 API를 사용하여 구현할 수 있습니다. 다행히도 이 프로세스를 추상화하는 라이브러리가 있어 가장 일반적인 사용 사례를 처리합니다. 이 섹션에서는 웹 워커와 서비스 워커에 대한 창을 각각 관리하는 두 가지 도구인 Comlink와 Workbox에 대해 설명합니다.
Comlink
Comlink는 웹 작업자를 사용하는 웹사이트를 빌드할 때 여러 기본 세부정보를 처리하는 소규모 (1.6k) RPC 라이브러리입니다. PROXX 및 Squoosh와 같은 웹사이트에서 사용되어 왔습니다. 이러한 동기와 코드 샘플의 요약은 여기에서 확인할 수 있습니다.
Workbox
Workbox는 서비스 워커를 사용하는 웹사이트를 빌드하는 데 널리 사용되는 라이브러리입니다. 캐싱, 오프라인, 백그라운드 동기화 등과 같은 권장사항 모음이 포함되어 있습니다. workbox-window 모듈은 서비스 워커와 페이지 간에 메시지를 교환할 수 있는 편리한 방법을 제공합니다.
다음 단계
이 시리즈의 나머지 부분에서는 기간 및 서비스 워커 통신 패턴에 중점을 둡니다.
- 명령적 캐싱 가이드: 페이지에서 서비스 워커를 호출하여 리소스를 미리 캐시 (예: 미리 가져오기 시나리오)
- 업데이트 브로드캐스트: 서비스 워커에서 페이지를 호출하여 중요한 업데이트 (예: 웹사이트의 새 버전 사용 가능)를 알립니다.
- 양방향 통신: 서비스 워커에 작업 위임(예: 대용량 다운로드) 및 진행 상황을 페이지에 계속 알림
창 및 웹 작업자 통신 패턴은 웹 작업자를 사용하여 브라우저의 기본 스레드에서 JavaScript 실행을 확인하세요.