◆ SERIES · 3 POSTS

서비스 워커 캐싱 딥다이브

『프런트엔드 성능 최적화 Deep Dive』의 캐시 장에서 못 다한 세 번째 캐시 레이어. 프록시와 라이프사이클과 전략의 일반론부터, Next.js 블로그에 직접 적용하고 GA4로 실측한 기록까지

README

브라우저 캐시에는 세 레이어가 있다. HTTP 캐시, CDN 캐시, 그리고 서비스 워커 캐시다. 앞의 둘은 책에서 한 장에 걸쳐 다뤘지만, 마지막 하나는 분량 때문에 끝내 싣지 못했다. 이 시리즈는 그 빚을 갚는 기록이다.

세 편으로 나뉜다. 1편은 일반론으로, 서비스 워커가 요청 경로 어디에 서고 어떤 수명을 살며, TTL 없는 Cache Storage는 어떤 성질의 저장소이고, 다섯 가지 캐싱 전략은 무엇을 기준으로 고르는지를 다룬다. 2편은 그 일반론을 Next.js App Router 위의 실제 블로그에 적용한 기록이다. 소프트 내비게이션과 프리페치, next/image가 만드는 함정들을 지나, 서비스 워커 배포 전후의 변화를 GA4 실사용자 데이터로 확인한다. 3편은 2편이 미해결로 남긴 워커 경유 비용을 재는 기록이다. 실사용자 데이터에서 대조군이 생기지 않는 이유를 확인한 뒤, Playwright와 셰이핑 프록시로 대조군을 직접 만들어 워커 기동, navigation preload, CPU 속도의 몫을 나눠 잰다.

순서대로 읽는 것을 권하지만, 서비스 워커가 익숙하다면 2편의 적용기부터 읽어도 무리는 없다.

03 ITEMS

전체 글

in order

01

서비스 워커 캐싱의 동작 원리: 프록시, 라이프사이클, 다섯 가지 전략

#web-performance#service-worker#pwa

서비스 워커는 사이트와 네트워크 사이에 선 프로그래밍 가능한 프록시다. 어디에 서 있는가, 캐시는 왜 썩는가, 배포했는데 왜 옛 버전이 보이는가, 무엇을 어떤 전략으로 담는가, 그래서 이걸 써야 하는가. 실무에서 마주치는 다섯 개의 질문을 붙잡고, opaque 응답이 104KB에서 6.6MB로 집계되는 실측과 상태 전이의 세부까지 내려간다. 『프런트엔드 성능 최적화 Deep Dive』의 캐시 장에서 못 다한 일반론이다. 서비스 워커 캐싱 딥다이브 시리즈의 첫 편이다.

2026-08-1239분 · read

02

서비스 워커 캐싱 적용기: App Router의 함정들과 GA4 실측

#web-performance#service-worker#pwa

1편의 일반론을 들고 이 블로그(Next.js App Router)를 오프라인에서도 열리게 만들었다. 첫 배포에서는 방금 읽은 글이 오프라인에서 안 열렸고, 두 번째 배포에서는 글은 열리는데 이미지가 전부 깨졌다. 소프트 내비게이션과 프리페치, next/image가 만든 함정들을 하나씩 고쳐 배포한 연대기와, 그 결과를 GA4 실사용자 데이터로 정산한 기록이다. 재방문자 FCP는 평균 634ms 좋아졌고, TTFB는 평균 525ms 나빠졌다. 서비스 워커 캐싱 딥다이브 시리즈의 두 번째 편이다.

2026-08-2747분 · read

03

서비스 워커 경유 비용 실측: GA4가 답하지 못한 대조군을 랩에서 만들기

#web-performance#service-worker#pwa

2편 끝에 남긴 "워커 경유 비용 500ms"를 확정하려 했지만, 대조군이 되는 하드 리로드는 하루 한 건이 안 됐다. 그래서 Playwright와 셰이핑 프록시로 대조군을 직접 만들어 재 보니 내비게이션에서 워커 비용은 2ms였고, 비용은 지연이 아니라 글 하나를 클릭할 때마다 배경에서 더 받는 바이트 쪽에 있었다. 랩과 실사용자 데이터 사이에 남겨 둔 간극은 글을 다 쓰고 나서야 103 Early Hints가 만든 측정 정의 차이였다는 것을 알았다. 서비스 워커 캐싱 딥다이브 시리즈의 세 번째 편이다.

2026-08-2881분 · read