Every website and web app should have a service worker

A service worker is a special type of JavaScript file that acts like middleware for your site.

Today, I want to talk about why every website and web app should have one. Let’s dig in!

What a service worker is

A service worker is a special JavaScript file that gets installed by a user’s web browser and saved locally.

Any request that comes from the site—and any response it gets back—first goes through the service worker file. Service workers also have access to a special cache where they can save responses and assets locally.

Together, these features allow you to…

• Serve frequently accessed assets from your local cache instead of the network, reducing data usage and improving performance.
• Provide access to critical information (or even your entire site or app) when the visitor goes offline.
• Prefetch important assets and API responses so they’re ready when the user needs them.
• Provide fallback assets in response to HTTP errors.

In short, service workers allow you to build faster and more resilient web experiences.

Unlike regular JavaScript files, service workers do not have access to the DOM. They also run on their own thread, and as a result don’t block other JavaScript from running. Service workers are designed to be fully asynchronous.

Service worker strategies

There are two main approaches for working with service workers…

1. With a network-first approach, you pass along requests to the network. If the request isn’t found, or there’s no network connectivity, you then look for the request in the service worker cache.
2. With an offline-first approach, you check for a requested asset in the service worker cache first. If it’s not found, you send the request to the network.

Network-first and offline-first approaches work in tandem. You will likely mix-and-match approaches depending on the type of asset being requested.

Offline-first is great for large assets that don’t change very often: CSS, JavaScript, images, and fonts. Network-first is best for frequently updated assets like HTML and API requests.

Why service workers are so awesome

I use service workers in a variety of ways on both my personal sites and client projects.

• I pre-cache critical or frequently used files for faster loading.
• I cache API calls for short periods of time to reduce network calls and speed up app performance.
• I load large assets locally instead of from the network.
• I provide fallback content when the network fails on a previously available piece of content.
• I cache previously visited pages so that users can access them offline.

I’ve worked with a lot of browser technology over the years. Service workers are pretty mind-blowing.

You can literally build fully offline apps with them, running just in the browser. It’s pretty amazing!

Getting started

If you want help implementing a service worker on your website or web app, get in touch!

I can help with everything from planning to strategy to implementation.

And if you’re more of the DIY type, I have a whole course on the technical aspects of working with service workers over at the Lean Web Club. Join for free today.