Worker 라이프사이클

Web Worker와 Service Worker 역할

Worker를 성능 향상 기술로만 묶으면 실행 위치와 수명 주기 차이가 가려진다. Web Worker는 메인 스레드 밖에서 계산을 하고 structured clone으로 메시지를 주고받으며, Service Worker는 페이지와 네트워크 사이에서 install, activate, fetch, cache 흐름을 가진다.

01

문제 분류

UI가 멈추는 계산 문제인지, 오프라인과 캐시 문제인지 먼저 나눈다.

둘은 이름만 비슷하고 역할은 다르다
02

Web Worker 연결

긴 계산을 worker로 보내고 postMessage와 message 이벤트로 결과를 받는다.

DOM은 worker에서 직접 만질 수 없다
03

데이터 전달 확인

structured clone으로 복사 가능한 값인지, Transferable을 쓸 수 있는지 본다.

큰 데이터 복사는 비용이 된다
04

Service Worker 수명 주기

install에서 캐시 준비, activate에서 이전 캐시 정리, fetch에서 응답 전략을 적용한다.

새 버전이 즉시 제어하지 않을 수 있다
05

캐시 실패 처리

네트워크 실패, 오래된 캐시, 업데이트 레이스, skipWaiting 사용 여부를 테스트한다.

오프라인 성공보다 갱신 실패가 더 위험하다
Web Worker
메인 스레드 보호 파싱, 압축, 이미지 처리처럼 긴 CPU 작업을 분리한다.
결과 반영은 메인 스레드에서 한다
Service Worker
네트워크 프록시 fetch 요청을 가로채 캐시, 오프라인, background sync 전략을 둔다.
HTTPS와 scope 설정을 확인한다
Structured Clone
메시지 복사 함수나 DOM node는 전달할 수 없고 큰 객체 복사는 비용이 든다.
ArrayBuffer는 transfer를 고려한다
Lifecycle
설치와 갱신 install, waiting, activate, controllerchange를 이해해야 업데이트 UX를 설계한다.
사용자가 오래된 SW에 묶일 수 있다

Worker 확인

UI 멈춤 긴 작업 중 메인 스레드 프레임이 유지되는지 Performance 패널로 본다.
오프라인 네트워크를 끊고 Service Worker 캐시 전략이 의도대로 응답하는지 확인한다.
업데이트 새 Service Worker 배포 뒤 이전 캐시와 새 캐시가 충돌하지 않는지 본다.