A second effect of this mobility is the slow loading of heavy websites: Amazon found that just 100 milliseconds of extra load time cost them 1% of sales.
In these situations, we would like to have offline access to our content.
That’s why tools like Instapaper and Pocket exist.
Spotify and Netflix also allow you to download media for offline use.
We can easily see there is a demand for this feature and how it can benefit your business.
It is time for the web to go offline.
Luckily we don’t need to build native apps to achieve this goal anymore.
For offline uses, one of their goals is to store network requests or images in the browser cache.
The agency BETC made a demo website called whentheinternetisdown.
com for the french telecom company Bouygues.
It only works offline and feels kind of magical.
Go try it out :)It’s the caching that makes the magic of the site: you can come back in 3 weeks, 1 month, 1 year, still without a connection, and access all the content.
— Maxime Huygue, Head of BETC Digital StudioOk this is cool, tell me how to do it then.
Ok, let’s begin with some prerequisites:In order to use SWs, you must enable https on your website.
SWs works in all modern browsers except our friend IE.
Which means: no DOM, and run outside of the main thread.
Understand how databases operate.
jsService workers lifecycleTo be able to work, SWs must be registered within your application, then installed.
You should check if SWs are compatible with your client before doing so.
1) RegistrationIf available, register your SW file.
It will return a promise, so you can handle errors.
You can also specify a scope of urls in the registration options.
2) InstallationService workers are event-based.
Briefly, you have to attach callbacks to events, as you would do with an element.
The first event you need to use is the install event.
The returned promise needs to be wrapped into event.
waitUntil(), which will delay the installation of the service worker until the promise is resolved.
Otherwise, the install event fails and the service worker will be discarded.
Please be cautious with caching: your user’s storage is precious, so don’t abuse it.
Also, be careful: the install event can only be called once, and you’ll need to update your SW to modify it.
3) ActivationThis one is a bit subtle.
Once the installation has completed, the service worker isn’t active yet: we are in the installed state.
In this state, it waits to take control of the page.
It then moves on to the next phase in the lifecycle, which is the activation phase.
The activation phase is handy when you update a SW.
The most common case is to clear the cache of the previous SW installed.
Please note that, once successfully installed, the updated worker will wait until the existing worker is controlling zero clients (clients overlap during a refresh).
skipWaiting() prevents the waiting, meaning the service worker activates as soon as it’s finished installing.
The advantage of this method is that you can receive fetch events faster.
It doesn’t really matter when you call skipWaiting(), as long as it’s during or before waiting.
It’s pretty common to call it in the install event.
We explored the SW Lifecycle: registration, installation, activationWe learned how to implement common uses cases such as: caching resources and clearing caches with the Cache API.
We saw that self.
skipWaiting and self.
claim allow us to activate SWs faster in order to catch events faster.
Ok moving right along…4) FetchThe fetch event allows us to intercept network requests and store responses or customize them.
The main advantage of this hook is to return the cached resources instead of making a request call.
You should take a look at the Fetch API for handling your request calls.
We can’t cover all the possibilities offered by service workers in one article.
Still, I encourage you to look into what’s possible: Custom 404, Background Sync API for offline analytics, ServiceWorker-side templating….
the future looks exciting!So far we’ve seen what a service worker is, how it works through its lifecycle, and the most common use cases by playing with Cache and Fetch API.
Those two APIs give us a whole new way of managing URL addressable resources in the browser.
To complete this guide, let see how we can store other types of data, for example a user’s JSON from your database.
Store custom data with IndexedDBA general guideline for data storage is that URL addressable resources should be stored with the Cache interface, and other data should be stored with IndexedDB.
For example HTML, CSS, and JS files should be stored in the cache, while JSON data should be stored in IndexedDB.
Note that this is only a guideline, not a firm rule.
(source)In short, we will see when you shouldn’t use Cache API but IndexedDB instead.
Both are asynchronous and accessible in service workers, web workers, and the window interface .
The good news is that it is well supported, even in recent versions of IE.
IndexedDB is a NoSQL database.
IndexedDB data are stored as key-value pairs in object stores rather than tables.
A single database can contain any number of object stores.
Whenever a value is stored in an object store, it is associated with a key.
It looks like this:Pretty classic, right?.The main thing to understand is the concept of key path.
It tells the browser which key to use to extract data from in the object store or index.
In this snippet, helpers libraries are used, see https://developers.
com/web/ilt/pwa/live-data-in-the-service-worker for detailsIn this example, we can see that our key path is the property id, and it is defined in line 10.
Then we return all the items from the database.
This is a very basic use case, so if you want to learn more about how IndexedDB works, I advise you to read this excellent article.
ConclusionTaking advantage of the offline web is great for the user experience, and some companies have started to take loot at it.
We’ve seen how to use them trough the service worker lifecycle and what you can do by using the Cache and Fetch API.
The possibilities are almost limitless.
so be creative and not too greedy on the device storage.
You can even use databases offline: that what’s IndexedDB is made for.
These offline capabilities certainly are part of the future of the web, so it plays well with the new type of websites that Google are creating: Progressive Web Apps.
Further reading:The Offline Cookbook: https://developers.
com/web/fundamentals/instant-and-offline/offline-cookbook/PWA and offline: https://developers.
com/web/ilt/pwa/lab-offline-quickstartLab: Caching Files with Service Worker: https://developers.
com/web/ilt/pwa/lab-caching-files-with-service-workerThe Service Worker Lifecycle: https://developers.
com/web/fundamentals/primers/service-workers/lifecycleDemystifying The Service Worker Lifecycle: https://scotch.
io/tutorials/demystifying-the-service-worker-lifecycleActivate Service Workers Faster: https://davidwalsh.
name/service-worker-claimLive Data in the Service Worker: https://developers.
com/web/ilt/pwa/live-data-in-the-service-workerIndexedDB Basic concepts: https://developer.
org/en-US/docs/Web/API/IndexedDB_API/Basic_Concepts_Behind_IndexedDBGetting Started with Persistent Offline Storage with IndexedDB: https://itnext.