Application Shells and Service Workers: Introduction
Application Shells and Service Workers #
We’ll work through the process of manually adding a service worker without tools or web components. We will then look at building a progressive web application using service workers, sw-toolbox and sw-precache. As we go along we’ll touch on diverse subjects such as:
- Offline as progressive enhancement
- Speed still matters
- Different cache strategies for Service Workers
- Service worker web components
- Progressive Web Applications
what's a service worker #
To start I’ll provide two different definition of what a Service Worker is and then we’ll draw some comparisons and a more detailed definition.
A service worker is a script that is run by your browser in the background, separate from a web page, opening the door to features which don't need a web page or user interaction. Today, they already include features like push notifications and in the future it will include other things like, background sync, or geofencing. The core feature discussed in this tutorial is the ability to intercept and handle network requests, including programmatically managing a cache of responses.
From the ServiceWorker specification:
Service workers are generic, event-driven, time-limited script contexts that run at an origin. These properties make them natural endpoints for a range of runtime services that may outlive the context of a particular document, e.g. handling push notifications, background data synchronization, responding to resource requests from other origins, or receiving centralized updates to expensive-to-calculate data (e.g., geolocation or gyroscope)
Service workers are a type of web workers that support features that don’t require active web pages or user interaction. Their current main use is to provide content caching and offline access and, in the future, will support additional features like Push Notification, Background Sync, Geofencing and others.
Service workers treat you like an adult (in the words of Jake Archibald) by not making any assumptions about what you want to do or how do you want to accomplish it as there are no default ServiceWorker settings or functions. This makes Service Workers harder to learn and to work well with but they make developers responsible for their code.
Why Service Workers? #
Service Workers make the web closer to native apps in a mobile device. Until Service Workers appeared we couldn’t do anything offline and the experience in mobile was fully dependent on the network. If the network died we were relegated to play the dinosaur game when using Chrome or hoping our network would return soon if working on other browsers.
Second and subsequent visits to a page under ServiceWorker control will load faster because all the content that hasn’t changed will be served from the local cache rather than the network. In order to update the cache with new content we only need to change 1 character in the ServiceWorker, this will trigger the new version of the worker and update the content as needed.
For an introduction to ServiceWorker see the video from a presentation by Jake Archibald for SFHTML5’s Perf Like a Pirate, 2014