◆ SERIES · 3 POSTS

Service Worker Caching Deep Dive

The third cache layer that did not fit in the caching chapter of Frontend Performance Optimization Deep Dive. From the general theory of proxies, lifecycles, and strategies to applying it to a Next.js blog and measuring it with GA4

README

The browser has three cache layers: the HTTP cache, the CDN cache, and the service worker cache. The first two got a full chapter in my book, but the last one was cut for length. This series pays off that debt.

It comes in three parts. Part 1 is the general theory: where a service worker sits in the request path and what lifecycle it lives through, what kind of storage Cache Storage is without a TTL, and what to base the choice among the five caching strategies on. Part 2 applies that theory to a real blog on the Next.js App Router. It goes through the traps set by soft navigation, prefetching, and next/image, and checks the change before and after deploying the service worker with real-user data from GA4. Part 3 measures the cost of going through the worker, which Part 2 left unresolved. After confirming why real-user data never produces a control group, it builds one directly with Playwright and a shaping proxy, and separates the shares of worker startup, navigation preload, and CPU speed.

Reading in order is recommended, but if you are already familiar with service workers, starting with the case study in Part 2 is fine.

03 ITEMS

All posts

in order

01

How Service Worker Caching Works: The Proxy, the Lifecycle, and Five Strategies

#service-worker#caching#browser

A service worker is a programmable proxy standing between your site and the network. Where does it stand, why does the cache rot, why am I seeing the old version after deploying, what goes in under which strategy, and so, should you use it? Holding on to five questions you actually meet in practice, this post goes down to the details of state transitions and to a real measurement in which a 104KB opaque response was accounted as 6.6MB of storage. It is the general theory that did not fit into the cache chapter of Frontend Performance Optimization Deep Dive (published in Korean), and the first post of the Service Worker Caching Deep Dive series.

2026-08-12Updated 2026-09-02
24 min · read

02

Applying Service Worker Caching: App Router Traps and GA4 Field Data

#service-worker#caching#nextjs

Armed with the theory from Part 1, I made this blog (Next.js App Router) open offline. On the first deploy, the post I had just read would not open offline; on the second, posts opened but every image was broken. This is a chronicle of fixing, one deploy at a time, the traps created by soft navigation, prefetching, and next/image, and a record of settling the results with GA4 real-user data. Returning-visitor FCP improved by 634ms on average, while TTFB worsened by 525ms on average. The second post of the Service Worker Caching Deep Dive series.

2026-08-27Updated 2026-09-02
27 min · read

03

Measuring the Cost of Going Through a Service Worker: Building in the Lab the Control Group GA4 Could Not Give Me

#service-worker#web-performance#caching

I set out to confirm the 500 ms hint that part 2 left behind, but the hard reloads that would form the control group arrive at under one a day. So I built the control group myself, with Playwright and a shaping proxy, and found that going through the worker costs 2 ms on a navigation, and that the cost is not latency but the bytes the worker fetches in the background on every click. The gap I had left between the lab and the field turned out, only after the post was written, to be a measurement definition difference created by 103 Early Hints. Third part of the service worker caching deep dive series.

2026-08-28Updated 2026-09-02
50 min · read