Enabling Offline First Experiences on the Web with Service Workers

Dan Zajdband
Sep 12, 2016 · 5 min read

During the first Offline Camp I had the pleasure to share a weekend with about 30 great people to talk about the Offline First community and movement.

As usual, the technical problem on how to provide users with access to relevant information when connectivity is limited or non-existent is part of a bigger “human” problem with social and economic components. In this article I’m going to focus on a technical aspect—the approach that the web ecosystem takes to the connectivity issue.

Image for post
Image for post
My offline first editing device

How did we get here?

Since its beginning, the web has provided a simple solution for storing website information into the user machine to access it later, even in an offline situation. It’s called “Save Page As….” Websites are basically HTML documents, so you can just download them as the browser does for you every time you access a URL. You can even download all the assets the website is accessing.

So, why are we talking today about fancy technologies? There are some reasons why this initial solution is not ideal:

  • The user needs to explicitly save the content.
  • If the user accesses the same resource again after the content changes, the offline version will be the old one unless the user saves an updated version.
  • Single-page applications inject HTML dynamically so this technique won’t work. (Sad but true.)

Application Cache

I don’t want to focus too much on an almost dead web standard, but the Application Cache (AppCache) was included in HTML5 as the first attempt by browser vendors to enable developers to offer an offline experience to their users. The approach that AppCache takes is for developers to define a manifest file describing the necessary files to make offline browsing possible, as well as fallback files for this situation. A natural advantage of this approach is that we as web developers have tools to shape this offline experience.

AppCache proved confusing to web developers and surfaced some important issues. This led the technology to be replaced by the brand new Service Workers specification. Among the difficulties people have found in working with AppCache are:

  • Cached files are always retrieved from the filesystem, even if the user is online, making it hard to update them.
  • Cached files are only updated if the manifest is updated.
  • Non-cached resources won’t load on a “non-cached” page, even if we are offline.

Service Workers

Service Workers offer three features in particular that I think are the most important to provide offline experiences to our users:

  • The Cache API gives us access to the creation and management of versioned caches, allowing us to save resources on the user’s file system. This is useful for both offline and online scenarios. If we store a resource in the cache then we can return it from the local file system and prevent an extra round trip request and response to and from the server.
  • The Service Worker has access to app lifecycle events. We can take advantage of these events to clean caches, preload and save critical resources. More importantly, we can get a trigger every time a resource is about to be fetched from the web. Inside a Service Worker we have the ability to get the resource from a cache, return a completely new response, or, for example, retrieve the resource from the network and store the result in a Cache before returning it. This is very important for scenarios with limited connectivity since we are in control of the experience every time.
  • We as developers are now allowed to ask for Background Syncs. The idea is that we can request that the browser try to sync our local data with the server. If there is no connection or we are on the subway then the browser will try to sync later, when we get a better connection. This is important in particular for local databases and multi-user apps.

Tooling

Examples

A note on Lie-Fi

Conclusion

Editor’s Note: This article is part of series of unconference session recaps submitted by the awesome folks who participated in our first ever Offline Camp, a unique tech retreat that brings together the Offline First community. You can find more coverage of our initial discussions in our Medium publication. To continue the conversation, join us at our next event or sign up for updates and cast your vote on where we should host future editions of Offline Camp.

Offline Camp

Building the Offline First community, one campfire at a…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store