Service Workers – The State of the Web

Service Workers – The State of the Web


RICK VISCOMI: Hello, everyone. And welcome back to
“The State of the Web.” My guest is Jeff Posnick. He’s on Google’s
Developer Relations Team. And today, we’re talking
about Service Workers and how they’re elevating the
capabilities of Progressive Web Apps. Let’s get started. [MUSIC PLAYING] All right. So Jeff, thanks for being here. In the context of
web technologies, what does it mean for a Worker? And what does it actually do? JEFF POSNICK: So the
whole idea of a Worker has been around for a while. Traditionally, there
were Web Workers. And this basically
serves as almost like a background
thread for the web. So a Worker can execute
JavaScript code. That’s kind of independent from
the context of your actual web page. And it’s a great way to
kind of offload processing or do tasks that might take
a certain amount of time without slowing down the main
thread for your web page. And that’s kind of been the
traditional model for Workers on the web. RICK VISCOMI: So now, what does
it mean for a Service Worker? What does that actually do? JEFF POSNICK: So Service
Workers builds on that concept and adds some superpowers,
really, things that you were not able to do before. So a Service Worker is
similar to a Worker, in that it’s running independent
from your actual web page. And it doesn’t have access
to things like the DOM or the global scope
of your web page. But unlike Workers, it could
respond to specific events. And some of those events
relate to network traffic. So one of the really cool
things and most common use cases for a Service Worker is to
respond to outgoing network requests that your web
page might be making. And it can kind of sit
in between your web page and the network and
almost serve as a proxy that you control. And you could write
code to take advantage of things like the
CacheStorage API and say, hey, I
know how to respond to this particular
request without having to go to the network. I could just use
this cached response. And thereby saving
the uncertainty and unreliability that comes
with going against the network. RICK VISCOMI: It also
enables capabilities like push notifications,
et cetera? JEFF POSNICK: Yeah. So there’s a whole bunch
of event based listeners that you could set up in a
Service Worker, including responding push
notifications that might come from a notification server
and fetching requests and a few other
interesting things are slated for the future as well. RICK VISCOMI: So what’s the
status of its implementation and support? JEFF POSNICK: Yeah,
so Service Workers are well-supported right
now in modern browsers, so pretty much anything
Chrome or Chromium-based, Firefox, Safari, and
Edge at the moment. It’s great. They all have at
least a basic level of support for service
workers and some of the enabling technologies,
like the CacheStorage API. So they’re ready
to use right now. RICK VISCOMI: So websites may
experience network reliability issues at any given time. Would you recommend Service
Workers for every website? Should they all be using one? JEFF POSNICK: Well,
it’s tempting to just throw a Service Worker
up and see what happens. I would suggest to
take a little bit more of a considerate approach
before adding a Service Worker to your web app. Ideally, a Service Worker will
kind of play the same role that your web server
would play and maybe share the same logic for
doing routing and templating that your web server would
normally respond with. And if you have a setup
where your web server– for instance, for a lot
of single-page apps, the web server is
just going to respond with some static HTML
that could be used to satisfy any sort of request. That’s pretty easy to map into
a Service Worker behavior. We call that the App Shell
model, where a Service Worker will say, hey, you’re
navigating to XYZ URL, I could just respond
with this HTML. And it’ll always work. So that’s a really good model
for using a Service Worker if you have a single-page app. We’re also seeing some
success with partners who are using models where
their server is implemented in JavaScript. They have some routing logic. And they have some templating
logic that’s on JavaScript. And that translates over really
well to the Service Worker as well, where the
Service Worker would just basically fill the role that
the server would normally play. I would say if you have a
scenario where your back end web server is doing a whole
bunch of complex templating and remote API calls in
a language that is not JavaScript, it really might be
hard to get your service worker to behave exactly the same way. So in those scenarios, you
can add a Service Worker. And we have some
provisions in place to not pay the price
of having that Service Worker intercepting all requests
and then not doing anything, just going on
against the network. There are ways of saying,
hey, we have a Service Worker, but we’re not going to be
able to respond with HTML for navigation requests. In those scenarios, it is
still possible to use a Service Worker for things like, OK,
show custom offline page when you detect that a user’s
network connection is down, or implement a
interesting caching strategy, like stale
while revalidate for certain types of resources. So it is still possible to add
a Service Worker in those cases. But you won’t necessarily
get the same performance and reliability
benefits that you get when your Service
Worker really responds to all navigations with HTML. RICK VISCOMI: By essentially
having a network proxy juggling requests and responses,
is there a latency cost to having a Service Worker? JEFF POSNICK: Yeah. So you’re running
JavaScript code. That’s sitting in between
your web app and the network. And that’s not free. Some of it depends upon whether
the Service Worker is already running. One of the neat features
about a Service Worker is that, particularly
to preserve battery on mobile devices, it’s
killed pretty aggressively. It doesn’t just keep running
forever in the background. So sometimes you do have to
start up the Service Worker again. And there is a cost
involved in that startup. There’s a really good talk
from the Chrome Dev Summit that just happened a couple of
months ago that kind of goes into some metrics and
real world performance timings of exactly how long
it takes to start up a Service Worker. I’m seeing tens to
hundreds of milliseconds depending upon the actual device
and things like the storage speed of the device. So you are going to be paying
that cost, potentially, when you’re using a Service Worker. And again, that’s
really why it’s important to make sure that
you have a strategy in place for responding to
requests, hopefully by avoiding the network and just
going against CacheStorage API ideally. And if you’re doing
that, then you should see the Service Worker
give you a net positive in terms of performance. Paying tens to maybe even
hundreds of milliseconds is nothing compared to the
multiple seconds of latency that you might
expect from making a network request each time
you navigate to a new URL. RICK VISCOMI: Right. What’s the saying,
the fastest request is the one that you
never need to make? JEFF POSNICK: Indeed, yeah. RICK VISCOMI: So what
are some anti-patterns that you’ve seen in the way that
people have implemented Service Workers? JEFF POSNICK: There’s
a lot of power involved in using a Service Worker. It is just JavaScript
that you could write that will pretty
much do whatever you want. So you can do all sorts of
crazy things, some of which are kind of cool as proof of
concepts but not necessarily things you want to
apply to production. In terms of the
things that we’ve seen as pain points
or things that are pretty easy to,
unfortunately, get wrong when implementing
a Service Worker, I think one of
the things that is most common is caching
requests and responses as you go without having any
sort of upper limit on the amount of data
that you’re storing. So you can imagine a
website that maybe has a bunch of different articles. Each of those
articles has images. It’s pretty easy to write
a Service Worker that just intercepts
all those requests and takes the responses,
saves them in the cache. But those cached
responses will never get cleaned up by default.
There’s not really any provision in the
CacheStorage API for saying, stop when you reach 50 or 100
entries or something like that. So you could very
easily just keep using up space on
your users’ devices and potentially use up space
for things that are never going to be used again. If you have an article
from a week ago, and you’re caching all the
images in that article, that’s kind of cool,
I guess, if you’re going to revisit that
article immediately. But if it’s a page that a user’s
never going to go to again, then you’re really just
caching things for no reason. I would say that, really,
one of the important things, before you implement
your Service Worker, kind of have a strategy for
each type of request, and say, here’s my navigation requests
that are being made for HTML. Here’s how I’m going
to respond to them. Here are the image
requests I’m making. Maybe it doesn’t make
sense to cache them at all, or maybe only cache
certain images and not others. So thinking about
that, and that really just means getting really
comfortable with the network info panel in the
browser’s dev tools and just seeing the full list
of requests that are being made. Sometimes your web
app is making requests that you don’t even realize
is happening, because it’s coming from third party code. And your Service Worker
ends up seeing that too. So you want to
make sure that you know what your Service
Worker is doing and you know what
your web app is doing. And just one other, I would
note that, a lot of times, a pain point and things
that could go wrong when using a Service
Worker just has to do with controlling
updates to resources. So you are stepping in between
your web app and the web server. You’re responding, potentially,
with cached resources. If you’re not sure that those
cached resources are being updated every time you make
changes to your actual website and you redeploy
to your web server, it’s possible that
your users will end up seeing stale content
indefinitely. And this is a tradeoff. Seeing stale content
but avoiding the network gives you a performance benefit. So that’s good for
a lot of scenarios. But you do need to have
a provision in place for updating and making
sure that maybe the user sees stale content. Then the next time
they visit the site, they get fresh content. So you could do that right. Unfortunately, you could
get that part wrong, and the users can end up with
a frustrating experience. RICK VISCOMI: So you maintain
a tool called WorkboxJs. What is that? And what does it do? JEFF POSNICK: Sure. So Workbox is an open
source set of libraries for dealing with
Service Workers, so kind of all aspects of
building Service Workers. So we have some
tools that integrate with build processes, including
we have a Webpack plugin. We have a command line tool. We have a node module. And that aspect of
the tool is basically something you can drop
in to your current build process and get a
list of all of the assets that are being produced
every time you rebuild your site along with some
fingerprinting information, like this is a particular
version of your index.html. Workbox will keep
track of that for you. And then it will
efficiently cache all of those files that
are being created by your build process for you. And that just helps ensure that
you don’t run into scenarios like I just described, where
you’ve rebuilt your site, and you never get updates
to your previously cached resources. And we also have some
tools as part of Workbox that are more executed at
runtime as part of the Service Worker, so some libraries
for doing common things like routing requests. There’s just some canonical
response strategies for dealing with caching,
so things like stale while revalidate or going cache-first. We have implementations of those
strategies inside of Workbox. And then we have some
value adds on top of what you get with the
basic Service Workers spec and the CacheStorage spec. So we actually have
an implementation of a cache expiration
policy that you could apply to the caches
that would otherwise just grow indefinitely. But using Workbox,
you could say, hey, I’d actually like to stop
when I reach 10 items and purge the least recently
used item and just cache when that happens. And a few other kind
of random modules, we see it as a bit of a kind of
grab bag for all the things that somebody might want to
do with a service worker. And we kind of ship them
as individual modules. You can choose the
ones that you think would be useful for your
particular use case. If you want to use
something, that’s fine. You don’t have to incur
the cost of downloading it or anything like that. RICK VISCOMI: Do you foresee
some of those caching and expiration policies
making their way back into that CacheStorage API? JEFF POSNICK: Yeah. It’s kind of
interesting whenever you have something that’s
almost like a polyfill for some behavior on the
web, whether that ends up being implemented back
into the standards, and the actual runtime could
just fade away and just use the underlying standards. And I’d like to see that. I think that Workbox has been
really great for enabling folks to ship Service
Workers in production and seeing the types of
things that they actually need when you’re shipping
something in production. And a lot of times,
when you can do that, and you can point
to something like, yeah, it is actually important
to have runtime cache expiration. That could then be used when
going to different standards groups and saying,
hey, we really do need to extend what’s
supported natively in the platform to take care
of this really common use case. Whether that actually happens
or not remains to be seen. But I think Workbox is
positioned to help folks with that initial proving
that these things are necessary stage and
we’ll take it from there. RICK VISCOMI: So in terms of
adoption according to the HTTP Archive, less than 1% of
websites tested actually include a Service
Worker, which is kind of a misleading
number for two reasons. The first is that it’s actually
growing at a very fast rate. And the websites that do
include it are actually pretty popular websites. Can you give us some
examples of those? JEFF POSNICK: Yeah. So I think the raw
number of unique URLs might be on the lower side. But I think in terms
of traffic, sites as big as a Google Search
have deployed a Service Worker for some types of clients. Partners that we’ve talked about
using Workbox in particular in the past include– Starbucks has a nice
progressive web app that’s implemented, Pinterest as well. And there’s also some sites
that you might have heard of, like Facebook and Twitter, that
are using Service Workers, not using Workbox, but
using them to unlock things like their progressive
web app experience or, in some cases, just
showing notifications, which is an important part
of being on the web and having parity
with native apps. So I think that the actual
number of visits to web pages is probably much higher than
the 1% number would indicate. And there are challenges
with adding a Service Worker into, especially, legacy sites. It does take that coordination
that we talked about before between making sure that
your Service Worker actually is behaving in a similar way
that your web server would behave. And that doesn’t always
fit into existing sites. So a lot of times,
what we’ve seen when working with partners
in particular is you’re planning a rewrite, a
re-architecture of your site anyway. That’s a great time to add a
Service Worker in and just kind of take care of
that story as well. RICK VISCOMI: Are
there any options for CMS users who
may be using things like WordPress or Drupal? JEFF POSNICK: So
there definitely are. And I think that,
first of all, I’d refer everybody back to
another talk from the most recent Chrome Dev
Summit that really goes into some detail about the
WordPress ecosystem in general. So they have a
really cool solution. Some folks from the
DevRel team at Google have been working on it. And I think it kind of works
around that problems I was saying where the
architecture for your back end web server needs to match
up with the Service Worker implementation by just
sending a baseline. So it’s not an attempt to
take any arbitrary WordPress site that might be out there
which might be executing random PHP code
depending upon what kind of themes and extensions
and all the other stuff is going on. You really are not going to be
able to successfully translate that into just a general
purpose Service Worker. But the approach that was
described in this talk seems to be building on top
of a common baseline of using the AMP plugin as
a starting point. So any site that has gone
through the effort of meeting all the requirements for
using the AMP plugin– so that means– I don’t know the full set– but I think not running
external scripts, not doing anything too crazy
with other plugins that’s inserting random
HTML on the page. Building on top of
that, you can then have a Service Worker that’s
like, OK, I actually do know how to handle this
subset of activities that WordPress is doing when
it’s using the AMP plugin. And it can automatically
generate that Service Worker for you. So again, it’s part
of a migration story. I think it’s not going to just
drop into any existing legacy WordPress site. But it does give a
nice path forward for folks who are planning on
rewriting anyway or planning on making some changes anyway. RICK VISCOMI: Yeah. And plugging into
the CMS ecosystem is a great way to
increase adoption by tens of percents on the web. JEFF POSNICK: Yeah, absolutely. RICK VISCOMI: So what
kinds of resources would you recommend for
someone who’s just getting started with Service Workers? JEFF POSNICK: We have a
lot of material available, some of which is more
recent than others. I would say that the things
that I worked on most recently are the resiliency
section of Web.dev. So if you were to
go there, kind of have something to walk you
through the various steps of thinking about adding a
service worker to your website or just really thinking about
making your website more resilient in general. So it’ll talk about identifying
your network traffic. It’ll talk about using
the browser’s HTTP cache effectively, which is your
first line of defense. And then it’ll go into
how you can add Workbox to an existing site and the
various steps involved there. So if you want a guided path,
I would say that’s one option. I’m a little biased for that. I would say that if you
want to just learn more about Service Workers in
general, then material written by my colleague Jake
Archibald is probably the best bet for
folks who really want a deep dive on things. He was somebody who worked
on the actual Service Worker specification. And he knows more than anybody
else about these things. So he has a really great article
talking about the service worker lifecycle, all
the different events that get fired, and how you have to
handle those events differently and the implications
that they have for the state of your caches and
updates and things like that. So diving into that would be
my recommended starting point. And he has another article that
talks about a cookbook almost for recipes for caching,
so implementations of the stale while
revalidate pattern and the cache-first pattern. If you wanted to implement
it yourself instead of using Workbox, he kind
of walks through the process there. RICK VISCOMI: Is that
the Offline Cookbook? JEFF POSNICK: Yeah, it’s
the Offline Cookbook. And if you want something
that’s really offline, there’s some actual
physical books that are pretty cool
related to Service Workers and progressive web
apps in general. There’s a new book written
by Jason Grisby in particular that I would recommend and
just kind talks a little bit about not necessarily some
of the technical aspects of Service Workers but more
about why you should think about adding a Service
Worker to your site and why you might want to
build a progressive web app in general. And that’s a really
cool book that takes it from a
slightly different angle but gives some good perspective. RICK VISCOMI: Great. Jeff, thank you
again for being here. JEFF POSNICK: Absolutely. RICK VISCOMI: You can find
links to everything we talked about in the description below. Thanks a lot. And we’ll see you next time. [MUSIC PLAYING]

