Apart from the obvious use case of returning cat pictures to every image request, we have found developers mainly use service workers primarily for 2 tasks.
Service workers have mostly been associated with offline support for web applications and for push notifications for re-engaging with users. There are pretty good drop-in wrapper libraries like sw-precache that you use to get such functionality without directly writing any Service Worker code yourself!
What else can you do with Service Workers?
The Service Worker API is so powerful that you can do a lot more with it. Here are 4 examples that we have come across which use the API in an intelligent way.
Differential update of text files
Capability reporting is a much better way than user-agent sniffing if you are leveraging on features which are not supported by all browsers. The idea is to attach the capabilities of the browser (such as types of image formats it supports) and send that as a header to the server in your Service Worker script. Since all requests go through your Service Worker, this is a great place to add such logic. You can find out more examples of how Service Workers can help you do this here.
Support for a new image format!
Browser vendors not moving fast enough to add support for the ultra cool image format that you want to use? Why don’t you write your own image decoder in JS? Yes, you read that right!
Since Service Workers run in a separate thread, the actual decoding of the image happens off the main thread. Here is a JS based decoder for the BPG format which is not currently supported by any browser. And looks like Dropbox is working on a JS decoder for the recently open-sourced Lepton format too here.
Client-side Load Balancing
You can now seamlessly choose which server to make a request to on the client side. This can be used to make a request to a server with the least load, to test new features when you are rolling out an update, to do A/B testing, the possibilities are endless.
How we use Service Workers at Dexecure
Being obsessed with speeding up websites, we immediately realised the huge potential Service Workers had to greatly speed up dynamic websites. Right now, we use a simple script to re-route image requests to our servers for optimization. We use different parameters like the device and browser being used to deliver highly performant images. There are a few reasons why we chose to offer our service via a Service Worker.
Yaay Progressive Enhancement
Progressive Enhancement is built into the very DNA of Service Workers. Your browser supports Service Workers? Okay, once the Service Worker script is installed on your site, your website would be enhanced to work offline / receive push notifications / insert your favourite Service Workers use case here. In our case, we upgrade the website to make images load faster!
For browsers which don’t support Service Workers, the original website continues to work as normal.
Service Workers lets us enable automated fall-back mechanisms very easily. For example, it is super simple to ask the browser to get the original image if it is not able to get the optimized image from our servers. This is how we implement it in our script.
Ease of Integration
Just adding one script tag on to the page lets us intercept and optimize all requests made by the browser - image requests from IMG tags, images referenced from CSS, images loaded via JS (man Service Workers are powerful!). We have had developers integrate Dexecure in under 15 minutes!
I am very excited to see the different use cases developers would come up with Service Workers and I believe we have barely scratched the surface of what is possible with them! APIs like these give developers the power to design fast experiences for their users and not just blame the browser. The Streams API is another such API that I am looking forward to -- it is incredibly powerful and is a killer combo along with Service Workers!