I remember Jason telling me about this weird service worker caching behaviour a little while back. This piece is a great bit of sleuthing in tracking down the root causes of this strange issue, followed up with a sensible solution.
Stuart writes up the process up making a mobile game as a web app—not a native app. The Wordle effect reverberates.
It’s a web app. Works for everyone. And I thought it would be useful to explain why it is, why I think that’s the way to do things, and some of the interesting parts of building an app for everyone to play which is delivered over the web rather than via app stores and downloads.
This is a really excellent four-part series on web performance that really dives into the technical details and asks all the right questions:
The headline is a little misleading because if you follow this advice, your multi-page apps will be much much faster than single page apps, especially when you include that initial page load of a single page app.
Here’s a quick high-level summary of what I do…
That’s an excellent recipe for success right there!
It’s official. The extremely niche browser behaviour I documented is a bug.
So, why would you want to use a service worker? Here are some cool things you can do with it.
Chris lists some of the ways a service worker can enhance user experience.
I’m trying to understand why developers would trust third-party code more than a native browser feature.
Debugging an error message.
The browser equivalent of a Roman legion showing up in a space opera.
Kiss your service workers goodbye on iOS.
The h-entry microformat and the Cache API are a perfect pairing for offline pages.