Author:

13 thoughts on “Service Workers – The State of the Web”

  • CreativeTechGuyGames says:

    Not sure what happened, but this video is extremely quiet compared to most other videos. I had to crank my volume up 4-5x higher than normal to hear this clearly.

  • Vincent Kammerer says:

    Thanks a lot for this video, informative and makes me want to get back into Service Workers. I second the comment about the audio being not so great. The voice of the the interviewee is sometimes barely audible.

  • Jeff is the man!! Video coming in perfect timing thank you!! Both of you ? I am shipping my new web app with Serviceworker powered by workbox in few days ?

  • I watched the video in "Coding Tech" channel and came here only to talk about the music. It would be OK in a maximum 5min video, but not in a 20min video. Too loud and distracting. The content is great!! Cheers guys!

  • I've seen some third party adverts that use Service Workers to drop a Malware payloads into the User Browser Cache. I sent the info to the Chrome Team and they just replied with a link to a Chrome web page saying yes Service Workers can be dangerous. That's great, but why don't the Chrome Team take the threat a bit more seriously!

  • I don't know why, but when i try to access this link and make it "Offline" from DevTools, simply can't load. This website provide tools like service workers. But it can't run with offline mode? really?
    https://developers.google.com/web/tools/workbox/

Leave a Reply

Your email address will not be published. Required fields are marked *