Service Workers Are for Every Website — Not Just Apps 🌐

How This Course Began 🎯

Kyle didn't start learning service workers from a textbook. He built a real app — a restaurant note-taking app he wanted installed on his phone — using nothing but web technologies. No Java, no Swift, just the web stack he already knew.

That hands-on journey led him straight into the chaotic world of Googling scattered docs, piecing together MDN references, and trial-and-error coding. Sound familiar?

"The code we'll be going through today was done exactly that way — I set out with here's what I kind of want to build and I spent a lot of time fiddling with it."

That honesty alone made me feel better about my own confusion.

📚 Recommended Resources

Before diving in, Kyle flagged a few go-to references:

"Going Offline" by Jeremy Keith — Hands down the best book Kyle found on service workers. Highly recommended.
MDN Docs — Comprehensive reference material, but requires a lot of piecing together.
Google's write-ups — Useful but scattered.
Workbox — A framework/library for writing service workers declaratively (more on this below).

Two Paths: Workbox vs. Raw Service Workers 💡

There's an important fork in the road when getting started:

Workbox — A framework that lets you set up service workers declaratively with clean APIs. Great if you're shipping something at work fast and don't have time to explore deeply.
Raw Service Workers — What this course covers. More code, more complexity, but also fine-grained control and real understanding of what's happening under the hood.

Kyle went the raw route on purpose — he wanted to know what was actually possible, including things most tutorials never even mention. This course follows that same philosophy.

If you're trying to get something shipped quickly, Workbox is a great starting point. But if you want to truly understand service workers, raw is the way to go.

The Big Claim: Every Website Needs a Service Worker 🔥

Here's where things got interesting. Most resources frame service workers as a Progressive Web App thing — like they're only relevant if you're building the next Gmail.

Kyle pushes back hard on that:

"Literally every single website on the internet needs a service worker. The static one-pager someone wrote 20 years ago. The fancy Gmails of the world. Everything in between."

We get distracted by shiny web features — CSS Grid, retina images, fancy web fonts, SVG animations — and forget the base plumbing fundamentals of the web. Service workers are that plumbing.

The Real Problem: Browser Caching Is Not What You Think 🤔

We've always had a naive mental model of caching:

"It's in the cache → browser uses it. Not in the cache → browser fetches it."

That's not how it works. The actual decision tree inside a browser for handling cached requests is enormously complex. It's not binary. And because we've mentally filed caching under "the browser handles that," we've completely ignored it — and users are paying the price.

The Offline Story That Says It All ✈️

Kyle travels constantly — Lithuania, Australia, all over — mostly on 2G speeds (free roaming via T-Mobile, slow but usable). This gives him a front-row seat to how broken the web can be for most of the world.

Here's a scenario that perfectly captures the problem:

You're sitting in an airport. A tweet comes by with an interesting blog post.
You tap it, start reading the first few paragraphs.
They board the plane. You pocket your phone.
30,000 feet in the air, no Wi-Fi, airplane mode on.
You open that tab — blank white screen. Failed to load.

The content was right there before takeoff. Nothing changed on your end. But it's gone. (Likely culprit? A background ad request that failed and took the whole page with it.)

"There's a difference between tolerating a degraded experience and getting absolutely nothing."

The Flawed Assumption We've All Made 😬

We design the web as if users will always have:

✅ Perfect Wi-Fi
✅ Continuous connectivity
✅ Full battery
✅ No interruptions

But the reality for the vast majority of the world's web users is none of that. Spotty connections, airplane mode, 2G speeds, rural areas — this is normal.

The web was built assuming a perfect, contiguous experience. Service workers exist to fix that assumption.

It's Our Responsibility as Developers 🧑‍💻

This is where Kyle stops being descriptive and gets prescriptive. Throwing expires headers at the problem and calling it caching? Not good enough.

"It is our responsibility as the builder of a web experience to ensure that the person gets to continue to experience as much of that as possible, regardless of the conditions they may be in."

If a storm knocks out the cell towers, users shouldn't be completely lost. If Wi-Fi drops mid-session, they shouldn't hit a blank screen. Not every piece of dynamic data can be preserved — and that's okay — but the baseline experience should survive.

The Twitter Case Study 🐦

Kyle tweeted (ironically) about his frustration with Twitter's own PWA. He'd be scrolling his timeline, board a plane, open Twitter in airplane mode — and get a completely blank screen.

The response he got back from people online was telling:

"There's no possible way Twitter could cache the entire stream of billions of tweets!"

That's not what he asked for. This kind of all-or-nothing thinking is exactly what leads to poorly designed products. The actual ask was simple:

"Show me the hundred tweets before and the hundred tweets after what I was already looking at. Is that too much to ask?"

No laws of physics need to be broken. No impossible data downloads required. Just cache what the user already had — the content they were literally looking at moments ago.

The Offline Tweet Problem 😤

Here's another sharp edge Kyle pointed to — the case of sending a tweet on a bad connection:

You start composing a tweet while online.
By the time you hit send, you're on 2G or just went offline.
Twitter shows no error. The tweet just... vanishes.
Nobody saw it. No likes. No record of it. Gone.

The problem isn't just full offline — it's the grey zone of terrible connectivity. The request might have left your device but never reached the server. Or it never left at all. Either way, the user has no idea.

What should happen? Any number of reasonable alternatives:

Queue it — save the tweet locally and send it when connectivity returns.
Warn the user — "Your tweet didn't send, but it's saved. We'll retry."
Ask them — "You appear to be offline. Want us to send this later?"

Any of these would be better than silent failure. The point is someone needs to think about this.

What This Course Will Actually Cover 🗺️

The course isn't going to turn every website into an installable home screen app. That's not the goal. The goal is more practical:

Use service worker technology to improve experiences for users on any website — fully static, fully dynamic, or anywhere in between.

The demo used throughout the course is a simple blog-style site. The scenarios explored include:

Navigating previously seen blog posts while offline — you should always be able to get back to content you already loaded.
Handling dynamic content gracefully — not pretending it's there, but not failing silently either.
Slow connection strategies — because "offline" and "online" are just the two extremes of a very long spectrum.

Every product will have a slightly different answer to these questions. Service workers give you the tools to build your answer thoughtfully.

Key Takeaway 🎯

Service workers aren't a PWA-only feature. They're the missing infrastructure layer that every website needs — and implementing them well is a developer responsibility, not a browser responsibility.

The browser won't do this for you. Expires headers won't do this for you. You have to think about it, build for it, and test it.