Saving Marp Slides from a Next.js App for Offline Use
From running the existing Marp viewer offline to fixing what deployments, networks, and the presenter window exposed along the way.
04 POSTS
Service-worker 1
◆ Service Worker Caching Deep Dive · Part 3Measuring the Cost of Going Through a Service Worker: Building in the Lab the Control Group GA4 Could Not Give Me
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.
◆ Service Worker Caching Deep Dive · Part 2Applying Service Worker Caching: App Router Traps and GA4 Field Data
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.
◆ Service Worker Caching Deep Dive · Part 1How Service Worker Caching Works: The Proxy, the Lifecycle, and Five Strategies
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.